Four and a half years ago we set about building a conditional tier rendering engine. The timing was perfect. Node was giving us a viable JavaScript on the server solution (no offense meant to Jaxer and friends) so we could explore the dream of shared code on the client and server.
One of the other key reasons for conditional rendering was: appease the SEO gods! If your web application doesn’t have the need (or business model) for Google and friends to draw customers to your experience then you could go ahead and SPA away. For many, that wasn’t the case, and the Google bot and its friends wanted you to give them some nice clean markup.
The Google bot has continued to evolve, and we have been told that it has gotten better at speaking JavaScript itself. This article on a test to see how well this works in practice is a good reminder to run some tests yourself, and to rethink the role of server rendering.
Is it possible to go full on SPA now? Let’s take a look at what has changed over the years, take some guesses to the future, and see how that could lead us.
Performance
Sending down a fully rendered page on first load is what we are really talking about here. You could argue that it is viable to do full page reloads, but you may as well at least pjax right? Once the app is loaded, why bother tearing down and setting up on interactions?
We have all witnessed the “slow SPA effect” though. You know the one. After tapping a link the page goes from white to show some app UI, but then you are watching a custom spinner as it goes back to the server to get the real data. Irritating.
SPA doesn’t have to be this way though. Google+ was one of the first web apps that I saw that would send the data required along with the app for first load, and we can do the same on our SPAs. This way, the app is able to render itself right away vs. having to phone home an extra time.
Is this as fast as sending down the right HTML (and then co-opting it and taking over)? No. Is it the bottle neck to your performance? I doubt it. Add to this the fact that you can also go after localStorage and friends, you may have a bunch of data already.
When you get to the point where it is important to tweak every part of your performance stack (e.g. customer HTTP client and servers!) you will want to look at each interaction and think about:
- What is important to show immediately?
- What can we lazily load?
- What should start low-res and then have us flip to high-res?
- What can be cached?
Data Centers
It turns out it is faster for your machines in your data centers to talk to each other than for your customers to keep talking to the various machines.
You will want the edge to have as much of the data to send down to the client in a blast as possible. Chattiness over networks (especially mobile ones) are not your friend.
You Already API
We have been through the years where the “web site doesn’t have an API for mobile yet!” They aren’t pretty. We got through them though and now you probably have nice APIs that multiple clients can access. Having all of the clients use these APIs is important. If you have a “mobile API” and the desktop web site doesn’t use it, I bet money that the ideal feature parity isn’t available :/
Beware perverted incentives.
Motion
The bar for a consumer grade experience is always getting raised. Motion, animation, and feedback are really important. When the customer goes between Web and native their worlds are blurring, thus more motion and layering will come to the Web and this fits in nicely with fluid SPAs.
The Web has an advantage in that the “app” can be downloaded and changed all the time. This allows for great A/B testing, seamless updates, but also requires the downloading of the app (vs. having the beast already on the device).
As your experience grows you want to have a build system that has a small core that is one step ahead of the customer.
Compare facebook.com to the Facebook app. A lot of code ships in that app that will never be run by a large number of users.
You can also look at the Google iOS app. That search box comes in at 64.7MB! (I know it is a LOT more than a search box). Smart dynamic loading is key, and this is one reason why I am excited about frameworks such as React Native that allow much more to be done at runtime.
Event driven
I a sucker for an event driven world. That REST thing can be over-rated at times. Why not think in state machines and events? With WebSocket support across native and Web it can be interesting to rethink how your application would work if it was connected in real-time…. but of course built to work very much offline first.
It drives me nuts when I see loaders all over the place when a lot of the data could be shown from cache.
Accessibility
Just as a datapoint, The WebAIM survey results (published yesterday) reveal 98.6% of screenreader users have javascript enabled.
Another area of concern for SPA is accessibility. There are a ton of nuances here, and it is an area that doesn’t get enough attention from teams, but I don’t think it is enough to icksnay SPA.
Other bots
Google isn’t the only bot out there man! There are Gobots as well as Transformers!
Absolutely, and the others may not be as advanced on the JavaScript side as Google. I get it, but is it time to skate to where the puck is going?
Brave New World
As always, technology is advancing at a rapid clip. It is important to revisit your assumptions every year or two. There are no sacred cows.
