Paul Cowan
Mar 16, 2020 ⋅ 7 min read

The single-page application must die

Paul Cowan Contract software developer.

Recent posts:

Building Web-Based Terminal Components With Termino.js

Building web-based terminal components with Termino.js

Explore Termino.js, an open source library for integrating web-based terminals into applications, in this introduction article.

Chibuike Nwachukwu
Apr 11, 2024 ⋅ 6 min read
How To Build A Custom Gpt: Step By Step Tutorial

How to build a custom GPT: Step-by-step tutorial

Let’s see why and how to build custom GPTs — personalized versions of ChatGPT that act as custom chatbots to serve a specific purpose.

Peter Aideloje
Apr 10, 2024 ⋅ 7 min read
Jest Adoption Guide: Overview, Examples, And Alternatives

Jest adoption guide: Overview, examples, and alternatives

Jest is feature-rich testing framework that comes with several in-built features that make it powerful and easy to use.

Ibiyemi Adewakun
Apr 9, 2024 ⋅ 12 min read
Implementing LiveViews In Node.js

Implementing LiveViews in Node.js

Explore LiveViewJS and how to build a full-stack Node.js app with LiveViews that supports real-time interactivity.

Emmanuel John
Apr 8, 2024 ⋅ 16 min read
View all posts

8 Replies to "The single-page application must die"

  1. You didn’t address the real issue. We need a common, accepted standard for distributed applications that is not built on HTML, css and js. Web assembly might open the door for that but we need an entire framework for building GUI apps. Everything we have now for HTML has been bolted onto something that was intended for a different use. We need a foundation built from the ground up for distributed apps that is supported by all operating systems and platforms but binary based.

  2. Something else you left out is server workload vs client workload. With spas, you are leveraging millions of machines to do processing. With server rendering, you are putting more stress there. It makes sense to leverage a users processing power with client side code.

  3. I disagree that it makes sense to leverage a user’s processor with client-side code.

    As the site owner, you can scale the server processing easily. It can be scaled up and down rapidly in modern hosting environments. It can account for surges, low traffic, and ensure the same rendered code is delivered to all users (barring network issues). It is part of the cost of doing business.

    You cannot, however, scale the end user’s processing power. If on an old phone, with a low battery, on dodgy cell service, and so on, you are leveraging millions of sub-par processors to create millions of sub-par experiences. You are essentially ceding the experience (and potentially reviews, word-of-mouth) to every device that does not match your developer’s device specs.

    IOW, put the burden on the server where you can.

  4. If a MPA were desirable in and of itself — and not merely a compromise made so that programs could be distributed over the web — then why did no one ever come up with a MPA for traditional PC applications and old-fashioned two-tier client-server applications?

  5. If an SPA can deliver a better user experience then it is the right choice. You simply cannot make some of the apps and interactions in a traditional MPA an example being Discord or YouTube Music. The user experience whilst using these products brings delight to those using them. Are they right all the time? No, but like anything they should be used in moderation and where they can excel at what they do best.

  6. for logically: clear business division with view
    for project management: fe-developer, be-developer
    for scalability: I can serve a SPA or an android device with the same BE
    for performance: rendering on the server means potentially thousands of pages on a single processor
    by aptitude: code executed where it appears
    for optimization: the data that transit on the internet is ONLY data
    code cleanliness, scalability, speed, accuracy…
    I would say that not using a SPA is just nonsense instead

Leave a Reply