I feel that this argument is pretty outdated at this point.
Most new SPAs people build use frameworks like NextJS that solve all of the big complaints.
Sure, there's plenty of old, crufty SPAs from the pre-react-router days still out there. I also dislike those apps.
I guess my point is... there was a time when you could blanketly hate SPAs and be mostly right about the category. And you could be mad at a company for even daring to try because they were very likely to screw it up. But I think we are now past that period. SPAs are now pretty awesome and fast and good!
Edit: ah, this article is from 2016. Which actually was a very valid time to hate SPAs! Maybe this is a good moment to applaud the hard work of folks at Vercel for fixing the problem :-)
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.
Two of those three are simple content sites. Why even use JS at all? I feel like we're reinventing the wheel with a ton of added complexity these days.
JS is used for fast page transitions and stuff like that, but funny enough I'm pretty sure I end up shipping less JS overall by running server-side JS.
Last I checked, a Tweet embed alone was several mbs of JS, and it causes a bunch of layout shift and loads third party resources. On my blog they're pre-rerendered and shipped statically[1]
Probably the strongest reason though is to not set a 'power cap' on your project unnecessarily. It'd suck to have to rewrite a project because you got trapped in a local maxima, which is why i always share you can have your 100 lighthouse cake & eat it too.
Comments
I feel that this argument is pretty outdated at this point.
Most new SPAs people build use frameworks like NextJS that solve all of the big complaints.
Sure, there's plenty of old, crufty SPAs from the pre-react-router days still out there. I also dislike those apps.
I guess my point is... there was a time when you could blanketly hate SPAs and be mostly right about the category. And you could be mad at a company for even daring to try because they were very likely to screw it up. But I think we are now past that period. SPAs are now pretty awesome and fast and good!
Edit: ah, this article is from 2016. Which actually was a very valid time to hate SPAs! Maybe this is a good moment to applaud the hard work of folks at Vercel for fixing the problem :-)
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.
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.
How did it?
Please give me a site in NextJS that doesnt break my browser
some that i've built recently with app router that are intentionally minimalistic
- https://rauchg.com
- https://next-ai-news.vercel.app/
- https://emoji-todo.vercel.app/
Next.js scales up and down in complexity / ambition. On perf:
- https://twitter.com/rauchg/status/1652093980958683137
- https://twitter.com/rauchg/status/1744183168541007878
Two of those three are simple content sites. Why even use JS at all? I feel like we're reinventing the wheel with a ton of added complexity these days.
JS is used for fast page transitions and stuff like that, but funny enough I'm pretty sure I end up shipping less JS overall by running server-side JS.
Last I checked, a Tweet embed alone was several mbs of JS, and it causes a bunch of layout shift and loads third party resources. On my blog they're pre-rerendered and shipped statically[1]
Probably the strongest reason though is to not set a 'power cap' on your project unnecessarily. It'd suck to have to rewrite a project because you got trapped in a local maxima, which is why i always share you can have your 100 lighthouse cake & eat it too.
[1] https://rauchg.com/2021/making-the-web-faster#next-momentum
the new Node.js website is made NextJs