• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Dion Almaer

Software, Development, Products

  • @dalmaer
  • LinkedIn
  • Medium
  • RSS
  • Show Search
Hide Search

Is it time to go SPA only?

May 12, 2015 Leave a Comment


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?

Loadin, loadin, loading

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

Petabytes for the soul

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.

Share this:

  • Twitter
  • Facebook

Reader Interactions

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Primary Sidebar

Twitter

My Tweets

Recent Posts

  • Generative AI: It’s Time to Get Into First Gear
  • Developer Docs + GenAI = ❤️
  • We keep confusing efficacy for effectiveness
  • The holy grail of a Web SDK
  • The rise of the extensible app platforms

Follow

  • LinkedIn
  • Medium
  • RSS
  • Twitter

Tags

3d Touch 2016 Active Recall Adaptive Design Agile Amazon Echo Android Android Development Apple Application Apps Artificial Intelligence Autocorrect blog Bots Brain Calendar Career Advice Cloud Computing Coding Cognitive Bias Commerce Communication Companies Conference Consciousness Cooking Cricket Cross Platform Deadline Delivery Design Desktop Developer Advocacy Developer Experience Developer Platform Developer Productivity Developer Relations Developers Developer Tools Development Distributed Teams Documentation DX Ecosystem Education Energy Engineering Engineering Mangement Entrepreneurship Exercise Family Fitness Founders Future GenAI Gender Equality Google Google Developer Google IO Habits Health HR JavaScript Jobs Jquery Kids Stories Kotlin Language Leadership Learning Lottery Machine Learning Management Messaging Metrics Micro Learning Microservices Microsoft Mobile Mobile App Development Mobile Apps Mobile Web Moving On NPM Open Source Organization Organization Design Pair Programming Paren Parenting Path Performance Platform Platform Thinking Politics Product Design Product Development Productivity Product Management Product Metrics Programming Progress Progressive Enhancement Progressive Web App Project Management Psychology Push Notifications pwa QA Rails React Reactive Remix Remote Working Resilience Ruby on Rails Screentime Self Improvement Service Worker Sharing Economy Shipping Shopify Short Story Silicon Valley Slack Software Software Development Spaced Repetition Speaking Startup Steve Jobs Study Teaching Team Building Tech Tech Ecosystems Technical Writing Technology Tools Transportation TV Series Twitter Typescript Uber UI Unknown User Experience User Testing UX vitals Voice Walmart Web Web Components Web Development Web Extensions Web Frameworks Web Performance Web Platform WWDC Yarn

Subscribe via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Archives

  • January 2023
  • September 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • November 2021
  • August 2021
  • July 2021
  • February 2021
  • January 2021
  • May 2020
  • April 2020
  • October 2019
  • August 2019
  • July 2019
  • June 2019
  • April 2019
  • March 2019
  • January 2019
  • October 2018
  • August 2018
  • July 2018
  • May 2018
  • February 2018
  • December 2017
  • November 2017
  • September 2017
  • August 2017
  • July 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • December 2016
  • November 2016
  • October 2016
  • September 2016
  • August 2016
  • July 2016
  • June 2016
  • May 2016
  • April 2016
  • March 2016
  • February 2016
  • January 2016
  • December 2015
  • November 2015
  • October 2015
  • September 2015
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • March 2015
  • February 2015
  • January 2015
  • December 2014
  • November 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • February 2014
  • December 2013
  • November 2013
  • October 2013
  • September 2013
  • August 2013
  • July 2013
  • June 2013
  • May 2013
  • April 2013
  • March 2013
  • February 2013
  • December 2012
  • November 2012
  • October 2012
  • September 2012
  • August 2012

Search

Subscribe

RSS feed RSS - Posts

The right thing to do, is the right thing to do.

The right thing to do, is the right thing to do.

Dion Almaer

Copyright © 2023 · Log in