Dion Almaer

Software, Development, Products

Progressive Web App

The Doomed Rewrite

It just happened again. I spoke to a company, with some great engineers, and they just experienced the doomed rewrite.

I remember the days of the Monty Hall Rewrite, which is a situation I would much prefer to DOOM. With Monty Hall, you run into the following situation:

  • A website uses a given tech stack. It feels legacy, and the team gets to a point where it is time to consider a rewrite, to wipe clean the technical debt. This is a very expensive decision, and often the better path is to iterate, but there does often come a time
  • A new website is created, using a newer, shinier, tech stack
  • There is a comparison made between the two, which often isn’t very fair, as it muddies the water based on the fact that the difference isn’t just the tech stack. You have all of the domain knowledge and learnings from the older version(s).

The doomed version, when you choose door three, follows a similar path, but the ending isn’t as happy.

You are not Google, is a great post that basically describes the important value in taking the time to understand that you should validate that you are choosing the right tool for the job. It focuses on backend infrastructure, but the same arguments can be made in the world of frontend.

Just as it is important to understand the problem that Cassandra was solving (database writes for the Add to Cart action), it is important to think through the front-end needs (e.g. what are Facebook’s biggest needs with React, or Google’s with Angular, or Lit, etc).

You want to create the right balance for your needs, and they are varied.

For example, the scenarios below are not the same:

  • You have an existing business at scale, and need to be able to build something that results in higher quality, developer velocity, and will scale with your growth
  • You are creating a new product, and need to build an experience that will find product market fit. Quality attracts, so you don’t want use a stack that will hurt you from finding this fit, but if everything takes off like a rocket ship and you need to rewrite…. that is a win condition

The doom scenario that I am seeing far too often these days relates to the first scenario. A great business is in place, but technical debt has caught up to the team, and they want to take a chance to rewrite in a modern stack that will result in a beautiful PWA experience that will scale to all of their users use cases.

The new stack is assembled, and a small prototype is built against the legacy APIs. It works! Full steam ahead! Fast forward to the launch of the new version, and oops….. it’s kinda slow.

Lighthouse is run for audits, and WebPageTest shows you The Truth in The Trace, and the team has that sinking feeling. The good news is that there are some quick wins: some preconnect, prefetch, and preloads help the cause, images are squooshed, etc.

“There are 44 copies of Object.assign polyfills!”

— Default pit

But this isn’t enough. There’s just way too much JavaScript. Unfortunately, it really is far too easy to npm install yourself to large dependency chains that all bring in polyfills and just a ton of code. It’s time to go back to the drawing board, and see what needs to be re-architected. Just when you were ready to build off of the new base, you have to work on fixing the foundation, and you have that dreaded thought….. do we need to rewrite the rewrite?

This is when I start to tear up. All of that work, and you aren’t at the promised land at all.

How do you avoid this?

You need to start with a performance budget, and stick to it as you grow. Make sure your architecture scales as the app builds (e.g. each new page doesn’t add to a huge bundle that has to be loaded at once. Code split FTW).

