A single-page app is almost always worse than a multi-page app

"I think this is a very underappreciated aspect of SPAs. Stateful software is always more difficult to work with than stateless. The frontend state is added on top of the already-existing backed state. This requires more development time, increases the risk of bugs, and makes troubleshooting more difficult."

But the thing is, almost as soon as you have any kind of significant user input to handle (multipart forms, date pickers, autocomplete elements, conditional input elements) you are instantly dealing with complex frontend state. And then your choice is not "SPA vs plain HTML forms," it becomes "SPA vs (ad hoc jQuery tangle + ad hoc server side endpoints that know to speak to random jQuery UI libraries)."

I find the ad hoc jQuery+endpoint tangle much harder to reason about than something built with a front end framework and a more uniform API.

Of course single-page apps generally require far more development than multi-page. Of course they require more state, more testing, are slower to load, etc.

But they also do a million things multipage "apps" can't and, and therefore have the potential to provide a vastly better user experience at the end of the day.

In the end it's same tradeoff as literally every other business decision: will the resulting benefits be greater than the costs they incur?

My dentist doesn't need a single-page app for their site. Anything complex enough to intuitively be called an "app"... there's a good chance it does.

As with stacks, this is highly team-dependent. I for one do not crave for the time of constant back and forth between backend-frontend mindsets and stack lock-in because of rigid query/rendering requirements. This may not work for the author's team of mostly "backend-mindend" devs who wish for more control over output, but is much preferred for a more diverse set of members (or especially departments).

The experience was wonderful and highly recommended. I think it's perfect for small teams who are more productive with traditional/backend tech.

SPA's also benefit from static caching and serving. You do not always need to have the pages being served from your origin, but can be served from a much cheaper source like Cloudflare or even a different origin.

Is that supposed to be a downside? Just showing a 500 page isn't really a great UX, the SPA experience is probably a lot better (think preserving of unsaved data for example).

Or if you want the full power of React, Redux, AND the simplicity of Turbolinks/PJAX. You can use https://jho406.gitbook.io/breezy/ which is Turbolinks for React Redux Rails, you can build SPA without APIs, just by treating JSON as a navigational format.

Full disclosure, I'm the author and I've been trying to get some feedback on the project.

The SPA approach also helps with statefulness, because it allows you to keep the UI state on the client where it belongs. The UI becomes much easier to reason about because you're not trying to keep state of the server and client in sync. Meanwhile, the server can just be a set of service calls the UI queries when it needs data, and doesn't need to store any state about it. This directly helps with horizontal scaling where you can spin up more servers and balance across them.

While SPAs can have a larger initial Js download, they can be a lot more responsive overall because you don't have page repaints, and you fetch data as you need it.

Testing actually becomes easier because your front-end is decoupled from the backend. You can test it in isolation, and the amount of statefulness is dependent on the complexity of the UI as opposed to whether its implemented SPA style or not. An equally complex UI implemented using traditional server-side rendering will likely be harder to test in practice.

Also not sure why authentication needs to be any different with SPAs. You can authenticate exactly the same way as if you did server-side rendering.

>Let's illustrate this with an example: we're building an e-commerce site that has a list of categories. We need to update the list from time to time. In an MPA, the list is updated on every page load. That's not the case in an SPA though.

Why wouldn't it be?

>In an MPA, we can simply pass models to views and render attributes we need. This isn't the case in an SPA. We need to define data formats and implement serialization.

Not really sure what that's about either. JSON exists, and I'm pretty sure nobody is inventing serialization formats in SPAs.

>Single-page apps are much more expensive to build than multi-page apps. In most cases, there is no business reason to choose this architecture.

Perhaps this is just a problem with the particular stack the author is using, and they're extrapolating this to be a general problem?

What that means in practice is that:

1. Routing is always handled server side. The less frontend state (IMO/IME) the better. There will be the odd bit of pushState where appropriate, but no actual full-on routes.

2. Whether to render content server or client side is determined on a case by case basis. It's often easier to build HTML using whatever templating system your backend tooling provides than build a REST/GraphQL endpoint for a component to consume.

3. You can introduce React/React-style programming piecemeal to a team with varying levels of experience. Everyone on a team (with varying degrees of frontend skill/experience) can be productive from day one.

Does anyone else do this?

Should huge wizards and complex forms be constantly sent back to the server and rendered as each bit is filled in? Of course not.

But if you have a basic CRUD app with a big dashboard, create route, edit route, view route, etc., it's a hell of a lot cleaner to break up each one of these main features into mini SPAs that cleanly refresh the state on the server when moving from one function to another.

Otherwise, you're constantly making duplicate calls to ensure you've got the data you want as you really can't be sure if some previous click from one of dozens of in-memory widgets has stale or incomplete data.

At least that's been my experience working on a few legacy apps written in AngularJS and, God forbid, JQuery. At that time, an Asp.Net or GWT app would have probably been easier to maintain as the duct tape increased over the years.

Maybe React and Vue allow for cleaner architectures, but older apps were a pain.

