6 ms·

In more cases than not I've noticed the choice of single page app itself is pure overhead. SPA technology brings some key advantages but also a whole new realm

In more cases than not I've noticed the choice of single page app itself is pure overhead. SPA technology brings some key advantages but also a whole new realm of cost and complexity. It's my experience that SPA popularity has convinced many folks to use it when they really don't have a practical reason to justify it.

com2kid 4y ago
Svelte is so insanely lightweight, I think it is a great counter argument to a lot of the SPA hate. And honestly, most of the weight in modern websites comes from analytics and tracking tools. I've made insanely performant SPAs that work well on low budget hardware. My personal phone is 5 years old, if code I write doesn't perform flawlessly on it I'm not going to ship it to customers! Heck my personal dev laptop is a 4+ year old $999 Costco special. Well made React sites can run just fine on devices like that, and Svelte runs even better. Also SPAs scale better, I remember the days of website backends being slow, with page loads taking forever, massive amounts of HTML being generated server side using slow scripting languages. Sending a JSON blob of some fields to the browser and having the browser update some nodes makes a lot more sense than the old school way of reloading the entire bloody page to change a couple fields.
- pweissbrod 4y ago
  By choosing an SPA. You must choose a dedicated static site hosting which is separate from your web application. You may already have this but you may not. In most cases you must choose a framework for routing. Also a framework for state management. You also dedicate to duplicating validation and security trimming logic both on the client side and the server side. More often than not you will find yourself including hundreds of NPM packages as dependencies which you must continually update and maintain. Also the requirement for unit testing on the front end is common. Which brings in the need for things like jest and enzyme. This complexity inevitably trickles into your build and deploy processes. Perhaps in larger teams this is a burden you can absorb. In smaller teams however you start to see division of responsibilities. One person only knows front end but not back end and vice versa. Common knowledge of the application as a whole can become fragmented. Perhaps the day comes where you want to take a partial of a user interface posted in a peripheral application and place it inside your web page. Because you have a virtual DOM this is now a security risk. You must build a component which duplicates the user interface which already exists. If the user interface needs to be shared among many applications you must build a commons code base to host your components. You start shouldering the burden of maintaining component libraries instead of just HTML and CSS. Again this is all very general and hypothetical but it feels worth pointing out some of the common implications that simply choosing an SPA can have in the longer run. Plus this is not an all or nothing sort of choice. For decades we have used Ajax to perform partial updates on a web page. Consider alternatives like HTMX as a comparison.
  - jsyolo 4y ago
    What backend tech do you like to pair HTMX with?
    - pweissbrod 4y ago
      That's the thing. It doesn't really matter. It's sort of like asking what backend tech you pair with jQuery
  - shortcake27 4y ago
    > By choosing an SPA. You must choose a dedicated static site hosting which is separate from your web application. No you don’t. > In most cases you must choose a framework for routing. Also a framework for state management. I don’t understand this argument. React gives the developer this freedom by design. If you want a framework that has all of these decisions made for you, they exist. > You also dedicate to duplicating validation and security trimming logic both on the client side and the server side. I’ve been validating on the frontend for 15 years, long before I worked on an SPA. It has never been necessary but it provides a better experience. If you don’t like this, you can still let the server do all the validation. There is nothing about an SPA that enforces client-side validation. And you’re wasting your time if you’re doing security filtering on the the frontend. > Also the requirement for unit testing on the front end is common. Which brings in the need for things like jest and enzyme. “Grr this paradigm allows me to test my code, I hate it!”. Seriously, we’re now able to write unit tests which were previously impossible. How is this a bad thing? Also Enzyme hasn’t worked since React 17, I now use RTL which asserts user behaviour - super nice. > Because you have a virtual DOM this is now a security risk. What? > You must build a component which duplicates the user interface which already exists. How is this any different to a non-SPA? Regardless of technology you can’t just arbitrarily lift interfaces from unrelated applications and inject them into your application without a bit of work. > If the user interface needs to be shared among many applications you must build a commons code base to host your components. Again, how is this any different from a non-SPA? You UI isn’t going to magically share itself between applications just because you don’t have an SPA. I’ve worked on all types of applications and I don’t think SPAs should be the defacto approach, but I really feel you’re clutching at straws with all of your arguments.
