I do have the benefit of a PC connected to my living room TV, but even if I didn't, most TVs these days can natively play media from a network share.

There’s wide compatibility with all sort of devices and you dont need to firewall tunnel vpn or do any setup. It’s totally grandma friendly.

Your approach works great for a single user with a tv connected PC. Lets say with your current system you want your parents, right now, to be able to view your movies files. How easy is that to do, and how much technical knowledge or assistance is required?

What is a little nicer about it is that we can hear about something, have it downloaded to the folder that gets indexed, and have it available to play near instantaneously. My NAS also does transcoding if necessary, so that eliminates a lot of hassles around codecs and such as well.

A lot of people take this a step further and avoid all paid services and just use tools like radarr and sonarr to get whatever content they are interested automatically off the high seas and play it when they want to.

The network share is the hard part- well really having the always on server that hosts it- plex/jellyfin/emby etc are just a little bit of sugar on top that make it a nicer experience. And IME, you install once and you are done, there is no maintenance to deal with afterwards so there is little downside.

Ultimately if you just want to browse a filesystem, network shares are fine, but if you want a nice looking front end for that with logos/artwork, descriptions or reviews from the internet, or features that require the files and metadata to be indexed in a DB of some kind, then these UIs come in handy.

Plus they look nice are generally easier for other less tech. savvy members of the househould to use.

Now I just get a pop-up on my phone that Plex has the latest episode. I sit on my couch, hit play on my nvidia shield, and watch on my giant OLED. It's great - and I've been doing this for years now.

Once you go through the initial set up, the UX is fantastic. Far better than anything Netflix, or any commercial provider has ever built.

And for music - Plexamp is an ode to Winamp and is worth it alone. It completely brought me back to the pre-Spotify world of music enjoyment.

And my content is always available from my NAS no matter where I am or what device I have with me.

I do both. But when watching with the family it's much easier to have them a media streaming server than to have to hook the PC to the TV (or projector) and use VLC.

