Performance
Single page applications are undeniably faster than traditional web apps.
With a SPA you bundle all the javascript, css, fonts and other resources into a single initial request.
This allows you to push all your content loading into the initial request, making subsequent page loads literally milliseconds in duration.
Just think about that for a second, every single page your user could ever see on your site is now ready and waiting in their browser.
All they need to do is click the link, and request a tiny JSON packet from your backend server.
Rather than making another HTTP request, your user is reading straight from their RAM.
But surely if you’re loading all the scripts etc on the first request, won’t the initial load be slow?
There are loads of ways you can reduce this initial load.
AMD one way of doing it but I don’t really believe that’s actually necessary most of the time.
With your scripts minified and gzipped your application would have to be pretty huge for it to be considerable in any way.
Work it out once you get to that point, don’t prematurely optimise.
Optimizing
Now that your front end is isolated you can really get your pre-delivery process sorted.
Here is the basic optimization you’ll probably do.
Concatenate
Removing the overhead for multiple HTTP request. Aswell as getting around the 2 concurrent request per domain limitation in browsers.
Minify
Minify everything, minify your javascript, your css, your html, your SVGs, whatever you can minify you should minify.
Optimise your images
Anything that can’t be minified, should be optimised.
Gzip the hell out of it
Gzip every file in your front end project before it even gets to your servers, whack it up to level 9 too.
This pre-gzipping will probably only save you a few microseconds per request, but it all counts.
It’s also means you no longer need a server that supports gzipping.
Distributing via a CDN
Amazon S3 and Cloudfront are absolutely perfect for this. Now that your front end no longer requires any server side interaction for it to be delivered you can literally publish it to every corner of the earth for blazingly fast speeds through a CDN. With near 100% uptime, and you literally don’t have to do anything for it to work, it’s just there as a permanent fixture of the internet. This is also infinitely scalable.
But I want to host it for some reason
The great thing is that you can. You can host the app however you want, and you can chop and change it at your will. You’re no longer tied to an application server to deliver your content, you could use node or nginx or apache or IIS or whatever else you could want.
Bundles
Your front end can now be thought of as a standalone bundle. Which is beneficial for a couple of different purposes.
I18N delivery bundles
If you’re using a decent front end framework, like Angular, then it’s already got support for I18N. Implementing I18N should be done from the start of a project. It’s so unbelievably easy to do with these frameworks that there is literally no excuse. If you become successful and you didn’t put the trivial amount of thought into I18N you’ll hate yourself and so will everyone else, especially your dev team.
Now you can (mostly) have your server side completely ignorant of languages and formatting and have it pump out raw values, to be formatted and displayed in whatever way the target audience wants.
When you do become successful, you can distribute specific language bundles to specific CDN endpoints for each relevant country.
This means that the people viewing the site in spanish don’t get the english content and vice versa.
This also means that your web server isn’t looking up translations and using your hardware resources to do so.
A/B Testing
A/B testing becomes much easier when you can selectively distribute the entire front end experience as a single package.
Change management
Customers generally don’t like change. With the front end being bundled into discrete packages you can now distribute different versions to different customers depending on the age of their account. This allows you to continuously deploy updates without worrying as much about bringing all existing customers up to speed with the latest UI.
Separation of concerns
Separation of concerns - that thing that you hear a lot about but it probably doesn’t apply to you right?
Separation of concerns goes far beyond frontend-backend but that’s out of the scope for this post.
Once your UI is separated it can be developed independently of the backend.
Imagine if you could quantify the amount of work a feature will take into backend and front end separately. Also imagine if you could hire someone who was really good at front end to do the front end
and someone who was really good at back end to do the backend. With an SPA you can, and there won’t be any overlap or duplicated work either, because their physically can’t be.
Testing
Now that your concerns are sufficiently separated you can unit test your UI. You’ve probably come across UI based testing and heard/experienced how terrible it is - and I’d agree with you. But we have to be specific about what we’re actually talking about when it comes to UI testing.
When someone mentions UI testing they usually mean end to end testing through the UI. With an SPA, UI testing is unit testing of the UI.
As a separate component, testing the UI is now a trivial task as the backend can simply be mocked out for each individual view. There are also plentiful tools for testing the UI in a variety of different ways for whatever front end framework you’re using.
These front end frameworks also make it a lot easier to split your front end bits into separate components. This means more reused code, easier testing, and a more consistent feel across your site.
One API for all
Your UI is now completely separated, but it needs to get it’s data from somewhere. This is where your server side API comes in, your backend will consist solely of JSON endpoints - each one performing one specific function that the UI needs.
This helps keep the code maintainable as each endpoint does one thing and one thing only. It’s also highly reusable because JSON can be consumed by everything, this becomes very useful when you suddenly need to develop a public API.
Picture this scenario: You’re now a successful company, a big customer comes along and wants to do some sort of custom integration. Rather than saying to them it’s going to cost 10k and take 6 weeks to develop the APIs you need, how great would it be to say: “Here is our API you can do everything on the website from it. Go ahead.”
With an SPA you get exactly that, an all encompassing API. Everything your website can do, can be done from the API.
It goes beyond the website though. Imagine you now need to write a mobile app, to accompany your site. The work is now immediately halved as you only need to worry about the mobile app, the API is already done. Or imagine for some insane reason you need to develop a thick client for your system. The API is already there.
But without a front end how do I write the backend?
Unit testing? - it’s that thing that people sometimes do when they want to make reliable and maintainable software. Unit testing server side code is even easier than testing the front end.
Think about what the server side actually does, it takes data from one place, combines and converts it into another type of data and spits it out the other end. There is literally no excuse for not having 100% code coverage on your backend code. That’s not an exaggeration, I literally mean 100% code coverage. Every aspect of server side development can be, and should be unit tested.
But I don’t have time for all those unit tests
It’s faster in both the short term and long term to write using TDD. I guarantee you, once you try proper TDD for a while you’ll never want to go back. I’ll go into this further in a later blog post.
Common complaints
But [search engine] can’t crawl my site
This is a valid issue, and to this I’d say if you are majorly concerned about it, then don’t use an SPA for your marketing site. Marketing sites are generally a lot smaller anyway so it’s not usually a problem. Also consider that modern crawlers are getting better at using javascript.
But SPAs use more memory client side than normal sites
This can be technically true, but again is a terrible thing to base your architectural designs off of.
It’s always good to have these things in mind, but you’ve got to think about the actual numbers here.
You’re not writing software for 8bit microcontrollers. Modern computers and mobile devices - even the mediocre ones - have upwards of 8 cores and gigabytes of RAM.
But I don’t know javascript
or
But we don’t have any javascript developers
Learn javascript.
If you are on your own, learn javascript it’s a useful language and not too difficult to pick up.
If you are managing a company - hire a front end developer.
All websites require knowledge in HTML, CSS, and javascript if you don’t have at least one person who could be considered a front end developer then you are doing it wrong.
But javascript isn’t supported by all browsers
I don’t really have an answer to this because I can’t tell if it’s a joke or not.
I don’t like the # in my URLs
Deal with it.