> I would love to see a clear explanation of why this is viewed as true. I've seen this stated many times, but generally in a way that seems framed to an audience already inclined to accept it as true.

To the credit of those that are skeptical, it is really difficult to explain exactly how much more productive it is without having experienced something it. The closest comparison I can make is how SCSS feels coming from plain CSS - it's like all of the things that you wish were easy are suddenly easy, while still being based off of something that you are familiar and already productive with. For people coming from traditional web development, I find that Svelte is the most comfortable tool for them to learn.

> I've never seen an explanation of this written and framed for people who wrote such applications before things like React or Vue existed, and genuinely don't understand (and want to) why the model they present is viewed as so much simpler.

I wrote such applications before React and Vue existed. I don't think I could ever go back. I would not describe it as a simpler model however - you're effectively writing two applications that communicate together to make one. The benefits you get for that are beyond worth it in my opinion. Assuming that you're using NextJS or something else that removes all of the boilerplate configuration, almost all of that complexity is hidden from you unless you need to modify it.

I don't know if I would be able to do very well explaining it myself, but generally - it allows for a more clean separation between systems. My backend exposes an API that my frontend can communicate with over background HTTP requests. I can swap out that backend on a whim (from Django to Rails to Express to Gin to...you get the picture) as long as it exposes the same API. With traditional web applications, I'd have to port over my templates and structure and state management system.

Most people don't switch backend frameworks on a daily basis though, I know I certainly don't. Some of the things that I enjoy are:

- Easier temporary messages/error handling (flash messages handle a limited version of this in traditional SSR environments)
- Greater control of how my data is structured and posted (forms are simple enough once you learn them, but having your data structure dictated by DOM structure is less clean in my opinion)
- Handling more complicated state is much easier - making a wizard interface with dynamically added and removed sections/questions doesn't need a large series of separate templates
- Component structure is just better to work with than template structure (expanded upon below)

The real selling point for me is removing templating languages from your templates. I don't have to worry about what Jinja considers to be an acceptable replacement for control flow, I'm using a language that I already know and is fully integrated with the entire rest of the environment.

> I've genuinely looked for this, and I've found only either presentations of "here's how it works, doesn't this seem better?" (to which the answer always seems like "no")

Generally speaking, the larger and more complex your business requirements are, the more easily you can justify using an SPA framework. Every presentation I've found on that gives only trivial examples, likely for brevity.

> or exhortations about how CSS and to some extent HTML are obsolete constructs except as tools to be manipulated by JavaScript.

I believe that idea is part of the "make everything JS!" cargo cult. For apps that have very simple interactions, I use plain HTML+CSS and no JS. Use the right tool for the job, and all that. With that same mindset however, I'd be very hard pressed to say that there is no place or justification for the Reacts and Vues and Angulars of the world.