The question is why? Sometimes SPAs are justified, like for a webmail, but in many cases, what is the point? For example, I see the Washington Post on the front page of NextJS. It is a newspaper, serving articles is what the web does best, you really don't need to do anything but serve static HTML files, with a style sheet if you are fancy, and the browser does everything else for you.
I agree with you, however: The WaPo has a veeeeery wide variety of endpoint devices. If they stuck to HTML + CSS it would mean an imperfect output on things like kiosk panels, public news stand displays, ebook readers etc. or needing to maintain multiple output services server side, with potentially different authoring considerations.
With their current approach, they can share one content authoring environment over an API that splits all render concerns to the consuming client.
Sounds a lot like what HTML was supposed to do in the first place doesn’t it… but not all devices support arbitrary html web browsing, nor would you want to serve a full page to most
, so the next best option (according to some) is API plus javascript client for the web side of things.
While I don’t think this path is correct, given the tools we have I do see why it is used so frequently.
> With their current approach, they can share one content authoring environment over an API that splits all render concerns to the consuming client.
Do you need an SPA for this? You have to write some code to handle different devices, I don't think it makes a lot of difference if it's being done in JS on the client side or rendered as HTML and spat out to the user direct?
Yeah :( Unfortunately, frontend developers have all specialized on building SPAs, and that's all they build now. I've tried to change this in my company, but the frontend devs resist strongly.
Being a frontend developer for years has taught me not to rely on JavaScript whenever possible. I'm not sure how can one go past the junior stage and not come to that conclusion while being honest with themselves.