There are undeniable benefits in using a JavaScript-centric development workflow—to building your UI as code & rendering on the client, rather than serving static markup & using JS just for interactivity. You get to draw your own boundaries along functional lines rather than language ones, wrapping things up in encapsulated components that can be reused in multiple places. You have more powerful ways of utilising libraries than simply injecting multiple script tags on the page. And you can bundle everything up using tools like Webpack that can seamlessly handle assets of all different types, applying specific tools and optimisations to each.

There are costs too, of course, but it's often a lot harder to enumerate those, since they differ so markedly depending on the particular use-case. But since it's such a controversial topic, discussions can quickly get sidetracked along ideological lines. I've seen it result in a vague convention: for public-facing marketing pages, use static HTML, CSS & unobtrusive JavaScript; for your main app behind your login screen, use a JS framework and a single-page app. It's a reasonable compromise, but we can do better.

With tools like server-side or snapshot rendering, we can take two seemingly opposed workflows and unify them in a way that gets the best of both worlds. To start, however, we need to better understand the problem—to dispassionately look at what we've lost without noticing, and conversely, what we now have to gain.