Today we announced the launch of the new Twitter.com – a project years in the making. Now, we want to go behind the scenes to give you a glimpse at what it took to actually build it. What’s new about it? Why are we so excited about it? And what does this mean for the future of Twitter for web?
Over the next few weeks, we’ll share a series of blog posts that will explore the thinking behind the new website architecture and how we’ve built a responsive experience for all the people who use Twitter. We’ll cover the journey of building Twitter.com in two parts: Faster, looking at how we thought about the systems we put in place to make Twitter.com more performant and efficient, and Richer Experience, digging into the functionality we added to make our site more immersive.
One of Twitter’s goals is to reach everyone everywhere. Twitter’s web apps are critical to making this happen. They don’t require installation and are immediately accessible by almost every connected device in the world. The open web has unparalleled discoverability and reach. However, the Twitter web team found it difficult to deliver on the promise of bringing Twitter’s features to everyone on the web due to our large user base and the variety of devices they use.
We tried several approaches to fix problems as they arose, but found many of these stemmed from old architectural decisions. Ultimately we decided to move forward with a whole new approach - rebuilding Twitter.com from scratch. We knew we were undertaking a huge task: a rewrite of one of the largest sites on the web. Big migrations like this are risky and difficult to pitch. Nevertheless, we were successful in getting the support we needed, and we set out to make Twitter anew.
One of our first priorities was to unify our mobile and desktop architectures - leveraging responsive design was a given. However, unlike traditional responsive designs, we set out to create something that was responsive to more than just design and screen size.
Our goal was to create one codebase - one website - capable of delivering the best experience possible to each person.
Many companies have one desktop site and a separate site for mobile web devices. This has the advantage of lighter mobile code, which means people on constrained data plans get the core experience they need faster. The downside of this approach is that it requires coding features multiple times, and prevents mobile users from accessing the full functionality of the product.
Our goal was to create one codebase - one website - capable of delivering the best experience possible to each person. We also felt it was the right moment to do something different: to set both our developers and our users up for Twitter’s future.
On web, we believe in the “write once, run everywhere” philosophy.
The techniques and technologies we’ve used on the new Twitter.com mean you only download and run code when it’s needed. So a mobile user won’t download the sidebar you see on the home page, and may not download the settings pages until they go to update their display name. However, it also means that the full functionality of the site is still available to them should they want to access it.
In short, our goals for this new site are two-fold:
The benefit of this approach is massive. In 2018, we replaced our Windows UWP app with the new Twitter.com, a Progressive Web App (PWA), meaning that the app is powered by the same code as the desktop website. Every new feature we develop for desktop becomes available on all other clients: the Windows app, Twitter Lite, and our KaiOS app.
We can now cater each component (or piece of the site) to each specific user. For instance, with a unified site, we can now provide data saver functionality to anyone who needs it. Many people pay per Megabyte of data they use, regardless of whether they use it on their phone, or on their larger screen desktop at home. While data saver may seem like a mobile phone feature, it’s actually a metered- or slow-connection affordance.
Even simple UI affordances can be changed to fit the user. For example, keyboard shortcuts will rarely be helpful for a touch-screen mobile user, but for a tablet user with a keyboard they could be just as handy as on a full-size desktop. So we enable these shortcuts whenever we detect a keyboard.
We’re proud of what we’ve accomplished so far, and we believe we’re now set up better than ever for Twitter’s future: a place where everyone can participate in the public conversation.
Did someone say … cookies?