SPA, or not SPA, that is the question!
Introduction
Web development is radically changed in the last few years. The need of high interactivity and the mix of different kind of media contents on the same platform has pushed developers adopting the SPA (Single Page Application) approach also when it is not necessary.
Making a SPA website means that all your website contents will be rendered and managed directly by the Javascript engine (AKA browser) used by the users browsing it. Your users’ browsers will receive contentless web pages that will be populated in a second step becoming interactive gradually once all the loaders will be gone.
During my working career I had the chance to work on several big SPA projects and in this article I will try to share my experience by listing my 10 reasons why you shouldn’t do a SPA website.
10 reasons why you shouldn’t do a SPA website
1. Speed and Performance
If you want to deliver your website contents as fast as possible to your users, independently from the devices they will use to reach your page, you should avoid rendering them on the client.
Rendering the whole HTML of your websites via Javascript in the browser means that you will use a technology that was never meant to be used in that way ignoring what was explicitly invented for doing that well and fast: Servers
Sites like google.com, twitter.com, amazon.com… they all render their contents on the server also because of performance reasons so unless you think you are smarter than them consider offering the SPA websites the exception and not your default offer.
Many developers think that making isomorphic applications pre-rendering HTML on the server will improve their websites performance and that’s true only for the initial rendering. However if all the other pages requested will be completely rendered by your users’ browsers, your page transitions might appear slow and laggy even if you tried all your best to avoid that.
2. High Development Costs
A SPA website costs from 3x to 5x times more compared to a non SPA one.
If your client has no need for a SPA website, offering it means that in the best case you will waste 3x times more time to finish your project.
Often in the end your client (and his/her users as well) will not notice the difference of the product you’ve hardly made compared to other normal SSR (Server Side Rendered) websites and he/she will be hardly willing to pay your big effort for having made it isomorphic with Javascript.
Having high development costs can be a big problem for startups and small companies in an industry with such high competition.
3. Fragility
Making a Javascript website means that (hopefully) you will be using a framework like React, Vue or Angular…
Frameworks maintainers design their code not with your same goals in mind
Your website contents will be fragile because available only to the browsers supported by the framework you have picked.
For example React maintainers correctly inform their users about the possible crossbrowser issues:
Trivial issues will also soon or later get in your way because any small Javascript error might compromise the stability of your whole site:
there is a big difference in having a small scoped portion of your site not rendered because of a javascript error (SSR) vs a complete white page because of a trivial exception thrown your footer javascript template (SPA)
4. Hard Long term Maintainability
Two years ago many big companies used to develop huge SPA website using Angular 1, not because it was particularly good, but because it’s developed and sponsored by Google. Today React is the new shit and Angular {2…n} is completely different from its first version and not backward compatible: all these companies above are forced to invest tons of dollars to rewrite everything from 0 (if they can afford it) or to search desperately developers that can maintain their monstrous legacy code just because nobody uses Angular 1 anymore.
In a nutshell: if you rely on a javascript framework for your entire project your are just writing today your legacy code
5. Poor Security
Backend developers pay much more efforts and time in making websites secure and stable. With the advent of SPA and isomorphic applications many web agencies let their frontend developers programming the frontend and backend (sometimes also mobile native 🤦♂ ) code for their projects!
…no real backend developer would ever code with javascript on the server
Having frontend developers (the same guys that 10 years ago used transparent spacer gifs for layouting) coding your application server is a high risk in term of security: it’s like letting your mechanic healing your heart disease.
In my experience I have seen many cases of backend applications written in javascript by frontend developers in the “most creative possible ways”. I can’t recommend it either to your worst enemy!
6. Reinventing the wheel
Doing a SPA website you will be forced at some point to re implement all the features our browsers give us for free.
For example you will need to find a way to restore the scroll position by any page change, add extra loaders to show that the contents are not yet ready, keep the page <title> in sync with your content and much more…
You will need to code emulating any trivial browser feature fighting constantly with inconsistent behaviors across the browsers vendors.
7. Social media and meta attributes
Social network platforms require meta attributes in your pages in order to get info about your contents. AFAIK Facebook and Twitter crawlers can’t run Javascript so they just read the HTML statically generated by your application routes.
If your app meta tags are not properly rendered your site (when shared) will always have the same title/description/share-image for all of its pages.
In this case the only solution possible is to render your page meta tags on the server and if your app is not isomorphic your backend is forced somehow to be aware of your application frontend router. This will end often in a mess and in unmaintainable code that doesn’t justify why you have made your SPA website in the first place.
8. The glam
Unless you are building the next google maps, a web game or gmail there is no need for a SPA website and you are doing it only for the glam.
The 90% of SPA websites I have worked on could have been made with a simple static site generator like hugo or jekyll, having Javascript components here and there when needed, to make their contents a bit more interactive and fun.
Having completely different templates for all your application pages and no real plans (or time) to animate the content blocks properly transitioning from page to page is already a sign that probably your application doesn’t need to be a SPA in the first place.
If you render your whole page template on any page change request and you think that doing it via Javascript will help you with your fancy “fade in” -> “fade out” css transition, I will reveal you a secret: you can do it with 6 lines of css without javascript.
9. Poor Accessibility
Regarding this topic I would like to give you an exercise: try to use a screen reader randomly on a SPA site to check all the focus behavior inconsistencies during the page transitions leaving your users in the middle of nowhere. No aria or role attribute will help your users with disabilities if your single page keeps changing completely its DOM structure with css transitions and animations.
10. Waste of memory and energy
Many “smooth” SPA websites require quite much memory in order to be able to manage all the website contents + markup + transitions + videos + canvas + webgl…
I have tried for fun printing the memory snapshots for https://mobile.twitter.com that is a brand new shiny SPA (after I have clicked on all 4 main pages) and https://twitter.com/ and these are the results:
It’s really fun to see that the old twitter website requires less memory to render than the “lighter” mobile one.
More memory translates to more energy and less battery life for all the devices browsing your contents. Javascript is a single threaded language with no ways to manage manually the memory allocated for its tasks, you will need to rely on your users devices hoping they will properly free memory for the UI components removed from the screen.
Conclusion
I am not against SPA websites and I love working on them in the rare cases when they make really sense. I hope for the future of the web that people working in this industry will focus more on reusable web components that can only enhance the user experience leaving the rendering of the important contents of the pages to the server available also for users that have for example javascript disabled.
I firmly think that letting downloading tons of Javascript files to your users or hacking ugly caching strategies with Web Services will only make your contents available to a small elite group of people that can afford the latest devices having the fastest internet connection plans.
I am probably a bit too naive but I will always stand for a simpler and lighter web available for the most wishing that more and more developers will educate their clients and companies raising up the issues above the next time someone will ask for a “Single Pain Application”.
P.S.
I have omitted many other issues like bad SEO, bad interoperability with CMSs, inconsistencies in the use of the HTTP status codes.. just for brevity and because they might be too specific to the projects I have worked on and not really related to the more general topic I wanted to describe here.
This story is published in Noteworthy, where 10,000+ readers come every day to learn about the people & ideas shaping the products we love.
Follow our publication to see more product & design stories featured by the Journal team.
