It’s not all bad, though! Whilst deep in my research for the "Panda Frame" project, I discovered some interesting historical information about Twitter tech and its development over time — and I’ve reached an interesting conclusion. Given that there’s a lot of talk about Twitter’s new ownership and where this might lead the platform right now, I thought it would be a good time to share my findings. But first, let’s take a look at what we mean by a SPA.
What is a SPA?
How can you tell if a website is a SPA?
Open the network tab in your browser dev tools, filter by “Doc”, and refresh the page. You should see an HTML document loaded in.
In brief: MPA
In a MPA, HTML documents are rendered on a server, either at build-time in the case of pre-generated static sites, or at request time for server-side rendered pages. Every page in an MPA has its own file or route. When you navigate to a new page in an MPA, your browser requests a new page of HTML from the server, the server builds it and sends it back. Traditional MPA frameworks include Ruby on Rails, Python Django, PHP Laravel, WordPress, and static site builders like Eleventy or Jekyll. This is the way all websites worked until the late 2000s.
Was Twitter the original SPA?
The web community often regard Twitter as one of the first modern Single-Page Applications. During my research for PandaFrame, I stumbled upon a blog post from Twitter published on 20 September 2010: The Tech Behind the New Twitter.com.
Encouragingly, Twitter made sure to consider this carefully in 2010 by building a Mustache-based rendering system that ran on both the server and client. (It’s a shame this didn’t persist into the present day!)
Fast-forward to 2012 and Twitter released a new blog post announcing that to “take back control of [their] front-end performance”, they decided to move much of the rendering back to the server(!), given that the SPA-based approach “lacked support for various optimizations available only on the server.”
React continued to grow to an almost unprecedented 71% share of developers, and Next.js rode that wave and is now used by 1 in every 2 developers.
In further technical developments, in 2017 Twitter released Twitter Lite — a Progressive Web App (PWA). Progressive Web Apps go even further to replicate that native app-like experience of a SPA, by being “installable” on devices, supporting offline use and push notifications, whilst also being discoverable on the web and sharable via a URL. Initially aimed at improving the mobile Twitter experience by minimising data usage, loading quicker on slower connections and taking up less than 1MB of device space, you can still install Twitter on any device today, including desktop machines.
Twitter Lite was available at mobile.twitter.com — seemingly splitting the codebases for desktop and mobile devices at the time. Before hand-held devices became as powerful as they are today — and before CSS became more responsive by default with tools such as grid and clamp — this was the way things were done. All companies I worked at in the 2010s maintained separate desktop and mobile experiences, although we began merging the two experiences starting in 2017/2018.
It’s interesting to note that the web dev industry took so long to appreciate that the performance benefits and features of “mobile sites” are just as compelling on non-mobile devices, and that responsive web design and progressive enhancement could let us build the best experiences for users no matter where they are or what device they’re using.
In 2019, Twitter followed suit and launched another new Twitter, this time with a “write once, run everywhere” philosophy, merging the desktop and mobile device experiences in code. This was further enhanced by only downloading visual elements to a user’s browser or device when they were needed, in order to prioritise data-saving on all devices.
And the cycle continues
The initial question that prompted this post was: “Should we really be asking whether people should build a SPA or MPA?” I think the answer is yes… BUT — there’s more. I am fascinated by the technical journey that Twitter has been on over the last 12 years, and a lot of it mirrors the technical trends I have observed and built myself during my career as a front end developer and tech lead. But this journey also highlights the extra nuances to take into account when building a product, and ultimately when choosing the tech.
The technical choices you make don’t just rely on the features your product will need. These choices are also massively influenced by how people will use your product.
- Who is your audience?
- How fast is their internet connection?
- What devices do they use?
- Do they use more than one device frequently?
- How do they actually use the product?
The changing landscape of hardware, internet connectivity, and social patterns — these all play a part in choosing the tech for our products. And this is likely to change as the world evolves around us. And so in conclusion: I’m not sure I can really build Panda Frame effectively.
What do you think? Is Panda Frame a lost cause? Let me know on Whatsapp (if it’s still around…)!
Hope you guys understood my explanation. And don't count out my English being a bit messed up.Then see you in another blog. 😄