Paul Cowan
Mar 16, 2020 ⋅ 7 min read

The single-page application must die

Paul Cowan Contract software developer.

Recent posts:

Vite Adoption Guide Overview Examples And Alternatives

Vite adoption guide: Overview, examples, and alternatives

Vite is a versatile, fast, lightweight build tool with an exceptional DX. Let’s explore when and why you should adopt Vite in your projects.

David Omotayo
Nov 29, 2023 ⋅ 16 min read
Implementing Advanced Features With The Navigator.Share API

Implementing advanced features with the navigator.share API

Explore advanced capabilities for content sharing with the navigator.share API, including dynamic content sharing, custom share targets, and batch sharing.

David Omotayo
Nov 29, 2023 ⋅ 10 min read
Chas Peacock Leader Spotlight

Leader Spotlight: Scaling for the next phase of growth with Chas Peacock

We spoke with Chas to get his insights on building technology and internal processes for companies that are scaling quickly.

Jessica Srinivas
Nov 29, 2023 ⋅ 7 min read
Cypress Adoption Guide: Overview, Examples, Alternatives

Cypress adoption guide: Overview, examples, and alternatives

Cypress is one of today’s foremost tools for testing web applications. Let’s explore when and why you should adopt Cypress in your projects.

Paul Akinyemi
Nov 28, 2023 ⋅ 10 min read
View all posts

7 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