On the other hand, there are plenty of times where a multi-page app is just fine. If that's the tool that works best for you, then by all means use it. The vast majority of users don't even perceive things like page reloading, etc. Build something useful, whatever the means are.

https://www.productchart.com/laptops/

Would the user have to chose "32 GB Ram", hit a submit button and wait for the page to reload with the matching laptops?

I hate SPAs, so much more complexity and work. In MPAs you can still use JS and AJAX for a better experience, but SPAs just have so much needless extra work and are harder to maintain. They are also frustrating to use. They can be better to use when done well, but you don't often see that unless it's from someone quite big.

I, personally, place blame on WC3 for this state of affairs, as Web components should have solved the UI interoperability problem, observed objects were dropped which regardless of what one thinks of them (I think a trie is better) would have unified state management clearly (replaced by Proxy? yeah, I see everyone using that string-only thing for state), and various other specs should have solved most of these issues, but I guess they were too busy making people leave their org over DRM, rather than making a useful, consistent, easily-produced internet. Who needs standards when all of the for-profit board members have their own un-interoperable libraries?

The complexity of state management must exist within an app. Either it's stateful server side or stateful client side.

Going away from the SPA pattern doesn't save anything in this regard.

The only unique complexity SPA brings to the table is route management, which can get confusing, and a non-trivial learning curve.

I think we could make a nice color coded calendar or almanac to celebrate these more. Maybe even create more formal holidays. I’m inspired by the Giant Man radio interview[0] I heard on NPR this last weekend. Highly recommend it, by Hillary Frank.

[0]https://www.thisamericanlife.org/351/return-to-childhood/act...

I'm no gilded dev, but 5 years back when PHP wasn't avoided like the black plague we would still need to update user interface handling these internal server errors. It's judt good design practice.

I more or less agreed/understood with the writer up to that point. Everything else past this just sounded like a argument for argument's sake.

It's understood that this can also happen in an MPA, but I think the blast radius is much smaller.

Most of the problems are solved by using Haskell+Elm+Generating the API types (sharing the code for their encoding/decoding). Testing the backend is way easier through API, and testing UI is better done with hands/eyes.

Without that second part, this is just a trite rant against SPAs.

Wrestling with this idea. Been using create react app for most of my projects that arguably do not need it. But the development is so much faster and easier to manage than traditonal html/css webpack

There are plenty of MPA's with slow first time loads for instance.

I don't agree with this article. I think its author has a significant misunderstanding of SPAs and overstates some of the potential issues. Having built both type of applications at varied level of complexity I absolutely don't agree with the notion that SPAs are necessarily more expensive than MPAs. I'll address a few of his points, but most, if not all, of his claims can similarly be refuted.

Statefulness: Few people would build an SPA on top of a stateful backend? Most SPAs query an API which nowadays will more than likely be hypertext driven (read stateless). The user authenticates, gets an access key, then serves that access key along with each subsequent request to the API that needs it. The server does not keep a session around. It receives the query, does its job in the confines of what is requested and serves back a response (likely in JSON). That's more or less it. There's very little state involved here.

Testing: Vague unsubstantiated claims. Why make backend and frontend talk to each other when mocking would do just fine.

Performance and network latency: Has anyone been using an SPA recently and had this as their main problem? If your client is incessantly polling your API, then it's a sign that either your API is not designed well enough to address the problem domain, or you need to employ a caching mechanism on the front. There's no cookie cutter way to architect an API. If your client is more likely to query and use 10 items from a collection, don't force it to make 10 requests, provide a facility to bundle them up into one. On the front-end most frameworks have satisfactory libraries to handle state and cache management.

Slow first time load, multiple times per day? Stop updating your live bundle multiple times in a single day.

Authentication with JWTs: JWTs are not an SPA requirement, they're just one of many approaches to authentication. I don't use them and don't see the point of them in most apps that I've built. If you do use them and need to keep track of them (maybe because you'd like to be able to invalidate them), store them in something fast like Redis on the server.

State updates: The JavaScript ecosystem has excellent caching facilities, that can automatically poll and update resources upon a timeout. It's indeed not rocket science.

Error Handling: You catch the error from the http response and call your handler. That's practically like muscle memory whenever one does an http request.

        client.get({url}).then(resp=>{
            // handle response
        }).catch(error=>{
            errorhandler(error)
        })

The rest of the article can similarly be addressed.

My conclusion is simply that if you want to maximize your cost efficiency, build a team that is familiar with their tools. If all your developers have done and are familiar with are MPAs, then yes, it might be more costly to build an SPA for them at first. I should know. I went through that phase at the beginning of my recent JS foray. Doing anything was slow and would've taken me a fraction of the time by simply playing around with Jinja on the backend. But fast-forward a few months, after immersing myself a bit more with the ecosystem, I cannot imagine reverting to that approach to build anything more complex than a simple data driven app. Emphasis on the simple.

The quality of an end product doesn't have as much to do with tools as people would like to believe.