The Doomed Rewrite
NOTE: This was originally posted on my own corner of the Internet.
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!”
— Defaults
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!
