8 ms·

State is hard: why SPAs will persist

86 points by DeadNeurons 4y ago

GaveDrohl 4y ago
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).
- oblib 4y ago
  It made sense to me, though he maybe could have offered some clearer examples of SPAs and MPAs that are better suited to those approaches.
- hypertele-Xii 4y ago
  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.
- legulere 4y ago
  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.
  - dustymcp 4y ago
    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!
- deleted 4y ago
  [deleted]
- Vinnl 4y ago
  He used to work on the performance of IE/Edge, as well as PouchDB, so that explains his biases.
tmcw 4y ago
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.
- Mo3 4y ago
  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.
dang 4y ago
Recent and related: The balance has shifted away from SPAs - https://news.ycombinator.com/item?id=31459316 https://news.ycombinator.com/item?id=31459316 - May 2022 (444 comments)
polote 4y ago
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 ?
- ratww 4y ago
  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.
planarhobbit 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. 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.
henning 4y ago
> 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.
- dustymcp 4y ago
  Or you design your components around this concept, its not really a hard problem to solve.
  - henning 4y ago
    Thank you for demonstrating that solving a problem you don't have creates a problem you definitely do have.
nathants 4y ago
everything is fine. people need to chill. 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. 1. https://news.ycombinator.com/item?id=31546615 https://news.ycombinator.com/item?id=31546615
samwillis 4y ago
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 http://tetraframework.com, so I'm somewhat biased)
- em-bee 4y ago
  the API is exactly why i love SPAs. 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.
miiiiiike 4y ago
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.
bitemealienboi 4y ago
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)
- scotty79 4y ago
  SPA often has pages. And pages are actually wonderful concept that should have migrated to desktop apps but it didn't 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.
slategruen 4y ago
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.
iostream24 4y ago
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.

86 points by DeadNeurons 4y ago

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

oblib 4y ago
It made sense to me, though he maybe could have offered some clearer examples of SPAs and MPAs that are better suited to those approaches.
hypertele-Xii 4y ago
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.
legulere 4y ago
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.
- dustymcp 4y ago
  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!
deleted 4y ago
[deleted]
Vinnl 4y ago
He used to work on the performance of IE/Edge, as well as PouchDB, so that explains his biases.

tmcw 4y ago

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.

Mo3 4y ago
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.

dang 4y ago

Recent and related: The balance has shifted away from SPAs - https://news.ycombinator.com/item?id=31459316 https://news.ycombinator.com/item?id=31459316 - May 2022 (444 comments)

polote 4y ago

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 ?

ratww 4y ago
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.

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

henning 4y ago

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

dustymcp 4y ago
Or you design your components around this concept, its not really a hard problem to solve.
- henning 4y ago
  Thank you for demonstrating that solving a problem you don't have creates a problem you definitely do have.

nathants 4y ago

everything is fine. people need to chill. 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. 1. https://news.ycombinator.com/item?id=31546615 https://news.ycombinator.com/item?id=31546615

samwillis 4y ago

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 http://tetraframework.com, so I'm somewhat biased)

em-bee 4y ago
the API is exactly why i love SPAs. 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.

miiiiiike 4y ago

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.

bitemealienboi 4y ago

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)

scotty79 4y ago
SPA often has pages. And pages are actually wonderful concept that should have migrated to desktop apps but it didn't 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.

slategruen 4y ago

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.

iostream24 4y ago

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.