Choose the right tools for the job. If you are a content site that averages 1.2 pages per user session (you know who you are 😉…. don’t load the entire world up front. Just show the content. Think about the areas of first load and separate that from subsequent loads. E.g. if you have more of an app, follow the Netflix pattern and have a super lean home / login that then loads up “the app” once there is time (users take time to read…. that’s great Idle time to do work!).

It’s never been a better time to build a web app that can scale to users across feature phones, smart phones, tablets, desktop, and more. If you hit the quality bar you have happy users coming to you from search and social…. and your loyal users will add you to their home screen, from the browser or store.

There is a lot we can do to make great experiences occur as more of a side effect of the toolboxes we have available, but even still: Run. Lighthouse. Early. And. Often. And then you will be set up to brag about your successful Monty Hall rewrite.

Want to learn more about getting started? Check out web.dev!

Progressive Web-First Apps

Leave a Comment

You have a cool idea, and you don’t think “there is an app for that” yet. The path is clear, right? Build an iOS app, because the VC you are pitching has one in their pocket, and you want high ARPU customers.

When we were in the early gold rush years of mobile, this may have been the best path. There were a few things in your favor:

  • People were enjoying the novelty, and would go to the app store to checking out the cool apps of the day (akin to going to Yahoo! for cool new web sites)
  • There were a lot of popular services without polished mobile apps, so great developers had room to come in with amazing third party clients (e.g. Tweetie, which became the official Twitter client… a pretty common pattern)
  • The mobile Web wasn’t the greatest experience on early mobile
  • Graphs were up and to the right, so funding was highly available. I saw this first hand. For example, after launching the mobile apps at Walmart, if you projected forward, they would eat everything….. but the reality is that there are plateaus when you consider the time spent across various platforms, and there is room for the overall pie to still be growing fast!

Today, the opportunity to have impact is still very much there, and the world continues to keep jumping online, so the user base for your experience may still be growing, but the landscape has new challenges.

  • Many users aren’t going to the app store for discovery, are happy with the apps they have, and aren’t downloading many new ones.
  • The barrier of an app store may hurt your funnel, so the cost of acquisition for new customers may not be in your favor.
  • The reach of one platform is naturally much smaller than the meta reach of something like the Web.
  • We are moving past the “easy” years of only having to worry about 320×480, or desktop websites. Computing is going through much more unbundling, with many more form factors joining ecosystems. We need a way to build for a diverse-computing world.

What if there is another way? Progressive Web-First Apps.

Why would it ever make sense to start with a PWA experience for your new idea?

  • If you want to cast a net to reach as many people to prove out your product, the Web offers the reach. Once someone taps on a link you can get them into the experience to try without an install, and you can iterate quickly with simple A/B testing and the ability to make changes that don’t ever require an [UPDATE].
  • Chances are, you have some level of sharing. Now, no matter how a URL gets to someone, they can participate easily, and this can happen across desktop as well as mobile (and beyond). Other than some simple utilities, a huge number of my apps are getting and sending URLs out, and some are basically app browsers.
  • Speaking of desktop, while we have moved into a mobile world, many ideas can come to life in new ways on desktop and you have the ability to expand in that direction. Even today I have worked on products that have 80%+ desktop usage. Why limit yourself?

Progressive enhancement doesn’t even have to stop on the Web. If you prove things out and get to the point where you need to reach for native applications, you can! The beauty of doing things this way around though, is that you always have a funnel of new people who can access your service no matter what they are on, and for some customers they can go native if that is what they and you need.

But, starting a native app from scratch at that point sounds like a lot of work doesn’t it? You have options here too. Basecamp developers in a way that lets you bring your web investment along with you:

“We just launched a major revamp of the schedule in Basecamp 3. New calendar grid, new day drill-down, new navigation across months. It’s a big change, and we rolled it out simultaneously across five platforms: Web, Windows Desktop, OS X Desktop, iOS, and Android.

Three people did the work in less than six weeks.”

This strategy gives you control when you need to truly go native, and not waste time and effort when it isn’t needed. The features that are still in Web land continue to benefit from A/B testing and releases outside of the store. Not too shabby!

There are many other ways that you can play a similar game. For example, Ionic’s latest products are a great example of leaning into the Web. Stencil allows you to future proof yourself with Web Components all the way down, giving you a fast path on the Web, but you can take that to the native land with the backing of years of plugins.

But, let’s say you didn’t start this way, and you have ignored the potential broad Web users for your product, you are probably blind to the impact falling onto the floor.

Don’t worry, it’s not too late. In fact, there is no better example of turning this around than Pinterest.

We often hear about a new launch, but how did things really play out? Zack Argyle shares his one year retrospective.

The results stunned me:

“Now for the part you’ve all been waiting for: the numbers. Weekly active users on mobile web have increased 103 percent year-over-year overall, with a 156 percent increase in Brazil and 312 percent increase in India. On the engagement side, session length increased by 296 percent, the number of Pins seen increased by 401 percent and people were 295 percent more likely to save a Pin to a board.

Those are amazing in and of themselves, but the growth front is where things really shined. Logins increased by 370 percent and new signups increased by 843 percent year-over-year. Since we shipped the new experience, mobile web has become the top platform for new signups.

And for fun, in less than 6 months since fully shipping, we already have 800 thousand weekly users using our PWA like a native app (from their homescreen).”

Those numbers are not only impressive, they once again show the synergy with the native apps, bringing in users who may end up being happy in the web experience (including those who add to home screen) or may end up with a native app. Either way, happy customers!

ASIDE: Addy Osmani put together a detailed case study with the Pinterest team, to help you understand the work that went into this.

If you think about it, Pinterest is a great use case for this. It’s the type of experience that is on the board of content and commerce. You want to share this around, and for those who catch the URLs to join in, even if they aren’t members.

Just like Henrik, I hope we see much more of this trend. I want new ideas to spring up on the web, reaching users all over the world and giving you as much of a chance as possible to click with an audience. I am reminded of a friend, who built a learning platform that spiked in traffic. It turned out that the spike was because the Philippines ministry of education had decided to go all in on his software. He found his viability through the global reach of the Web.

And, I want existing companies to realize the low hanging fruit that is: making their website modern. On the one hand you can invision new features for your existing users, but on the other you can bring a new seamless funnel that will capture many new users from the Web.

So, crack open Lighthouse. Time for you to be the next Pinterest!

Flexibility brought to you by P, W, and A!

Leave a Comment

As I reflect on 2016, one of the highlights was working with companies who were reinvesting in the Web. I got to hear a lot of stories about their business and their technology stacks as they wrestled through how to get from here to there. It is one thing to understand that there are exciting new capabilities, but the reality is that websites are at varied stages of evolutions and there are practical constraints to work through.

You can look at this in a negative way, but you can also recognize that this is often a good problem to have. Dealing with a legacy system that runs a substantial business is a good problem indeed. It is vital to take care as you change a ship that is on an important journey, but fortunately the Web is very well suited to the job. Thanks to the loose architecture of URLs coupled with the fact that you can ship down code at will means that the logical representation of the business is very much abstracted from the physical.

Evolving your experience is similar to evolving your codebase. You make many choices that have trade offs. For example, at companies such as Google they have often taken an interesting approach of keeping One Large Codebase where everyone works as close to master as possible. What happens if you are are all evolving the same codebase together? It means that if you fix a bug in your SSL library it can be rolled out to all of your services in record time. It also means that you need to be vigilant at keeping up to date all the time, with is definitely a tax, especially if you don’t have tools to handle this.

In general it is good practice to have a strong master. I often look at the source tree and map it to a real tree. You want a strong trunk that is always growing enough to handle the branches that come off of it. You don’t want the opposite, a weak trunk with heavy branches that eventually makes the tree fall over.

How do you keep complexity down, and try to make sure that person A isn’t causing problems for person B in another part of the codebase?

One solution is small modules that can be easily composed. We see this in areas such as UNIX, node, and React. The key is the composition of the pieces, which is different to separate units that can’t be reused. Composition not solely isolation.

Native has been around long enough now that all of this has come up too. How do you handle a large codebase? What about once you have multiple apps? What do you want to share between them? There are many techniques to help here, but none are quite as flexible as the URL + Web delivery.

Speaking of which, let’s get back to evolving your Web app in 2017

After talking to many developers and companies, three patterns emerged for the journey, and I will force them into the same acronym as the latest Web revolution itself, just to be confusing:

Piece

Take one user journey, or sub-site, and make it a PWA. For example, Air Berlin did this by creating a post-purchase experience that keeps your boarding pass offline and ready for you. This then feels like a mini app, akin to early mobile apps that focus on one use case and do a good job. One of the under-explored areas of PWAs is the fact that you can mint them in any way that makes sense for your service. For example, HBO could have an overarching app for their service, but you could also choose to just have a launcher into a particular show, all in a natural way that doesn’t need multiple entries in a store if not desired.

Whole

You could take on the whole enchilada. This is ideal if you are looking to do a re-think of your experience any way. Let’s say that you haven’t done that responsive design re-do yet and have separate “mobile” and “desktop” sites? Maybe you were thinking about trying one of those shiny new frameworks that you were hearing about? Maybe your product and design team were feeling the itch anyway? Well, the water has never been warmer. If you have the buy off from the business to do this you can look at rolling out a spanking clean, offline first, super fast reliable experience that works progressively. You lucky pup!

API

Maybe there is a particular new capability that would be impactful for your business. A PM comes running in with a glint in their eye as they tell you how fantastic it would be to bump up re-engagement via push notifications. This is exactly where The Weather Channel started their journey. Once you get the infrastructure in place (e.g. make sure to get onto https) you can add a feature like push without large changes to the web app.

There are many ways to skin the cat, to start your journey to an ideal web experience, and as always, the key is to get started.

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