For 90-95% of applications, a single page app architecture with a front-end JavaScript framework running a bunch of application code and rendering output is overkill and you could write the same app in half the time using server side rendering.

HTML rendering, form handling, etc take up a lot of time in the backend too. And with the interactivity that is expected now for many pages (forms just as an example), you end up having to duplicate a lot of things on backend end frontend. And you end up using a framework on the backend too, because you really don't want to hand roll all the routing, templating and form handling. You don't. Trust me.

As long as you are comfortable with a JS stack (or have specialized devs for that) and have a good way of server side rendering figured out, I don't think an SPA incurs a big overall tax.

As an additional plus, there can be a lot more decoupling between frontend and backend work. You can stub out the API and work on the frontend independently in a much cleaner fashion.

The amount of time saved in developing services and front-ends over a server-based system is so significant as to offset any of the complexities mentioned here.

The speed of development, the ability to rapidly change requirements, to adapt to stakeholders wants and needs...all are supported by the service+SPA model.

And tooling is coming in many forms to support this pattern, so it's not going anywhere.

I can give examples of a lot of things that SPA's can't do, that's not the point.

I also don't think, you should either build everything on the backend or everything on the frontend, I consider both approaches to be equally bad.

SPA's do not help split responsibilities, I can easily give the SPA a low level Data API and start implementing data processing functionalities in the frontend.

SPA's don't help build services, good frameworks do.

SPA is a religion, cause it states 'Single Page'. What if I want to have an application with 2 or 3 pages just because it doesn't make any sense whatsoever to cram everything into 1 page? What if I can render a lot of stuff on the backend and be 100x more efficient and provide far superior UX?

I had a colleague once who wanted to do everything on the client side, he said that the SPA is the way to go. He got 6 months to prove his approach is good. He failed. His application was both slow as hell and nobody on the team could maintain it. So after he left it took me roughly 2 months to implement what he had in 1/5th of the code.

I've seen plenty of applications that could have easily been a collection of server driven pages broken into an api and spa. I think it comes down to a few things where SPAs are great.

1. Programmers padding their resume. react looks more marketable that any server side templating technology

2. fomo, what if later we want to add something that needs it

3. seperate api/frontend teams, spas make seperating responsibility easier. two seperate codebases.

of course it has its downsides

1. you're maintaining a communication bridege between two different applications. This entails a context switch if you're a developer hopping back and forth.

2. more failure modes to handle. Only so many things can go wrong loading a page. If an SPA breaks, it can render the entire page unusable. You also need to have error. handling code for inputs on both your frontend and backend.

3. large file sizes to download. This one has been beaten to death but it still holds true.

Ive personally found a nice middleground with phoenix liveview. Its slightly more work than a tradtional page driven app while giving me teh ability to create all the features I was being asked for that before would have warrented an SPA. I hear livewire and stimulus reflex are great too.

