JavaScript hydration is a workaround, not a solution

I don't fully agree with the person you're responding too, but it feels like you're making their point for them with this. Users are engaging with a tool or some content for themselves and today. Startups are the ones dreaming of standing among the "largest, most successful websites" someday.

Users don't care how efficient or inefficient your development process is, or how much technical debt you carry, or how many concurrent users or requests you can run, or how scalable you are if things go well. If your service stands up and works for them today, none of those things are relevant to them at all.

That's not to say that the startups concerns aren't critical to making sure that the service is still capable tomorrow and the day after, and that the company doesn't collapse under bad process and inefficiencies, and that the service maintains utility rather than becoming data and stale. They're valid concerns.

But the users are so far removed from those concerns that it can be legitimately frustrating when pursuit of those long-term concerns degrades their immediate experience.

I'm not sure what other desktop apps you use but for something as simple as viewing a single database record I've not seen loading screens since about 2000 on any native apps.

Clearly this means that office politics is good for your company

Largest economies in Europe have the oldest and most drafty, poorly insulated housing stock. Therefore shitty housing stock must be good for the economy.

Largest economies in the world have the most pollution. Therefore pollution must be good for the economy.

Backwards reasoning.

I'm slowly coming around to the idea that PageSpeed (or Lighthouse, or Core Web Vitals, or whatever Google has invented this week) is what drives a lot of the complexity in web app dev. People refuse to throw out what they've learned, so every time there's a new metric to chase in case you lose SERPS ranking for being slow! devs heap another layer of complexity on to the Webpack bonfire.

Hydration is an example of this. People chased 'first contentful paint' and 'cumulative layout shift' timings because that's what Google told everyone they needed to optimize for. That meant reducing the amount of upfront work done in JS, pushing some barebones HTML and CSS to the client for those sweet, sweet metrics, and then running a massive bundle of deferred JS to make it do anything. Google is pulling that rug with Time to Interactive, First Input Delay and (coming soon) Interaction to Next Paint, so now devs are trying to write the same website but have the server strip out the code they wrote (eg Remix.run).

Everyone wants a fast website. No one wants a heap of fragile complex build tooling. The answer to the first problem is to stop trying to solve the second problem with MORE TECH. Go back to fundamentals. Just make something that works with with HTML and CSS alone, and enhance it with JS. You don't need to be clever about it, especially if the level of interactivity on your website amounts to basically a form.

I actually just updated a bunch of old Java code in Eclipse. It is simply faster than VSCode at everything -- syntax highlighting (noticeable delay in VSCode on a 1000+ line Java class), switching between files, loading files, etc. I only updated and used Eclipse because VSCode was being noticeably slow.

That was in a bare J2EE Eclipse instance, and didn't have any of dozens of plugins running that I typically would have back in my enterprise-y Java dev days. Visual Studio seems to have gone the "kitchen sink" route. JetBrains' IDEs typically wind up crammed with plugins from what I've seen. I wonder how much that screws with people's perceptions.