6 ms·

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 i

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.

vdnkh 4y ago
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.
- deleted 4y ago
  [deleted]
- drBonkers 4y ago
  What would be necessary to cut JS out of the picture and use a technology like web assembly exclusively instead? Please excuse my naivety.
- HWR_14 4y ago
  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.
RHSeeger 4y ago
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.
- gorono 4y ago
  Back buttons work on SPAs
- robertoandred 4y ago
  Breaking the back button is not SPA behavior.
  - hansvm 4y ago
    It's a common behavior in SPA that's uncommon elsewhere. Kind of like how buffer overflows aren't C behavior.
    - andrewstuart2 4y ago
      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.
  - icedchai 4y ago
    It’s very common in poorly engineered SPAs. “Built in” browser functionality often has to be reimplemented.
    - Mo3 4y ago
      Bad developers are still not a valid argument against SPAs.
asabla 4y ago
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
gadflyinyoureye 4y ago
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.
outime 4y ago
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.
Taywee 4y ago
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.
- boredtofears 4y ago
  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%.
- drewcoo 4y ago
  > 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?
ratww 4y ago
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.
rektide 4y ago
> 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.
scotty79 4y ago
If that was Angular 1 I admire your patience. It felt like a such a step back crossed with layers of unnecessary ad-hoc complexity. Everything else on your list is perfectly fine.
edmcnulty101 4y ago
I don't have a problem with SPA's. 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.

vdnkh 4y ago

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.

deleted 4y ago
[deleted]
drBonkers 4y ago
What would be necessary to cut JS out of the picture and use a technology like web assembly exclusively instead? Please excuse my naivety.
HWR_14 4y ago
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.

RHSeeger 4y ago

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.

gorono 4y ago
Back buttons work on SPAs
robertoandred 4y ago
Breaking the back button is not SPA behavior.
- hansvm 4y ago
  It's a common behavior in SPA that's uncommon elsewhere. Kind of like how buffer overflows aren't C behavior.
  - andrewstuart2 4y ago
    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.
- icedchai 4y ago
  It’s very common in poorly engineered SPAs. “Built in” browser functionality often has to be reimplemented.
  - Mo3 4y ago
    Bad developers are still not a valid argument against SPAs.

asabla 4y ago

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

gadflyinyoureye 4y ago

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.

outime 4y ago

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.

Taywee 4y ago

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.

boredtofears 4y ago
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%.
drewcoo 4y ago
> 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?

ratww 4y ago

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.

rektide 4y ago

> 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.

scotty79 4y ago

If that was Angular 1 I admire your patience. It felt like a such a step back crossed with layers of unnecessary ad-hoc complexity. Everything else on your list is perfectly fine.

edmcnulty101 4y ago

I don't have a problem with SPA's. 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.