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.