State is hard: why SPAs will persist
nolanlawson.com
nolanlawson.com
that and the fact that SPAs, not intrinsically, but often are so sluggish
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.
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.
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.
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?
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.
As a result I have a complex build and deployment process (relative to templates packed away in a Jar) for little velocity benefit.
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 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.
Everything else on your list is perfectly fine.
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.
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.
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.
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.
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.
so yeah, SPAs will persist.
The balance has shifted away from SPAs - https://news.ycombinator.com/item?id=31459316 - May 2022 (444 comments)
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.
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.
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)
Ability to point to specific place in the UI of a desktop app with a short link would be so great.
Although we got something similar or even better with Ctrl+Shift+P in VSCode.
if you don’t have a good sdlc[1], build one. if you’re in an environment where that is impossible, change environments.
there’s never been a better time than right now to build software of all sorts.
no excuses.
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.
FYI: Tiktok seems to be an SPA with routing and SSR.