- AtlasBarfed 4y ago
  I wish there was a "works for Pentium III" label that would help indicate that the app's usability hits necessary minimums on a 1Ghz Pentium III computer. IMO that would be a good optimization floor for avoiding the hidden monstrosity of electron apps and that type of stuff. If your McCrud app can't be responsive on a baseline 1Ghz PIII with 1GB of RAM, then there needs to be some sort of shame pushback. Moore's law is effectively coming to a close, there will need to be more optimization in the future.
  - toastal 4y ago
    Works on a KaiOS feature phone support would be a relevant metric today with similar goals that you mention. They explicitly state in their docs that React will be too heavy for your app.
  - mrtranscendence 4y ago
    Why Pentium III? That's nearly 25 years old. You couldn't run Windows 10 on such a processor, let alone a modern browser, and a $200 mobile phone would beat it in benchmarks. Surely you can have a higher floor than that.
    - com2kid 4y ago
      Google Maps ran like a dream on Pentium M systems back in 2005. Gmail was also smooth as butter. Pentium M was a derivative of the Pentium III design. Ignoring high resolution image assets, there is no reason a website shouldn't degrade and be able run on any machine faster than 300mhz.
    - AtlasBarfed 4y ago
      The Pentium III was the around a half a gigahertz, and we were starting to get into multi-hundreds of gigabytes. ... that sounds small compared to today's specs, but IMO this is when PCs had plenty of horsepower to run "real" operating systems (32-bit preemptive multitasking), "real" browsers, 3D gaming was into it's fifth year or so, etc. So this wouldn't be a badge where you say "wow we fit it into this impossibly limited device". The dirty secret of the PC business is that this hardware spec is more than enough for practically all productivity and browsing (and video with hardware acceleration). Now, high polygon high res high antialiased games... but that has actual hardware horsepower needs you can quantify. The amount of wasted resources from the year 2000 to now is stupefying. Intel and AMD love it! DRAM makers love it! But as an industry we have squandered the last two decades (and the last two decades of CPU improvement), right as gigahertz scaling disappeared, Moore's law is probably going to collapse under its economic weight, Amdahl's law says parallelism won't save us forever. So if I look at some software and wonder why this relatively straightforward app is hogging along on a PC that is effectively 10-50x faster than a Pentium III 500Mhz (8x-10x in clock speed, then massive improvements to cache, branch prediction, multiple ALUs, speculative execution)... something is wrong.
meanyesterday 4y ago
Totally agree. Definitely a reason I avoided any SPA on findthca.com. I've never had a user complain that it needed one.
ko27 4y ago
It's actually the opposite. MPAs are pure overhead. In theory SPAs are faster because they only require a minimum of 1 user blocking network request, while MPAs need at least 1 for each page. Everything else is up to the implementation. So if you are doing heavy performance optimizations, SPAs will always end up faster. However that's not the full picture, and in practice there is a lot of nuance, but SPAs definitely have a higher performance ceiling.
- pweissbrod 4y ago
  Not for large DOMs. And for websites which Don't require support for low internet bandwidth this is optimizing for the wrong problem
  - ko27 4y ago
    Network latency is your no.1 bottleneck for every modern device, everything else is a distant second. Also you can optimize everything, but you can't make MPAs navigate without a network roundtrip.
    - bruce343434 4y ago
      Mpa still is faster so spa must have another type of bottleneck
JLuterek 4y ago
This is very true. It's also why we have svelte-kit, remix, astrojs, and other frameworks that take a transitional app approach. They are server-rendered where it makes sense and client-rendered where necessary. Before developers had to choose between a server-rendered website and full on single-page application, now there are great options that blend the two depending on needs.

com2kid 4y ago

Svelte is so insanely lightweight, I think it is a great counter argument to a lot of the SPA hate. And honestly, most of the weight in modern websites comes from analytics and tracking tools. I've made insanely performant SPAs that work well on low budget hardware. My personal phone is 5 years old, if code I write doesn't perform flawlessly on it I'm not going to ship it to customers! Heck my personal dev laptop is a 4+ year old $999 Costco special. Well made React sites can run just fine on devices like that, and Svelte runs even better. Also SPAs scale better, I remember the days of website backends being slow, with page loads taking forever, massive amounts of HTML being generated server side using slow scripting languages. Sending a JSON blob of some fields to the browser and having the browser update some nodes makes a lot more sense than the old school way of reloading the entire bloody page to change a couple fields.

pweissbrod 4y ago
By choosing an SPA. You must choose a dedicated static site hosting which is separate from your web application. You may already have this but you may not. In most cases you must choose a framework for routing. Also a framework for state management. You also dedicate to duplicating validation and security trimming logic both on the client side and the server side. More often than not you will find yourself including hundreds of NPM packages as dependencies which you must continually update and maintain. Also the requirement for unit testing on the front end is common. Which brings in the need for things like jest and enzyme. This complexity inevitably trickles into your build and deploy processes. Perhaps in larger teams this is a burden you can absorb. In smaller teams however you start to see division of responsibilities. One person only knows front end but not back end and vice versa. Common knowledge of the application as a whole can become fragmented. Perhaps the day comes where you want to take a partial of a user interface posted in a peripheral application and place it inside your web page. Because you have a virtual DOM this is now a security risk. You must build a component which duplicates the user interface which already exists. If the user interface needs to be shared among many applications you must build a commons code base to host your components. You start shouldering the burden of maintaining component libraries instead of just HTML and CSS. Again this is all very general and hypothetical but it feels worth pointing out some of the common implications that simply choosing an SPA can have in the longer run. Plus this is not an all or nothing sort of choice. For decades we have used Ajax to perform partial updates on a web page. Consider alternatives like HTMX as a comparison.
- jsyolo 4y ago
  What backend tech do you like to pair HTMX with?
  - pweissbrod 4y ago
    That's the thing. It doesn't really matter. It's sort of like asking what backend tech you pair with jQuery
