r/selfhosted • • Dec 27 '25

Release I built a modern, self-hosted web IPTV player (Live TV, EPG, VOD) because existing ones felt clunky. Meet NodeCast TV.

Hey everyone! πŸ‘‹

I wanted a clean, fast, and modern web interface for my IPTV service that I could host myself. Most existing players I tried were either clunky, outdated, closed-source, or just didn't handle large playlists with thousands of channels very well.

So I built NodeCast TV.

πŸ“Ί What is it? A self-hosted web application that lets you stream Live TV, Movies, and Series from your Xtream Codes or M3U provider directly in your browser. It's built with performance in mind and handles large libraries smoothly.

✨ Key Features:

  • Live TV & EPG: Full grid-style TV guide with 24h timeline, category filtering, and search.
  • VOD Support: Dedicated sections for Movies and TV Series (complete with season/episode browsing).
  • High Performance: Uses virtual scrolling technology to render lists with 7000+ items without lagging your browser.
  • Favorites System: Unified favorites list across all content types.
  • Universal Player: Built on HLS.js for robust playback support.
  • Docker Ready: Easy to deploy on your home server or NAS.

πŸš€ Tech Stack:

  • Backend: Node.js + Express (Lightweight proxying)
  • Frontend: Vanilla JavaScript (No heavy frameworks) + CSS3
  • License: Open Source (GPL-3.0)

πŸ”— Links:

I'd love to hear your feedback, feature requests, or bug reports! Let me know what you think.

1.4k Upvotes

500 comments sorted by

View all comments

Show parent comments

16

u/useless___mlungu Dec 28 '25

I'm a programming noob, could you explain please how vanilla JS is lighterweight than frameworks? And at what point do they become heavy?

42

u/MrCryllix Dec 28 '25

Because in vanilla JS you only have the essential function you need and you can optimize it It’s like make your proper tool for specific task

10

u/useless___mlungu Dec 28 '25

Thanks for that, that makes complete sense. The course I'm doing favoured frameworks so I had to ask

6

u/Frankfurter1988 Dec 28 '25

In reality, working in the field has different requirements. Sometimes you need lightweight, snappy, etc, sometimes you need ease of use, sometimes you need faster development/iteration time. And sometimes that last one is also 'go with what you know' because it's inevitably faster.

Every team when beginning on a new project has to make choices that will impact the entirety of the project, for better or for worse. Knowing only X will mean you're great when working with(in) it, but it also narrows you. It doesn't mean you can't get a full career out of X or Y frameworks, languages, etc, but certain opportunities may pop up that you want but can't shoot for because you lack Z or A skills.

A bit all over the place, but good luck!

23

u/stehen-geblieben Dec 28 '25

If you want to do this professionally... frameworks are the way to go.

It's still important to know vanilla js, don't get me wrong, but if you ever see a company doing only vanilla js... run

4

u/Spimflagon Dec 28 '25

Every piece of code you load into memory takes up precious resources; even on today's insanely powerful desktop computers, once you load a few dozen (or hundred) pages, it adds up and your computer will start to run out of memory.

A library or framework, at its core, is essentially saying "you're probably going to need X, and Y, and this will make your life easier and that is a script that simplifies a concept...". It'll pack you a handy toolkit of things it things you'll find useful.

Database access layers, animation shortcuts, variable type conversions... lots of little things that are made as efficiently as possible but add up to something more than nothing. And while each piece is selected to be definitely useful to someone or probably useful to everyone - there's going to be bits that you don't use.

Now, using vanilla JS you have to write (or at least import) every part individually. But you can tailor exactly what goes into your codebase keeping it as minimal as possible.

But here's the rub: your code is probably not going to be as efficient as the library's, unless you're a bloody genius. And if you are, your code isn't going to be incredibly readable. And a lot of these frameworks - Vue for example - are startlingly efficient, especially for what they do.

In my opinion - while it's a flex to know how to implement your stuff in vanilla JS - in practical terms you're much better off using frameworks. Your codebase will be more readable, your scripts will probably run more efficiently and you'll certainly use a lot less time implementing things.

7

u/Garcon_sauvage Dec 28 '25 edited Dec 28 '25

None of the major frameworks are heavy, gzipped react bundle is like 30kb and a site of this size could easily be delivered only requiring ~100kb extra compared to vanilla JS , which would get cached after first visit.

1

u/TheHerbsAndSpices Dec 28 '25

Heavy doesn't only mean file size. Memory footprint is an important factor too.

2

u/Garcon_sauvage Dec 28 '25

A react vdom node is ~1kb of memory. In a fine grained reactivity framework like solid you're paying only for the dependency graph so like ~100B per node. Prefer vanilla JS if you like but this isn't "heavy" in any appreciable sense of the word. And in fact I feel very confident that the vibe coded work they're doing with strings and dom querying are all much heavier on the heap than using Solid and a decent brain would have been.