[slightlyoff]

OP here; at a tactical level, prefer HTML/CSS and MPA architecture until you have firm evidence of long sessions and many interactions per session that justify JS, and when you add JS to smooth a common interaction based on data, build from progressive enhancement unless it's impossible (e.g., a text or image editor).

More pithily, maybe PHP was good, actually?

Popping up a level, this isn't about tools, it's about culture and how we decide to choose. I work every day with teams that need to claw back to sanity from years in the JS fever swamps, and nobody's having a good time when launches are blocked on terrible perf, a11y, etc. The root issues here are down to complexity and eng/management capacity to master it. What gets teams in trouble is picking stacks that have mountains of implicit complexity without attendant controls.

Some of that is captured in this post; hope it helps:

https://infrequently.org/2022/05/performance-management-matu...

[em-bee]

so in essence your argument is that management needs to care about performance because most end users have devices that are not powerful enough to process all that javascript, based on this technical argument i found hidden in a footnote:

JavaScript-delivered UI strips the browser of its ability to meaningfully reorder and slice up work so that it prioritises responsiveness and smooth animations. JavaScript is the "fuck it, we'll do it live" way to construct UI, and stresses the relative performance of a single core more than competing approaches. Because JavaScript is, byte for byte, the most expensive thing you can ask a browser to process

that's fine. as an independent developer i don't care much for the management problems in large teams, so maybe this topic is not for me. i need to make the tradeoffs between engineering and product performance, development cost and client budget all by myself, and hence am looking to technical solutions to find the right tradeoff.

what i am missing on the technical side of the argument is how "fuck it, we'll do it live" relates to latency.

my expectation is that while device performance increases continuously and becomes cheaper, latency on the other hand does not improve as fast.

to put it drastically: people in rural africa or india have smart phones from the 2010s but internet connectivity from the 1990s

[slightlyoff]

Device performance has been growing in diversity as we approach smartphone saturation (the last couple of hundred million flipphones getting traded for < $100 low-end smartphones). I'm working on an update to this series, but here's a recap from last year:

https://infrequently.org/2021/03/the-performance-inequality-...

As this relates to latency, JS-mediated UI is slower to materialize for a host of reasons, not least of all the problems with getting it across the wire (as you note). Naive SPA designs tend to serialize what should be parallel (data fetching and shell setup). Getting better at this requires more sophistication, whereas teams that stick to basic HTML + light progressive enhancement tend to end up with simpler systems that are faster for light-to-medium session depths and are easier to diagnose/fix when things go sideways.

[em-bee]

another thought:

The root issues here are down to complexity and eng/management capacity to master it. What gets teams in trouble is picking stacks that have mountains of implicit complexity without attendant controls.

i agree that some (or maybe all) frameworks go needlessly complex with their dependencies. little libraries that contain one function that should really be folded into the other libraries that are using that function.

but isn't part of the problem the the inherent higher complexity of modern interfaces? the days where a site as simple as hackernews are appealing to the average person browsing the web are gone. i am afraid that in order to compete for visitors or customers, we have pushed ourselves into a corner. doesn't any new website need to function and look as modern as every other if it wants to have a chance?

a large engineering team with a sufficient budget and time may accomplish that without a framework, and so you are exactly right, the strings to accomplish it need to be pulled at the very top. but what hope do we have when the primary directive that comes from the top is to keep the cost down?

especially new projects suffer from this. i can only afford to spend engineering resources after a project has become profitable. but in order to get there, i need to cut corners where i can. that usually means using frameworks to get up and running fast. and once we make a profit we can spend money to improve things. but by then it's to late to switch to a non-framework approach unless the resources are enough to start over.

the complexity caused by frameworks is costing us money. but it's money that is now available because the project is making a profit.

wouldn't your approach require higher expenses upfront, at a time when i don't even know if it is worth the effort?