- shortcake27 4y ago
  > By choosing an SPA. You must choose a dedicated static site hosting which is separate from your web application. No you don’t. > In most cases you must choose a framework for routing. Also a framework for state management. I don’t understand this argument. React gives the developer this freedom by design. If you want a framework that has all of these decisions made for you, they exist. > You also dedicate to duplicating validation and security trimming logic both on the client side and the server side. I’ve been validating on the frontend for 15 years, long before I worked on an SPA. It has never been necessary but it provides a better experience. If you don’t like this, you can still let the server do all the validation. There is nothing about an SPA that enforces client-side validation. And you’re wasting your time if you’re doing security filtering on the the frontend. > Also the requirement for unit testing on the front end is common. Which brings in the need for things like jest and enzyme. “Grr this paradigm allows me to test my code, I hate it!”. Seriously, we’re now able to write unit tests which were previously impossible. How is this a bad thing? Also Enzyme hasn’t worked since React 17, I now use RTL which asserts user behaviour - super nice. > Because you have a virtual DOM this is now a security risk. What? > You must build a component which duplicates the user interface which already exists. How is this any different to a non-SPA? Regardless of technology you can’t just arbitrarily lift interfaces from unrelated applications and inject them into your application without a bit of work. > If the user interface needs to be shared among many applications you must build a commons code base to host your components. Again, how is this any different from a non-SPA? You UI isn’t going to magically share itself between applications just because you don’t have an SPA. I’ve worked on all types of applications and I don’t think SPAs should be the defacto approach, but I really feel you’re clutching at straws with all of your arguments.
AtlasBarfed 4y ago
I wish there was a "works for Pentium III" label that would help indicate that the app's usability hits necessary minimums on a 1Ghz Pentium III computer. IMO that would be a good optimization floor for avoiding the hidden monstrosity of electron apps and that type of stuff. If your McCrud app can't be responsive on a baseline 1Ghz PIII with 1GB of RAM, then there needs to be some sort of shame pushback. Moore's law is effectively coming to a close, there will need to be more optimization in the future.
- toastal 4y ago
  Works on a KaiOS feature phone support would be a relevant metric today with similar goals that you mention. They explicitly state in their docs that React will be too heavy for your app.
- mrtranscendence 4y ago
  Why Pentium III? That's nearly 25 years old. You couldn't run Windows 10 on such a processor, let alone a modern browser, and a $200 mobile phone would beat it in benchmarks. Surely you can have a higher floor than that.
  - com2kid 4y ago
    Google Maps ran like a dream on Pentium M systems back in 2005. Gmail was also smooth as butter. Pentium M was a derivative of the Pentium III design. Ignoring high resolution image assets, there is no reason a website shouldn't degrade and be able run on any machine faster than 300mhz.
  - AtlasBarfed 4y ago
    The Pentium III was the around a half a gigahertz, and we were starting to get into multi-hundreds of gigabytes. ... that sounds small compared to today's specs, but IMO this is when PCs had plenty of horsepower to run "real" operating systems (32-bit preemptive multitasking), "real" browsers, 3D gaming was into it's fifth year or so, etc. So this wouldn't be a badge where you say "wow we fit it into this impossibly limited device". The dirty secret of the PC business is that this hardware spec is more than enough for practically all productivity and browsing (and video with hardware acceleration). Now, high polygon high res high antialiased games... but that has actual hardware horsepower needs you can quantify. The amount of wasted resources from the year 2000 to now is stupefying. Intel and AMD love it! DRAM makers love it! But as an industry we have squandered the last two decades (and the last two decades of CPU improvement), right as gigahertz scaling disappeared, Moore's law is probably going to collapse under its economic weight, Amdahl's law says parallelism won't save us forever. So if I look at some software and wonder why this relatively straightforward app is hogging along on a PC that is effectively 10-50x faster than a Pentium III 500Mhz (8x-10x in clock speed, then massive improvements to cache, branch prediction, multiple ALUs, speculative execution)... something is wrong.

meanyesterday 4y ago

Totally agree. Definitely a reason I avoided any SPA on findthca.com. I've never had a user complain that it needed one.

ko27 4y ago

It's actually the opposite. MPAs are pure overhead. In theory SPAs are faster because they only require a minimum of 1 user blocking network request, while MPAs need at least 1 for each page. Everything else is up to the implementation. So if you are doing heavy performance optimizations, SPAs will always end up faster. However that's not the full picture, and in practice there is a lot of nuance, but SPAs definitely have a higher performance ceiling.

pweissbrod 4y ago
Not for large DOMs. And for websites which Don't require support for low internet bandwidth this is optimizing for the wrong problem
- ko27 4y ago
  Network latency is your no.1 bottleneck for every modern device, everything else is a distant second. Also you can optimize everything, but you can't make MPAs navigate without a network roundtrip.
  - bruce343434 4y ago
    Mpa still is faster so spa must have another type of bottleneck

JLuterek 4y ago

This is very true. It's also why we have svelte-kit, remix, astrojs, and other frameworks that take a transitional app approach. They are server-rendered where it makes sense and client-rendered where necessary. Before developers had to choose between a server-rendered website and full on single-page application, now there are great options that blend the two depending on needs.