Multi-page web apps

I received this email recently:

Subject: multi-page web apps

Hi Jeremy,

lately I’ve been following you through videos and texts and I’m curious as to why you advocate the use of multi-page web apps and not single-page ones.

Perhaps you can refer me to some sources where your position and reasoning is evident?

Here���s the response I sent���

Hi,

You can find a lot of my reasoning laid out in this (short and free) online book I wrote called Resilient Web Design:

https://resilientwebdesign.com/

The short answer to your question is this: user experience.

The slightly longer answer���

For most use cases, a website (or multi-page app if you prefer) is going to provide the most robust experience for the most number of users. That���s because a user���s web browser takes care of most of the heavy lifting.

Navigating from one page to another? That���s taken care of with links.

Gathering information from a user to process on a server? That���s taken care of with forms.

This frees me up to concentrate on the content and the design without having to reinvent the wheels of links and form fields.

These (let���s call them) multi-page apps are stateless, and for most use cases that���s absolutely fine.

There are some cases where you���d want a state to persist across pages. Let���s say you���re playing a song, or a podcast episode. Ideally you���d want that player to continue seamlessly playing even as the user navigates around the site. In that situation, a single-page app would be a suitable architecture.

But that architecture comes at a cost. Now you���ve got stop the browser doing what it would normally do with links and forms. It���s up to you to recreate that functionality. And you can���t do it with HTML, a robust fault-tolerant declarative language. You need to reimplement all that functionality in JavaScript, a less tolerant, more brittle language.

Then you���ve got to ship all that code to the user before they can use your site. It might be JavaScript code you���ve written yourself or it might be a third-party library designed for building single-page apps. Either way, the user pays a download tax (and a parsing tax, and an execution tax). Whereas with links and forms, all of that functionality is pre-bundled into the user���s web browser.

So that���s my reasoning. At least nine times out of ten, a multi-page approach is leaner, more robust, and simpler.

Like I said, there are times when a single-page approach makes sense���it all comes down to whether state needs to be constantly preserved. But these use cases are the exceptions, not the rule.

That���s why I find the framing of your question a little concerning. It should be inverted. The default approach should be to assume a multi-page approach (which is the way the web works by default). Deciding to take a JavaScript-driven single-page approach should be the exception.

It���s kind of like when people ask, ���Why don���t you have children?��� Surely the decision to have a child should require deliberation and commitment, rather than the other way around.

When it comes to front-end development, I���m worried that we���ve reached a state where the more complex over-engineered approach is viewed as the default.

I may be committing a fundamental attribution error here, but I think that we���ve reached this point not because of any consideration for users, but rather because of how it makes us developers feel. Perhaps building an old-fashioned website that uses HTML for navigations feels too easy, like it���s beneath us. But building an ���app��� that requires JavaScript just to render text on a screen feels like real programming.

I hope I���m wrong. I hope that other developers will start to consider user experience first and foremost when making architectural decisions.

Anyway. That���s my answer. User experience.

Cheers,

Jeremy