Convopage
See the entire conversation
Couldn't resist the bait: I'm howling into the wind on Hacker News today about how defaulting to SPAs is a bad idea and we should stop doing that news.ycombinator.com/item?id=305334…
112 replies and sub-replies as of Mar 03 2022
Time after time, I see talented developers who are clearly operating in good faith decide to switch to the SPA route ... with the inevitable end-result of a slower, buggier product that takes significantly longer to ship
I must be missing something - what am I missing?
This is a very strong theory - sadly as an industry we've spent the past decade training up a new generation of engineers who mostly don't know how to build web applications without architecting them as an SPA
I'm seeing a lot of companies jump on SPA and related bandwagons simply because it's easier to hire for these things than it is to find "old-style" backend/frontend/fullstack dinosaurs like us.
IMO development monoculture plays a big part. React is for SPAs (you can use it in other ways, but…) and “React or not” is treated as a more important choice than “SPA or not”
We rebuilt our entire frontend for Crunchy Bridge from ground up, threw out SPA, all request response traditional now... velocity is better, product is more polished, quality is better. Not sure there was a downside.
And amusingly page response time was better as well.
Now days super happy to login to crunchybridge.com vs. feeling small nits and picks before due to SPA oddities and complexity.
HTMX kind of reminds me of Plone's long abandoned KSS.
kss.core
KSS (Kinetic Style Sheets) core framework
pypi.org
Would you consider something like Remix an SPA?
I think the React=SPA assumption will change as tools like @nextjs which have React server rendering setup for you become more popular. Being able to use a single technology for both server rendered and client rendered components is a huge advantage.
I have heard the hiring reasoning literally used (& with justification) for continuing to use React for an application that completely does not need it at my dayjob.
In other contexts, I’ve often seen “tech choice first, rationalization after” instead of requirements analysis.
not entirely unseriously, money?
In that engineers know it will take longer to build something and hence they'll get paid more money for it?
I don't know if I'm cynical enough to believe that, but I've spent my entire career figuring out how to build things faster so maybe I have a skewed perspective
I was more upstream in the guessing-what's-funding-the-companies-making-spas
Multiplatform support?
When the Tao is lost, there is goodness.
When goodness is lost, there is morality.
When morality is lost, there is ritual.
Ritual is the husk of true faith
SPAs are a ritual, their motivations lost in time
Chesterton's fence lol
Pride. And management convinced that if they can the latest cool thing, they move up the ladder.
Generating HTML for every page request has its issues, too
At work, or their own projects?
I'm talking work stuff - I'm completely in favour of using whatever you feel is most interesting to learn in a personal project
Well, this might be very subjective, but from my experience, these sort of decisions are rarely made by the engineers implementing the apps, and even when they are, the reasons for one or the other go way beyond "what would be the best technical fit".
I'm seeing a lot of companies jump on SPA and related bandwagons simply because it's easier to hire for these things than it is to find "old-style" backend/frontend/fullstack dinosaurs like us.
(With "easier to hire" really just being an euphemism for "cheaper".)
Good point, this is very true. Many are even specialist React engineers and lack a general understanding of Javascript, let alone have a good handle on client/server design.
FWIW, I think this trend is fine. The industry is growing continuously. The experts are still there, but frankly, aren't always needed. I think all this is (paradoxically, maybe) a sign that the industry is doing well, and providing opportunities for people of all skill levels.
You’re right, although there are people with that skill level doing hiring, interviewing, and architecture/design, who are then being trusted as experts by the non-technical or even more junior engineers. Maybe this isn’t a real problem but it does make hiring hard.
Because people want to claim they’re “full stack” without actually doing much backend?
Like one of the commenters says it can help organising big projects into team-sized chunks. The interface between teams then takes the form of an API. (The argument does not work for small projects of course)
resume-driven dev rings true, but secondarily:
talented developers are great at carrying out decisions, but bad at making decisions themselves. people don't weigh options or think about what they're building, and there isn't a strong culture around good decisionmaking.
You are now a wise old engineer, they are not there (yet) ;)
IMO development monoculture plays a big part. React is for SPAs (you can use it in other ways, but…) and “React or not” is treated as a more important choice than “SPA or not”
You can make good, fast, server-side applications, but there’s a ceiling to the UX, particularly around offline capabilities and more advanced speed optimisations.
I think many (myself included) have been bitten by server-side applications that grew too much client-side stuff – validation, AJAX, etc – to meet UX requirements, and it became a bit of a mess. SPAs are sometimes a solution to that.
I get that if you're building Figma, but I see so many of these things where the most complex interactive element is the equivalent of a contact us form!
People are shipping developer documentation sites as SPAs these days, I mean come on
Arguably, offline support for dev documentation would be nice, but in general I agree.
SPA for a contact form is definitely a bad choice, but there is still that concern for many that complexity may run away from them and they’ll need more in the future. A reason, not an excuse.
I'm pretty sure you can get offline support working for a multiple static page documentation site if you know your way around service workers
(Ooh... that would be fun thing for me to try to add to docs.datasette.io)
Maybe, but once you’ve got some caching, search, keyboard shortcuts, and a few other bits, maybe a frontend framework isn’t too bad?
Unfortunately I think SPAs are often chosen for the wrong reasons, the ecosystem doesn’t prioritise quality, and the frontend is still treated like an afterthought.
If you go for a frontend-heavy design with all that, it often comes out crap.
See also noSQL, although that wave seems to have subsided a bit, luckily.
I think a lot of it comes back to borrowing decisions from big organizations — SPAs require taking on a number of hard problems, and most people don't consider that the cool blog post they saw from a major tech company is backed by an order of magnitude larger team.
There can be an argument for using an SPA to be an API client like Android/iOS clients, but that only holds if a) you actually do that and b) see real advantages to not having that same client be a simple HTML templating layer.
We rebuilt our entire frontend for Crunchy Bridge from ground up, threw out SPA, all request response traditional now... velocity is better, product is more polished, quality is better. Not sure there was a downside.
I've seen some really grim, slow, buggy sites that aren't SPAs, and some really nice SPAs. Most rewrites nowadays are to SPAs where the project failed because it ran out of time and needed to keep shipping features, not necessarily because they chose to go SPA.
Plus with an SPA you can decouple the frontend and backend codebases which can be a worthwhile trade-off. You can have one backend API running multiple clients where each client "product", including your web spa one, can then make their own decisions about what to render and how.
Even just sharing lots of complex rendering business logic across a python backend and a javascript frontend is a recipe for duplication and the resulting regressions and misery.
Developer convenience trumping quality of result.
Part of learning from one’s mistakes. Organization, manageability, and readability is key. Asking yourself which tool/architecture is right for the job is wisdom. That comes from experience.
I think that's dependent on what you're used to: if you have built a bunch of SPAs before, you'll be fast at building a new SPA
My claim is that if you have experience with both MPAs and SPAs you'll be able to build an MPA faster - but seems not many people have that these days
I think some of it can be traced back a long way to when many server-side devs were v keen to position themselves as ‘proper engineers’ elevated above the ‘trivial’ HTML/CSS stuff, then when JS became unavoidably important SPAs became the way to bring in that status elevation
In the case of my company, I know that the backends are a motley assortment of SQL databases and more specialized things, so those get treated as APIs instead of integrating more directly with apps…
…and once that’s done, I think it’s easy to (mistakenly) regard server-side HTML as an unnecessary “third layer,” as something that will complicate your app rather than simplify it
The HN thread also makes a good point (I wince as I type those words): every new line of JS you add to an MPA makes it feel like a kludge to tear all this down and set it back up with every page load, and wouldn’t it be great if… — but, no, it wouldn’t
1- people think this will help them make app-like web apps
2- people get seduced by small simple demos and think it will scale up easily
Where do things like NextJS that let you build an app as if it were a MPA but then does non-reload page refreshes on navigation stand?
I think of those as a hybrid approach, and generally I'm optimistic about them - haven't built anything with one of those tools myself yet
I have seen situations where mobile teams had to fight for their APIs and were hugely relieved when SPAs started happening because it meant the API built for the web app worked for them too!
Forgetting the negative perf implications of SPA there really is something magical about only operating in one context (client). Trying to do isomorphic in the past has been a headache (Next). This is why Remix is so special and exciting to me.
upvoted.
When we knew better we did better
big if true
I understand it’s even possible to serve them real damn fast.
Well said!
I’m firmly in the server side rendered monoliths or static website generators are great club. Completely agree with what you are saying there.
For static sites I think SPAs are 100% bad. Just like Wordpress for static sites is 100% bad if you don't turn on static page generating/caching
But my default for apps is to go SPA since good 3rd-party UI components require JS and SPAs give you a reasonable way to organize code
Why heavy machinery for static sites. In addition, to position in the SERP, Google still does not look favorably on sites with javascript rendering.
But think of the boon SPAs have been to the loading spinner industry
Yeah that's true - there's a lot to be said organizationally from having those teams be able to work independently
In practice though it results in frontend teams blocked because they don't have the API they need, and backend teams blocked waiting for attention from frontend!
OpenAPI to the rescue!
Shameless plug: pyotr.readthedocs.io 🤪
My sniff test is:
Does the web app generate a unique URL for every possible state it can be in?
If yes, I don't care if it's a SPA or a geocities page
You’re not wrong. I used two SPAs recently, for a bank and Heath insurance respectively. Both were terrible UX and added nothing over a traditional web app.
Amen! But it feels like the wind is starting to blow in a different direction now, with all the attention htmx et. al is getting
Yeah that's true, there does seem to be a lot more interest in more sensible hybrid approaches now than there was a couple of years ago
You can tell the pendulum is swinging back because of the latest revolutionary feature all the hot SPA frameworks are touting: Server-Side Rendering
as a web developer, intuitively true
counter argument: mobile apps are necessarily "SPAs" in architecture
i think as with all engineering decisions, right tool for the job with sane and simple defaults
Completely agree - there are a bunch of jobs where an SPA is the right tool
But they're not the right default for every project!
Is the content on the page expected to change while the visitor is viewing it?
If yes, SPA *might* be the right tool.
If no, SPA is *not* the right tool.
essas tretas aqui que tem que rodar na bolha dev.
Quero ver os argumentos pro/contra rolando solto.
a galera vai surtar
While I agree with your larger points, I think you are missing a compelling aspect of SPA: building UI in components that combine presentation and behavior in a modular way, but also share state. You don’t need to be building Figma for this to be really valuable.
reject modernity; return to django
I don't think you are shouting in the wind. The popularity of HTMX and other non-SPA libraries are proof.
I often have shitty mobile network here in Germany, and I despise SPAs because they break in bad ways, most of the time without notice.
With a traditional application you'll see the timeout and can press f5 in most cases. With a SPA you might lose your work.
A documentation website. A blog. A news website - heck, any site that's more about content that interactivity. A "contact us" form.
Or a complex web application like GitHub, which thankfully is still way more MPA than SPA
Aw really? To me, GitHub is an excellent example of an MPA that should be a SPA, especially when working in a private repo. I use GitHub web constantly and I’m always reloading the page.
I take full advantage of GitHub's MPA nature - I frequently have dozens of tabs and windows open with different repos, issues and pages and I bounce between them all the time
Contrast to Trello, which I found far less useful since it's harder to open cards in separate tabs
I'm enjoying the new GitHub projects though, which is a well built, appropriate SPA that lives within the larger GitHub MPA - I like that pattern
Yeah I do think there are two “modes” of GitHub, consuming (mostly public) and “working” with a repo. Both have different needs
I also love things like the fast file search interface that comes up when you hit T - another mini JavaScript app embedded in the larger site
Huge fan of the VS Code SPA interface that comes up when you hit "." though
Well yeah you’re going to find a lot more Java codebases than Clojure - that’s what the masses know. You might get some advantages by building your site with pure HTML and vanilla JS but good luck hiring. The optimization problem has more inputs than bug count!