Now at times for whatever reason some media file won't play over the network: dunno why... Maybe it's a blue moon, maybe there's a space in the filename, maybe I didn't respect the directory naming scheme or the file permission or whatever freaking bullshit. When that happens, I put the file on a USB stick, then on to a laptop, then HDMI cable. And that always work. (just had to make sure the TV wasn't using interpolation to 60 Hz or whatever otherwise every movie looked like a soap opera).

You only have those things if you choose to use them.

I've been building websites for 25 years. I use the same core technologies today that I did when I started. Sure, I make use of modern improvements to the languages themselves, but I have never permanently adopted any of the "hot new trends" and feel I am better - or at least saner - for it.

No, your marketing or e-commerce website almost certainly doesn't need a JS bundling toolchain. It almost certainly doesn't need a CSS preprocessor or even a CSS boilerplate/framework. It almost certainly doesn't need an enterprise-class PHP framework; or a dependency manager; or a CI/CD pipeline.

If you have a thousand people working on a single product, yes, but you also have the resources to have dedicated tool support teams at that level. In my experience, if you’re under multiple dozens of developers or not everyone works on all of your projects, the tools fragment because people aren’t combining or configuring them the same way and there’s enough churn in the front-end tool space that you’ll hit various compatibility issues which lower the effectiveness of sharing across projects. This is especially true if you’ve hired people who self-identify as, say, Next or Tailwind developers rather than web developers and lack the understanding of the underlying technology to fix complex problems.

Build pipelines are purely a technical decision. Bundlers are purely a technical decision (TBH, a non-brainer if you decide to have a build pipeline, but it's not an organizational helper). Those help one do some things, not several people to organize.

I'm still waiting for any person to claim they made CSS maintainable by adopting a framework. It's an almost purely organizational decision with no upsides at all.

PWAs are a product decision, not technical or organizational. The same applies to Core Web Vitals, SEO, layout shifts and srcset, those are all product decisions.

You can escape the technical and organizational decisions. You can't escape the product ones.

Can I ask, what classifies as large scale project for the web?

I previously created and exited a trading platform that did billions in transactions via our servers with thousands of users streaming real time data. It's certainly more complicated and "larger" than 99.9% of things you'll ever do. So does that qualify?

If so, I can tell you that I did it with PHP and no JS frameworks. Hosted on a couple of VPS servers from digital ocean. From idea to execution to exit in ~9 months.

You know what the weird part is? I see your take repeated over and over by "shovel peddlers" and grifters. And every single time it comes with 0 substance or merit.

The 'I' here reveals that this is indeed not a large scale project, though perhaps impressive. When working on a piece of software with tens of people, using more tooling really does makes sense.

A 9-person-month project is just not a large scale project by any definition.

I'm talking about projects that have a lot of people working together across multiple teams where not everyone is even a dev. This is routine with e-commerce. The build will have assets from design teams, copywriters, analytics scripts, etc. and a CMS isn't always the correct or even scalable solution for that. The original commenter I was replying to seems to be stuck in the past. These days it can all be done with a simple CI script, but yeah ultimately that means build tools.

Above all else, like I said in another comment, there cannot be server-side rendering because it deploys to a CDN for hosting. These are projects that require huge amounts of content, but need to stay responsive. The final build result and upload is many files, but the initial load for the site is minimal JS and HTML to render for the user.

> billions in transactions via our servers with thousands of users streaming real time data. It's certainly more complicated and "larger" than 99.9% of things you'll ever do.

Large scale doesn't have to be complicated, but it does need some way to coordinate the effort which means there's a build and there will be requirements that are beyond any one person's control and expected for the modern web.

I want to also point out the obvious that there's insane money being made in e-commerce since it's now the default way to shop for everyone. It's a very common type of web project and if the typical HN web dev is getting paid a decent salary it's likely that the sites they maintain have several orders of magnitude more users than what you're talking about.

I think it makes a lot of sense and allows for faster initial rendering of the page while automatically setting up the JS and interactivity in the background.

I am not trying to be dismissive, but a common strict requirement is static hosting from a CDN, embedded environments, etc.

Then your JS bundle is broken.

Promises exist. Modules exist. HTTP/2+ exists. You can load data while you are loading a small amount of JS required to render that data while you are loading other parts of your JS.

If everything is sequential: load giant JS bundle -> fetch -> render, that's because someone architected it like that. Browsers give you all the tools you need to load in parallel, if you don't use them then it's not the browser's fault.

You do not need SSR or rehydration. That's just Vercel propaganda. They saw that people are doing a stupid thing and decided to push a complex solution to it. Why? It makes them money.

If you use code splitting, your initial bundle size can be smaller, yes. That's about it.

I guess in theory you can hack together static loading skeletons that you then remove when React loaded your initial bundle, but that's certainly far from a common approach. By that standard, the vast majority of JS bundles would be "broken".

You totally can!

Don't call fetch directly from a component - it's brittle. Write a hook to abstract that into one place. In your hook you can support prefetching by awaiting the promise you fired before you loaded your JS bundle (if you don't want to modify the server), or else take advantage of the browser cache. In this way your data and code can load in parallel.

Is it common? Not really. But it's a technique that is in the toolbox of a conscientious webdev.

I guess if you're already so deeply entrenched in writing all your application logic on the server side you need React SSR, but that sounds miserable.

I did not interpret that as React SSG. SSG is the default behavior of NextJS unless you dynamically fetch data, turning it into SSR automatically.

What I thought of is React's "renderToString()" at build time which will produce static HTML with event handlers stripped, in preparation for a later "hydrateRoot()" on the client side.

It only depends if you interpret it incorrectly.

I'm tired of having to use stupid hacks to get nice-looking borders between flex/grid items.

I've been developing web stuff for 15 years now and sometimes I can't believe comments like these. We didn't have it "so much better before". CSS sucked hard and getting things right for three devices was an incredible pain in the ass.

Tables have semantic meaning. They don't support fractional units. Reflowing for mobile is impossible and you need JS hacks like splitting tables. You can't reorder natively.

Flex and grid enable layouts that are far beyond anything we could do with table layouts. Anyone who claims otherwise has obviously not done any amount of serious, production FE UI design and development.

Are there bits of DX ergonomics I’d like in flex and grid? Of course. Does the syntax sometimes feel a bit arcane? Yeah. But the raw power is there, and anyone who claims the contrary is either a gormless backend developer, or some troll who is trying to design things in MS Word.

I reminded that person we had to use floats and positioning hacks and abuse HTML tables for page layout before flexbox and CSS Grid were created.

There was no way simple method to center a div!

They meant now. "we have it so much better than how it used to be."

Gap decorations allow you to add borders between flex/grid items, but without the woes of dealing with table quirks and behavior.

Common use cases would include mimicking design patterns found in print layouts, particularly newspapers and menus, to help divide groups of items or info.

Examples: https://developer.chrome.com/blog/gap-decorations

But the truly troublesome issue is how an entire ecosystem of (very expensive) hardware is allowed to be tied to an identity controlled by a giant black box of a corporation.

What I mean is: you can spend thousands and thousands on devices and configure them to be almost invaluable to your everyday life, but you are ultimately completely beholden to Apple. You require their ongoing permission to continue using those devices. You are completely at their mercy.

And sure, you can argue that people willingly sign up for that kind of agreement when they make the decision to purchase Apple/Google products but that's also missing the point. Phones are now essential utilities. Accessing vital services sometimes requires an iOS or Android device.

Permitting giant, uncontactable, merciless tech corporations to control the digital lives of virtually everyone on the planet is absolute insanity.

The scenario described in the OP's article should simply never be allowed to happen.

The way I see it resolved is for Google and Apple to link the accounts to a physical person via government ID so that if you want issues to be resolved you'd have to verify yourself. This would also limit abuse by bad parties.

Now, do you want all of your web accounts be linked to your government ID?

No, but I don't think that's actually necessary. My cloud storage account with Google could be linked to my government ID, and... that might be ok? This sort of plan wouldn't require, e.g., my HN account to be linked to my ID.

Yes, that would mean that some people (e.g. activists under repressive regimes) shouldn't be storing stuff that could get them in trouble in Google Docs or iCloud Photos, but... they probably shouldn't be doing that now anyway.

But this would still require governments passing laws to prevent arbitrary account closures. Linking an account with an ID doesn't automatically make Apple/Google behave. The legally-mandated process would need to be something like: automated system detects fraud, they call the police, police investigate, and either a) they see nothing and drop it, and Google/Apple are required to drop it, or b) they investigate, prosecutors bring charges, and the outcome of the court proceedings is binding on Google/Apple (conviction = account terminated, exoneration = no retaliation allowed).

It would be easy to fix this problem simply by charging a hefty up-front fee for direct connection to high-level human support, who will take the time to verify the user's identity using established KYC procedures and then take action to restore the account. The fee would then be refunded if the problem turned out to be on the company's end.

Companies like Apple don't offer that, because they don't GAF.

Why not "just use HTML"?