I think if you’re using SPA frameworks to create static HTML web sites, you’re probably doing it wrong.
If you’re creating an interactive and non-trivial web application that also requires some sort of external API communication and therefore JS, SPAs definitely have their place.
Sure you can use a server-rendered framework, but there are pros and cons to both. I think being anti-SPA just for the sake of it is kind of dumb
If you’re creating an interactive and non-trivial web application that also requires some sort of external API communication and therefore JS, SPAs definitely have their place.
I think this goes unmentioned in most discussions, but it is most likely the reason why SPAs became popular. People had their tradition webapps that run on a server and output HTML. Then the demand for interactivity and all sorts of fancy UI workflows appeared. So they started scattering but of logic on the output. Often called the views. At this point the application was split accross the server source and the served HTML. This was messy and weak in terms of design. All the effort organizing code in a server in a certain way, only to put crucial parts of the application under a completely different set of operational requirements.
It then started to make sense to create a clear logical division line. Define whatever logic is to be implemented on the server and put it behind a rest API. The UI could then be developed completely separated from the server, all it needs to know is the API spec. Which could even be agreed before hand.
SEO has always been a deal breaker, and frankly, had such concern not been there, I think outputting html documents from the server would be a relic by now. Not that I particularly like it, but people would not possibly be bothered.
I’ve written countless tiny SPAs even before the acronym became popular or even was coined. And I still do it nowadays as it a perfectly viable solution for many things that need a UI. For things like admin UIs that live in corporate intranets, I still think it makes perfect sense, despite the ecosystem being horribly littered with non sense and laughable quality libraries and frameworks.
Was expecting a rant but this is just a legit article talking about some cool advances for multi page app tech.
Having rich interactivity is super nice, and there’s a lot of places where SPA-y frameworks just work nicer, but there’s definitely this feeling that the MPA design space isn’t fully explored (htmx for me is the big one. PJAX of course existed before but htmx has a lot of niceties about it).
Figma isn’t going to become a multi-page app, but I do get this feeling that at least MPAs kinda default to a certain kind of statelessness that reduces weird stuff from breaking.
I think if you’re using SPA frameworks to create static HTML web sites, you’re probably doing it wrong.
If you’re creating an interactive and non-trivial web application that also requires some sort of external API communication and therefore JS, SPAs definitely have their place.
Sure you can use a server-rendered framework, but there are pros and cons to both. I think being anti-SPA just for the sake of it is kind of dumb
I think this goes unmentioned in most discussions, but it is most likely the reason why SPAs became popular. People had their tradition webapps that run on a server and output HTML. Then the demand for interactivity and all sorts of fancy UI workflows appeared. So they started scattering but of logic on the output. Often called the views. At this point the application was split accross the server source and the served HTML. This was messy and weak in terms of design. All the effort organizing code in a server in a certain way, only to put crucial parts of the application under a completely different set of operational requirements.
It then started to make sense to create a clear logical division line. Define whatever logic is to be implemented on the server and put it behind a rest API. The UI could then be developed completely separated from the server, all it needs to know is the API spec. Which could even be agreed before hand.
SEO has always been a deal breaker, and frankly, had such concern not been there, I think outputting html documents from the server would be a relic by now. Not that I particularly like it, but people would not possibly be bothered.
I’ve written countless tiny SPAs even before the acronym became popular or even was coined. And I still do it nowadays as it a perfectly viable solution for many things that need a UI. For things like admin UIs that live in corporate intranets, I still think it makes perfect sense, despite the ecosystem being horribly littered with non sense and laughable quality libraries and frameworks.
God, I hope so.
On the other hand, the cure might be worse than the disease, if it means more complexity to browsers to make MPAs behave like SPAs…
TIL about service workers and then shared workers. That’s fun!
Seems like there are more and more anti-SPA articles popping up: https://github.com/taowen/awesome-html/blob/main/README.md#reflection
Was expecting a rant but this is just a legit article talking about some cool advances for multi page app tech.
Having rich interactivity is super nice, and there’s a lot of places where SPA-y frameworks just work nicer, but there’s definitely this feeling that the MPA design space isn’t fully explored (htmx for me is the big one. PJAX of course existed before but htmx has a lot of niceties about it).
Figma isn’t going to become a multi-page app, but I do get this feeling that at least MPAs kinda default to a certain kind of statelessness that reduces weird stuff from breaking.