When only one side pays the price, I think it isn’t that surprising that it gets dogmatic. Because there isn’t any trade off, really, for me as a user, getting scripts is simply bad, and getting plain old documents is simply good. Where’s the nuance or tradeoff? I don’t care if setting up a static site generator takes more time or is harder or whatever, I only see the output, which is obviously better in one case.
In the case of web devs talking to web devs, I’m not sure, having not been in that room. But from an outsider point of view, it seems like some sites care about this sort of thing and others just don’t. Maybe which parties are included in the cost calculation is basically an axiom, not really something that can be logic-ed out, and so it tends toward dogmatism and statements of preference? (hopefully I’ve accurately represented the fact that this is 100% a comment from the user point of view, so heap of salt and all that).
Don't these static site generators serve the scripts that you do not like? On a statically-generated site, the dynamism of the site is in the script and is evaluated in your browser. On a non-static site, the server does the evaluation, so your browser does not have to run as many scripts for the same level of dynamism.
This isn't that simple IMO. On one hand, JS-heavy apps take longer to load on underpowered devices and slow connections, which should be treated as an accessibility concern. On the other, approaches like LiveView, HTMX or even plain old HTML struggle on high-latency or spotty connections. A well designed SPA can cache data locally and push changes whenever internet connectivity comes back, making it feel a lot snappier in these situations. SPA apps are harder to write because you have an extra API layer, but you need one anyway if you're also writing a mobile app, so they may even become slightly easier in that situation. Every solution has its tradeoffs.
In fairness, most of my experience in past 10 years is dealing with companies trying to fake SPA style apps in blog-style server side frameworks.
Maybe it's gotten better very recently, but Rails+jQuery mess is not better if folks really want a SPA-style app and interactions.
Among the 4 production B2B Rails apps I've been adding features to in the past year, the only one using jQuery was created 13 years ago. None of the others ever used jQuery, and using Hotwire Turbo to replicate SPA functionality is easy nowadays.
One of the Rails apps serves a Flutter mobile client on the front-end, and as much as I appreciate all the lifting Flutter does for me, the sheer amount of code required to support that is enormous and laborious in comparison to writing a few Turbo frame tags in the fullstack Rails app. If not for a few gotchas that the client app needed, that mobile app would have been done with Jumpstart Pro iOS & Android with Turbo Native (great code reuse potential).
Users of Rails apps leveraging Turbo frames or streams don't think those apps feel more shiny and cool and performant than legacy SPA frameworks such as React, and the modern Rails developers spend less time churning out code.
Most of my own custom work plugs in to the old school PHP server side rendering and that works just fine. I also have what's in effect two separate SPAs in the backend. Doing these in htmx and Alpine or whatever would be an absolutely enormous headache and it would perform worse. There's no one size fits all.
People love arguing over nothing instead of picking a stack and shipping.
The most valuable code is the code that runs in production.
It’s important to think about the right solution, and it’s also important to know when and why you’re putting something into production. Golden mean and all that.