Just seeing the thread frequency of anti-SPA stuff on HN makes me shake my head. I don’t get the viscerally negative reaction. I think people are pidgeonholed in their jobs to whatever framework someone picked and they feel powerless to change it and it’s the wrong tool for the job, I don’t know. I’ve done everything from manually crafting http packets to SSR to SPAs. Our current apps are spread out between basic SSR stuff, Blazor, Angular, React/Node, and so on. I’ve yet to sit down and have a (pardon the word usage) temper tantrum over any of these. I’ve had to poke my head in and maintain each thing at least a little bit. Nothing is going to be perfect, and requirements changing means every N years you need to re-evaluate not just the FE, but the architecture and inter-app communication strategy, caching mechanisms, etc etc.
My negative reaction to SPAs is as a user, not a developer. There are so many places where SPA behavior runs counter to my intuition as a user (breaking the back button being the single most glaring issue) that I just don't like them in general. Sure, all these places _can_ be fixed with enough code; but they shouldn't need to be. Unless the application is one that clearly benefits from being implemented as a SPA, it shouldn't be one.
You can see this broken behaviour in the revamped Play Store website. It makes you wonder whether no one at Google felt this was a problem or just didn't bother to fix it.
I've had at least as many WebApps I've used built with JSP or ASP et al that broke back via unrepeatable POSTs and server side state as I have with SPAs.
While I agree that the back button _should_ work in an SPA, it's common for it not to. And it's common for other functionality to break. It's not hard to fix that and, for a well engineered SPA, such things typically do work. However, it _is_ extra work and it _does_ get missed. As such, SPAs tend to have more issues than non-SPAs. As such, as a user, I tend to prefer non-SPA implementations unless there is a strong reason that the SPA makes more sense.
If it is more common for functionality to be broken in an SPA than in a non-SPA, then that most certainly _is_ a valid argument against SPAs (from a user perspective). It's not an argument that all SPAs are bad. Rather, that I prefer non-SPA implementations because I can generally assume that it will have fewer bugs/annoyances in using it.
Why not? "You have to reimplement a huge amount of current and future behaviors that just work for MPAs" is definitely an argument against SPAs. That's extra work, extra potential for bugs, extra potential for accessibility problems.
It sort-of is if bad developers are less likely to wreck havoc with MPAs. Also, I don’t think that back-button breakage automatically indicates incompetent developers (although I tend to swear at them).
Not only is it not implicitly SPA behavior, as you say, good back button behavior design is actually hard in a app setting. And you can’t generally “get it right” — no matter what you do, in a sufficiently complex scenario (which… that’s why you built an SPA, right?) users will disagree about what the back button should do!
Generalized anti-SPA sentiment is silly. Saying “bad implementations correspond with SPA” is true but also silly because there’s not as much to get wrong in non-app settings which admit a “traditional” approach. It’s like the xkcd observation about heat maps and population density.
Personally, I have a negative reaction because we have an app that is used regularly by only a couple hundred users, developed by three programmers. The move to even a partial SPA with modals took forever, and we already had a completely unnecessary microservices architecture for potential future scaling that we still have never needed after 10 years (decisions I rallied against, but I was out-voted).
Now we have an app that we depend heavily on, where more than 90% of the processing is just 10 different Rails apps chatting with each other on the same machine (all talking to the same database server, of course), 90% of bug fixes are related to the bespoke SPA architecture or microservices (where operating without caching is impossible for performance reasons, but caching is constantly causing problems), modals behave really weirdly on mobile, we spent months just re-implementing things that just worked out of the box with the MPA, like history and sharable URLs, and every single new feature has loads of more care that needs to be taken.
A lot of this could have been avoided by going with a proper framework, or doing things the right way, or doing more research, but it also could have been avoided by just keeping our boring web app boring, and not jumping into trends that can't reasonably be maintained at our scale.
I see the value in things like SPA and microservices, but I've personally seen the pitfalls in doing them just to do them, and being unable to reverse the decision once it's already happened, because the real pain didn't become apparent until much later. A lot of people might have the same experience.
Every day staples like browsing history, middle click / control click a link to open in new tab, back function, forward function, bookmarkability of specific "subpages" (in quotes, because SPA) are the first things to fly over board in 90% or more of SPAs, which do not have to be SPAs in the first place. Then developers either ignore all of those things, living with the illusion, that this is not impacting UX, or they have to introduce even more dependencies, that aim to fix those very basic things, which by default are broken.
This is one of the main criticism I have for SPA. If you go SPA, it is your responsibility, to make it work at least as well as a traditional website.
The other criticism is, that I expect to at least have a noscript block, telling me about a website not working without JS. And not some nonsense about my browser not being supported. No, it should admit, that the website was created in a way, that does not work without JS. It should be honest. But that is often too low level for SPA frameworks, so that the devs of the website cannot be a*ed to build that into their SPA. They throw around "web components" (actually react components, or any other framework components, because often you cannot copy paste them into another framework, which is not based on the framework, you implemented them for, because they are not standardized), but are unable to include a simple noscript tag.
Basically most SPAs introduce JS as a must have dependency, but if I allow it to run on the page, I first have to trust some random code, and I will have opted into high CPU loads for things I do not need. How often I have experienced 100% of a core being used just by scrolling or for some silly animation no one needed or some hover effect. No one is testing these sites properly or speaks up in those organizations about the unprofessionalism that are apparent in the resulting websites.
Some websites manage to get it right and to make everything work, probably, but usually I just close the tab, when again I only see a white screen with nothing on the page, instead of going through the pain of allowing their 10 CDNs to actually make it work, so I am not so likely to see that SPA, which does everything right and allows me to use an SPA like any normal website.
> used regularly by only a couple hundred users
> completely unnecessary microservices architecture for potential future scaling
It sounds like the problem wasn't architectural decisions at all. The problems listed are from engineers trying to build for growth that didn't happen. You can probably complain about those because they're your bailiwick.
The root cause is not the engineering side of the house, though. What happened to the predicted growth? A decade ago?
Every project here is skunk works. It wasn't made this way in response to growth predictions, but developer fancy. Our entire staff of programmers has never exceeded 5.
I wonder how many other hypergrowth stage startups besides my own are currently in a state where "legacy" codepaths are handling 90%+ of the bulk traffic while developers spend all their time on the other 10%.
I don't disagree with you in general, but I don't think it's fair to characterise the sentiment as purely simply anti-SPA.
There's a lot of people that dislike the SPA-as-default movement, where simple websites could be written in a more traditional manner. Add that with a lot of people that dislike the fact that native applications are being replaced by lower-performance web-tech ones.
But we still see a lot of love for PhotoPea, for example. And I don't think anyone with anti-SPA ideas believes that things like Google Maps and Google Docs should be rewritten as SSR or something. And even the Electron haters admit that VSCode is a great piece of software.
The HN hivemind hates JavaScript, mostly because they believe that complexity on the web is a problem self-inflicted by eager "framework devs" continuously chasing the "new shiny", which in their mind invalidates any legitimate engineering credibility or progress.
I don't care about the frameworks. I hate JavaScript because it is a security (unintentionally, and therefore intermittently) and privacy (intentionally, and therefore constantly growing) problem. And because it's necessary for more and more pages that work fine (the exact same way) with HTML and CSS alone.
My aversion to SPAs is due to working with non-SPA tech in the past. While portal systems got by with little need for JS for anything other than client side validation. The sever would work the business logic and render a view. This was fast, simple and understandable. SPAs require tracking state on the client side, and probably on the server side. Then you add SSR which often dictates your server side tech (mostly Node). Now I can’t use Go or Java.
As a result I have a complex build and deployment process (relative to templates packed away in a Jar) for little velocity benefit.
You're not alone. SPAs have their place, they're not alternatives to fully SSR pages - they're simply different. There are other examples of such visceral reactions here, for example K8s.
I personally don't bother discussing these things anymore here as a big portion of the HN crowd just dislikes it and there isn't much left to reason about despite having countless examples of nice implementations around the world.
I share your experience as well. Sometimes a SPA doesn't make sense, and others it may be the only viable long term solution to keep things maintainable.
I just use whatever makes sense for whatever problem I'm trying to solve
I just hate the Javascript monopoly and can't wait for another option to dethrone JS with another more sane language through Web Assembly or some other meant.
> Just seeing the thread frequency of anti-SPA stuff on HN makes me shake my head. I don’t get the viscerally negative reaction.
In general, commenting as a medium is a breeding grounds for dissent & doubt. Some because thatcs natural, that a stance attracts the anti-stances, serves as a place for contrast.
There's a lot of general anti stances that can just never ever be dealt with & killed though. That's an issue, imo anstructural one: if someone mentions docker you bet your ass three people will chime in to ask why docker, can we do without docker?
We're finally no longer having to endure the same endless griping about how awful pulseaudio was, we've been through the conversations enough times & know the refutations & enough people enjoy the vastly-more-powerful and user-configurable than all alternatives capabilities it grants. And pipewire iterated & refined, somewhat proving the concept & api was good enough & worthy. Progress eventually shined theough. But other tech still is beset:
BTRFS still attracts wide manners sof casual slander. Systemd feels like it's turning the page, that we're starting to route & rebuff the endless endless tide of complaints & griefing and sometimes there can be peace when systemd gets mentioned somewhere, but there's still a sizable chance any give little systemd mention turns into a slugfest.
Each tech has to endure years & years of it's haters. The haters have more time & energy, & Bullshit Asymmetry Principle makes just asking a short disruptive question blow up into a vast fog of disinformation & nonsense back & forth. Doubt is just, structurally, easy & cheap, & hard to escape from. It's successful memetically in propogating, in confusing, in disuading. The shouting class has a huge advantage. Doers & believers have much harder jobs & their vigilance & it requires careful finess to cut clearly through bullshit without getting too much on yourself.
> I think people are pidgeonholed in their jobs to whatever framework someone picked and they feel powerless to change it and it’s the wrong tool for the job
Yes for sure. The web has heavily undergone heavy industrialization, with jquery & backbone kind of warm up acts, young adult years, then a rapid rapid acceleration of expectations & demands, more formalized tools, more deliberated architectures. People miss the simpler stringing shit together. And there's tons of concerns we've had to start accepting in, as we grow big, as we raise expecations & add developmemt pressures. You point this our yourself:
> Nothing is going to be perfect, and requirements changing means every N years you need to re-evaluate not just the FE, but the architecture and inter-app communication strategy, caching mechanisms, etc etc.
I also think, the web used to be a cross-roads of different languages & technologies. I've always championed & celebrated the rise of JS, but JS uber alles (over all) was never my desire. Even within JS, we're only just starting to see some re-diversification & re-exploration in a an after-React world; we'd really monocultured out & a lot of older princples (url routing, rest) got kind of kicked over, unmooring the platform from it's roots & things that made it hackable & legible. We're both semi-monocultural, but we also dont bundle in all the answers, to the many facets that need to be considered, and there's less other people trying other ways in this mid-industrailizarion phase, fo learn from & pluck easier ways of doing from.
> We're finally no longer having to endure the same endless griping about how awful pulseaudio was, we've been through the conversations enough times & know the refutations & enough people enjoy the vastly-more-powerful and user-configurable than all alternatives capabilities it grants.
This reads like someone who wasn't around for the pulseaudio switch. I remember when it was first introduced to Ubuntu: It was actually bad and the complaints were warranted. Audio lag and drops (over wired headphones and speakers of all things, not bluetooth like might be expected), where the only fix available was to switch back to just alsa. Over the following few Ubuntu releases it steadily became more stable and actually useable, hence why the complaints disappeared - there no longer was anything to complain about.
If systemd is also reaching a turning point, it's because either the developers or distro maintainers are finally listening to users. For example, on Ubuntu, the default for KillUserProcesses is now "no", so screen/tmux/etc won't get killed on logout. This was one of the major complaints with systemd for a long time, the developers changing decades-old conventions and pushing it onto everyone, then saying those programs had to change to work with systemd. What's happened instead is systemd is being made to adapt to those conventions, so complaints are slowly going away.
Imo it was still an overloud minority with problems. Online complaining was totally single-issue, with few of these agents able to also sing the virtues, which were many & immense. Pavucontrol was and is unparralelled in the world. Last, the bitterness never quelled. There's still a vocal minority of Pylse haters. But they now know they'll get shut down & taken to the cleaner. It's also well known that Pulse wasnt even to blame for a vast vast number of the issues- device driver bugs had to be filed & the kernel had to actually start working as advertised. Yes it's a hard experience having tbings not work. But to enforce strict conservatism, to be so resistant & dissentful of progress: it's treasonous what these people do, it's treasonous to so lopsidedly spread only the bad, so loudly & peristently. Even when it was a problem. That it has taken well over a decade of enduring the griefing, that's ignoble & unconscionable.
I think there definitely is some tugging towards perfection that has to happen, sure. Some of it is users lives getting better. But I also think there's a huge resistance to change rooted in the human heart, & some people will drag us all down for a vrry long time over anything that doesnt meet their bias, anything remotely uncomfortable, they'll refuse to see good, or they just have negative biases anyways, have already drank enough of the haterade, become witting or unwitting parts of the shouting class mob.
Hello folks and welcome to round 986 of the Least Interesting Conversation on The Internet. If you're just joining us, SPAs are great when they're necessary and MPAs are good too. And that's the game. The series stands at 986 ties. Thanks for tuning in and we'll see you again tomorrow for rounds 987, 988, and 989.
I don't know how many times I can read the same article from a different (or same) author. They're apples and oranges. Scroll position restoration is really the only thing that has ever given me problems in an SPA. Really, come up with a browser model that can restore my scroll position when I hit back and I'm good.
The current SPA vs MPA debate is conflating multiple things, when really I think the current trend isn't a move away from SPAs, it's a move towards server side rendering. Server side rendering is completely compatible with a SPA architecture, thats exactly what tools like Hotwire/Turbolinks and Livewire are doing, and in many ways makes it easer and more light weight.
I believe the current frustration is with having to build APIs as a bridge between your backend and frontend with many of these JS SPA toolkits. With a server rendered "html on the wire" type architecture you don't need to build flexible apis. No need to plan ahead what you need, no more separate API authentication (at an object level), fewer moving parts in your stack.
I think the future (for a large subset of website/apps) are frameworks that take a "hybrid" component approach, where you are defining in one place your sever and client code. If you open up a simple automatic bridge on the component level between back and frontend you remove an awful lot of leg work from building a site.
There is always going to be a need for all these different architectures though, there will never be "one true solution".
(Disclaimer, I'm building a hybrid component toolkit called Tetra http://tetraframework.com, so I'm somewhat biased)
remember the good old days when desktop applications were common?
to me, creating an SPA feels exactly like writing a desktop app.
i have a backend that does everything i need for a server, and i write a client, that accesses that server through its API. it's very clean and easy to manage. in my case i haven't been doing any backend coding for half a decade, because there is nothing left to be done. i just write client after client after client that does whatever is needed, using the backend as storage for state and data. it's so easy now. i can write multiple different clients that access the same data. i don't even have to write browser based clients. i can actually write true desktop clients, and they too are able to access the same data through the same API. need a mobile frontend? no problem either.
in fact even for applications where an SPA is supposedly not suitable, i am still going to make it an SPA because otherwise i'd have to create a new backend instead of reusing the one i already have.
so for me an SPA is now the cheapest, most efficient way to build any webinterface.
> I’ll go for the more performant solution, even if it’s awkward or unintuitive.
He said the quiet part loud. D'oh!
If the APIs being called are slow as shit, your SPA won't be any faster than just refreshing the entire page. Actually, you have a new problem, since unless you add loaders/skeleton components, it will look like nothing is happening in the app. This is what has happened on every SPA I've worked on.
Hope this kind of thinking becomes the norm! There are different tools for different problems, and SPA-like architectures are a good fit for a bunch of hard problems.
As much as I agree with you, I don't think it will. Unaware identification with the mind is rampant and black-and-white thinking as a consequence as well. It's going to take a long time until these patterns resolve slowly.
I don’t like any SPA email clients I was ever forced to try, for example.
I don’t think email should play games with me and have latencies selecting and editing text, for example.
Microsoft’s Outlook.com is terrible in this regard, for example.
I can see where entertainment content involving mixed media would be a perfect candidate for an SPA.
The problem lies in an SPA-first approach.
When the tools and the dev training and code boot camps churn out SPA developers, the world is a nail and they have a hammer.
I also don’t have any of t he issues the author refers to regarding state and rehydration because I never bought into the kit and caboodle the allegedly low-level performance-obsessed author seems to imply is necessary for a multi page application.
So are there any good resources on how I should decide whether to use an SPA or an MPA for specific use-cases? I know both has their own strengths and weaknesses but it feel like a lot of sentiments here are too polarizing.
Ofcourse SPAs will always be around. In most programming, there are no concepts of "pages". Sure you have windows and dialogs and sections but all those elements maintain state.
The controversy between SPA and MPA is simply due to the fact that HTML and the World Wide Web was never designed for dynamic applications in the first place. It was designed to serve static, linked resources.
All of the controversies in web development, and the hundreds of differing frameworks each with their own opinions on the Right Way To Do Things (tm) is the result of attempting to fit the square peg of dynamic application development into the round hole of web design.
MPA paradigms attempts to match Web concepts as they were intended, while SPA paradigms attempt to design programs are they are designed with other toolkits, languages and environments (while not being truly compatible with web)
This guy lost me after listing his biases. If your approach or the technology requires you to work at that low of a level, then we're doing something wrong. We should be abstracting complexity away, not depending on being knowledgeable of the inner working of things, like browser specific tricks (unless necessary).
Who do you think is going to successfully abstract complexity, if not the people knowledgeable of the inner workings of the underlying platform?
Those people age and die, as well; Don't want to find ourselves in the position of high abstraction that nobody living understands anymore. Therefore it's vital to the health of the techosystem that some people approach it from the bottom up.
All abstractions are leaky, some more, some less. Knowing what stands behind the abstraction is usually very helpful, even when most of the time using the abstraction you don't have to think about it.
I say pick your battles, some things you use way more than others understanding the inner workings of your most used is very helpful, you cannot know it all!
If we renamed "SPA" to "using a framework for the frontend" we may be able to stop having so many of these discussions. What is a "page" in an app like Tiktok ? Is Tiktok a SPA or just a single page with an app inside it ?
Not really, we can't. You can still use a framework for the frontend in an MPA website (and you can have an SPA without a framework, although that's rarer), so the distinction still makes sense.
FYI: Tiktok seems to be an SPA with routing and SSR.