Additional logic tier: exactly the opposite is true. A SPA allows to get rid (almost) completely of the logic on the server, leaving there only a shallow layer of services. While traditional web applications always had the problem of a complex logic layer on the backend, with in addition the need to manage complicated interactions happening only client side (because even traditional web applications couldn't afford an entire page reload for simple things like reordering a table, displaying an error message, etc.). Part of the logic had to be replicated on both sides, with all the problems that it creates.

Data synchronization- again, given the fact that the entire state of the application resides only on the client and is rendered only by the client, data synchronization becomes trivial- it's just a matter of calling some backend service to store or retrieve the full state.

In short, the problem with traditional web apps is that they've always had the need to manage a state on the client as well as on the server; and the client's state was lost at every page reload, or either had to be sent to the server with some hack to be restored after the page reload. A nightmare.

What I mean by that is that the way we learned is that the old/wrong way (php style templates) mix front end and backend development, and data with formatting. It's better to have data available through rest APIs and then consume it from something. Which is mostly true if you plan on being available in a reasonable way from smartphone apps, etc. but of course that means that your website should also be a client capable of working as similarly as possible to a mobile app - there you go, SPAs.

We need to find a way to keep those benefits without the bulk of current SPAs. But SPAs appeared for a reason, and it would be wrong to ignore why it happened. Being able to have front and backend devs working in parallel is a benefit, being able to server your content to several frontends is a benefit, etc.

(And if you're thinking "these people don't need apps anyway", the reality is that clients demand to have them - even if it's only so they can bother users with push notifications or collect data, they do ask for them).

SPAs bring back the client-server architecture we had before the web. you build desktop clients that consume server-api's.

server-side html generation now feels like cruft and an awkward way of building applications.

The average SPA is not only written to experience zero latency but are poorly written from an efficiency perspective. They are often doing tons of procedures under the hood in order to support generalized programming when in actuality they could get by with a lot less framework code (Svelte in part demonstrates this in a positive way). Programmers waste so much time figuring put frameworks that they shirk proper exception handling, handing off complex tasks to the server, or giving the user cues as to what to expect.

Most SPAs don't even need to be SPAs. If all the meaningful state belongs on a server then the app is better off being a traditional web site with progressive JavaScript enhancement. Not only does that free frontend code to be more UI centric but it also means JavaScript wouldn't be required. It amazes me how many blog sites don't work at all with JS turned off. That shouldn't be any more acceptable than it would have been to implement a blog entirely in Flash back in 2005.

It is much faster to train people on a combo js+css framework rather than training someone on backend languages, databases, queues, authentication, scaling + html & css for server side rendering.

The other argument is that frontend developers are looking for SPA work because they see SPA work everywhere. There's an element of everybody having to go with the flow...

SPA create a polarization between devs whereby they're either front end or backend. Full stack devs are slowed down compared to tools like Hotwire/Turbo, Liveview, HTMX, etc.. Furthermore you need a huge stack of tooling to make pages work and lots of javascript code needs to be downloaded to make most standard SPAs work today. Not to mention having to render html on the backend in a slower and more complicated manner than using any of the more recent enhancements of HTML that provide caching, high speed download out of the box.

You get a much more limited range of languages and libraries to work with. You get to use overcomplicated build and deployment processes with ever-changing tools. You get to reinvent the wheel if you do want to use things like URI-based routing and browser history in a sensible way. In many cases you are going to need most of the same back-end infrastructure to supply the underlying data anyway.

Also, it's tough to argue the SPA approach is significantly more efficient if it's being compared with a traditional web app built using a server-side framework where switching contexts requests exactly one uncached HTML file, no uncached CSS or JS in many cases, and any specific resources for the new page that you would have had to download anyway.

Of course some web apps are sufficiently interactive that you do need to move more of the code client-side, and beyond a certain point you might find it's then easier to do everything there instead of splitting responsibilities. I'm not saying everything should be done server-side; I'm saying different choices work for different projects and it is unwise to assume that SPA will be a good choice for all new projects.

Thankfully, I'm not a frontend developer. Was just toying around here and there. Maybe it was just that I sucked at simple things.

Still, for now I believe many (not all, of course) fancy SPAs are a probably a waste of otherwise productive time. There is already a browser, and it does things well. Having something that would allow for smaller documents is a good idea, of course, and some eye candy for transitions between different documents would be neat to have, but every site doing this for themselves feels just plain wrong to me.

Exceptions - e.g. for heavily API-centered systems - apply, of course. If a webpage is one of half a dozen client applications that consume the same API, then SPA could be a sane way to do it.

Despite that (or because of that?) I was a hater on SPAs throughout most of the 2010. I know agencies that did PHP/ColdFusion/ASP work before 2005 or Ruby on Rails work 2005-2010 who found their customers were asking for SPAs and they just couldn't sell the traditional sites anymore.

I think it's a situation that people blundered into. Web forms weren't originally designed to make complex applications. At the beginning you typically made a web form and then had the form POST to a cgi-script at a different URL. (e.g. Back them you had a static HTML page and a separate Perl script in your cgi-script directory)

If you wanted to validate the form you were in trouble because doing that on the back end required the script to be able to display different pages depending on the content of the form, and ultimately that requires a back-end framework that separates HTML content from the exact URLs it is served as at.

Ruby on Rails was an example of the kind of framework that addresses that -- what you get when you think systematically about these issues. Around the same time Microsoft was coming out with ASP.NET which had some brilliant ideas but didn't understand that you might need to display a different page at the same URL, then they got ASP.NET MVC that threw out all the good things from ASP.NET. On top of that there were many frameworks and apps that did very bad things keeping session state on the server that led to major bugs.

The SPA answers many of those issues by having (medium term) persistent state on the front end rather than having to have something that manages that state cooperatively between the front end and back end.

I did a lot of home automation and related work recently and that got me looking at cross-platform GUI frameworks and I found that these were uniformly awful. For instance if you are working in Python you can use tkinter or GWT but the Python side isn't really documented so you have to look at the Python docs, source code, and the tk or C or C++ docs to guess what you're supposed to do. I kinda liked JavaFX but it is being phased out...

I got back into programming React-style SPAs for work, and I finally got over my hate for SPAs and (particularly) Electron.

Yes, it's annoying to install 20 crapplets on your machine that are all 30 - 32 MB in size, but just try using any other x-platform gui framework and Electron, React-Native and other web derived things look good.

I’ve been doing this for 15 years, and if I’ve learned anything it’s that developers can figure out ways to abuse anything.

What the author is really getting at, I would guess, is that front end dev is awful, due to this weird combination of the Blub issue and a historical trajectory that has caused many problems.

The blub issues is mostly simple enough to pin down. Experienced programmers know that JS is an awful language. But there’s also a tooling or SDK “blub problem”. For example, compare npm and webpack vs gradle and javac (not to defend the Java ecosystem, but it does get some things right, or more right than others).

More idiosyncratically, there’s this historical arc of encountering fundamental problems, and trying to solve them within the current constraints of the web, rather than perhaps waiting for the web to standardise and evolve. This seems to be a mixture of lack of experience outside of this ecosystem (a bit like Blub) and, for this and other reasons, fixing problems “in your app” that should be fixed in the fundamental infrastructure of the web. It feels like technical solutions to social problems or, to use another metaphor, we are patching downstream what should be fixed upstream... if you build a house on sand, it will never be robust, no matter how many layers of infrastructure you add. That’s where the complexity arises.

It’s an enlightening exercise to step back and ask how you would build SPA infrastructure if starting anew. You certainly wouldn’t use a language like JS, you certainly would want to provide visual design tools as far as possible, APIs would be replaced with standard protocols, and probably you’d use a relatively small XML for layout. So perhaps only the HTML is anything like what you’d use. There’d be no transpilation, no webpack, no polyfills, no CSS, no JS.

In fact, what you’d end up with would look remarkably similar to the dev process for a Java applet!