The Single-Page-App Morality Play – Baldur Bjarnason

I keep seeing Single-Page-Apps with huge JS files that only, in terms of concrete User Experience (UX) benefits, deliver client-side validation of forms plus analytics. Apps rarely leverage the potential of a Single-Page-App. It’s still just the same ‘click, wait for load’ navigation cycle. Same as the one you get with Multi-Page-Apps. Except buggier and with a much slower initial loading time.

When you look at performance, cross-platform and mobile support, reliability, and accessibility, nearly every Single-Page-App you can find in the wild is a failure on multiple fronts.

Replacing those with even a mediocre Multi-Page-App is generally going to be a substantial win. You usually see improvements on all of the issues mentioned above. You get the same general UX except with more reliable loading, history management, and loading features—provided by the browser.

Before you dismiss Baldur as a hater based on what I’ve just quoted, you should really read the whole article. The issue he points to is not with the technical architecture of single page apps, but with management.

Single-Page-Apps can be fantastic. Most teams will mess them up because most teams operate in dysfunctional organisations.

A lot of what he says really resonates with me. Over and over again I’ve seen projects where the technical decison around which monolithic client-side JavaScript framework to use has been made even before a problem has been defined.

Baldur’s conclusion chimes a lot with what I’ve been saying in conference talks this year: the biggest challenges facing the web are not technical in nature.

The biggest hindrance to the web’s progress isn’t non-expert developers, tooling, libraries, Single-Page-Apps, or Multi-Page-Apps.

It’s always humans.

The Single-Page-App Morality Play – Baldur Bjarnason

Tagged with

Related links

How to Build Good Software

The right coding language, system architecture, or interface design will vary wildly from project to project. But there are characteristics particular to software that consistently cause traditional management practices to fail, while allowing small startups to succeed with a shoestring budget:

  • Reusing good software is easy; it is what allows you to build good things quickly;
  • Software is limited not by the amount of resources put into building it, but by how complex it can get before it breaks down; and
  • The main value in software is not the code produced, but the knowledge accumulated by the people who produced it.

Understanding these characteristics may not guarantee good outcomes, but it does help clarify why so many projects produce bad outcomes. Furthermore, these lead to some core operating principles that can dramatically improve the chances of success:

  1. Start as simple as possible;
  2. Seek out problems and iterate; and
  3. Hire the best engineers you can.

Tagged with

React, Electron, and LLMs have a common purpose: the labour arbitrage theory of dev tool popularity – Baldur Bjarnason

An insightful and incisive appraisal of technology adoption. This truth hits hard:

React and the component model standardises the software developer and reduces their individual bargaining power excluding them from a proportional share in the gains. Its popularity among executives and management is entirely down to the fact that it helps them erase the various specialities – CSS, accessibility, standard JavaScript in the browser, to name a few – from the job market. Those specialities might still exist in practice – as ad hoc and informal requirements during teamwork – but, as far as employment is concerned, they’re such a small part of the overall developer job market that they might as well be extinct.

Tagged with

The cost of opinion – Dimitri Glazkov

This is a terrific analysis of why frameworks exist, with nods to David Hume’s is-ought problem: the native features are what is, and the framework features are what somebody thinks ought to be.

I’ve been saying at conferences for years now that if you choose to use a framework, you need to understand that you are also taking on the philosophy and worldview of the creators of that framework. This post does a great job of explaining that.

Tagged with

My stack will outlive yours

My stack requires no maintenance, has perfect Lighthouse scores, will never have any security vulnerability, is based on open standards, is portable, has an instant dev loop, has no build step and… will outlive any other stack.

Tagged with

Modern JS is amazing. Modern JS is trash. | Go Make Things

My name is Jeremy Keith and I endorse this message:

I love the modern JS platform (the stuff the browser does for you), and hate modern JS tooling.

Tagged with

Related posts

Mind the gap

If you’re making a library or framework, treat it like a polyfill.

Portals and giant carousels

Trying to understand why people think they need to make single page apps.

Read-only web apps

It’s fine to require JavaScript for read/write functionality. But have you considered a read-only mode without JavaScript?

Choice

Progressive enhancement: it’s not just for web sites, y’know.

Why use React?

Or, more precisely, why use React *in the browser*?