How Braze Deprecated RequireJS and Modernized Our Front-End Tech Stack

For thousands of marketers around the world, the Braze dashboard is where they make things happen. The work involved in ensuring that this interface is at its best is undertaken by a wide variety of different people, from product designers to engineers. And while these optimizations are often about the user interface, just as frequently, they’re about the technology that supports the dashboard.

In recent years, one of the most significant shifts in this area was our deprecation of RequireJS and migration of the dashboard to Webpack, an effort spearheaded by Braze Senior Software Engineer Alex Guerra. Let’s take a look at Guerra’s essential contributions to this project, the ins-and-outs of the migration process, and how the subsequent speed improvements made it easier to solve coding issues related to the dashboard.

From Hack Day to Migration: How It All Started

It’s funny to say, but I ended up working on the RequireJS deprecation project almost by accident. I’ve been working on Braze Engineering’s Messaging and Automation team for about eighteen months, a team focused on optimizing the back-end message-sending pipeline for our core product. At some point, I asked another team member how the front end worked—and while he had a vague idea of it, he wasn’t clear on the exact details.

That got me curious; I really wanted to understand how our dashboard worked. And because Braze holds hack days that allow employees to pursue passion projects, I decided to take advantage of the next hack day to explore the ins-and-outs of our dashboard by mapping out and documenting the front-end code. Around this same time, the Braze dashboard team had been looking at making the switch from RequireJS to Webpack, which was expected to be a major undertaking. But during the course of my exploration, I started to see a path forward that I thought could help the dashboard team automate some of the work involved in upgrading the software supporting the Braze platform’s front end.

But to get the full picture of what we were looking to change and why I got so excited about it, you have to understand the differences between RequireJS and Webpack.

Evolving the Braze Dashboard: RequireJS vs. Webpack

So, what is the Braze dashboard, anyway? At the most basic level, it’s a single-page JavaScript application. And when a marketer visits the Braze website and logs into our platform, the web view that they receive is generally informed by a bundled version of the dashboard’s code. This bundle, which collects disparate files for production, has several different optimizations applied to them that help the dashboard function more efficiently, including:

• Minification to allow it to load faster
• Automatic code modifications that let the dashboard adapt to different web browsers
• Code splitting to allow front-end code to load on demand as it’s needed

At Braze, that asset bundling process for our JavaScript code was originally supported by RequireJS, a JavaScript file and module loader designed for web use. But over time a consensus grew with the Braze Product and Engineering organization that we needed to evolve the way we were bundling code for the dashboard.

The biggest motivating factor was the need to speed up the build process. A developer generally needs to go through the build process every time they want to validate the changes they’ve made to a piece of code, to ensure that their adjustment is impacting the software the way they expect. Once it was clear that Webpack—an open source JavaScript module bundler—could carry out these complicated builds more quickly and effectively than RequireJS, we knew it was time to make the switch.

In particular, we felt that making the change would have three key benefits:

1. A Unified Code Base

At that point, the dashboard’s front end was essentially split in two, with one half written in CoffeeScript and built using RequireJS, while the other was written in JavaScript and TypeScript and built with Webpack. As you might expect, sharing code across the divide was an issue and in a lot of cases it took some very brittle hacks to make it all work. So one major upside of doing the work involved in the migration to a single process was that it presented a golden opportunity to truly unify—and modernize—the code base.

2. Shorter Feedback Cycles

As I mentioned above, one of the big priorities associated with this project was finding ways to shorten the feedback cycle for engineers working on the dashboard. Back then, if you made a modification to the front end code, the bundling process with RequireJS would take an average of three minutes—and sometimes it could take as long as eight minutes. That’s a long time to make an engineer wait to find out if their code is operating normally. With Webpack, there’s an initial startup time that lasts about 90 seconds, but every additional change can be carried out significantly faster, allowing engineers to make better use of their time and get more done.

3. More Effective Troubleshooting

Finding and addressing code errors is an essential part of any engineering team’s work. At Braze, we use a product called Sentry that helps organize and trace the source of problems when they surface in the production dashboard. But because that code was CoffeeScript built with RequireJS, when it got compiled and minified, the descriptive name of a function like “navigateToPill” would be renamed to something like “a.” That, in turn, meant that we’d see a type error in “a” on line one, column 200,000—which, as you’d imagine, made it a lot of work to determine the source of that error. Webpack, on the other hand, has a tool called Source Maps that allows teams to take that minified code and map a given column and line to the source file; that means you’d get Sentry reports saying that “navigateToPill” had an error on a specific line, making it easier to solve problems faster.

The Migration Process: Moving from RequireJS to Webpack

The need to make the switch from RequireJS to Webpack was clear, but the scale of the undertaking meant that they expected the process to take at least a year and involve a lot of complexity and engineering bandwidth to achieve. The thought at the time was that we were going to have to systematically go through the code base section by section and manually migrate everything, which would have been really onerous.

My breakthrough, if you want to call it that, was realizing that I could write code that was capable of modifying the Braze dashboard’s code in bulk through an automated process—and also un-modifying our code, if we needed to roll back these changes quickly. I ended up doing a proof of concept following my hack day project, just to show that it could work, and then kept working on it in my spare time as a sort of passion project.

That said, things didn’t really take off until Greg Beaver—who’s a Senior Software Engineer on the Braze Dashboard team—got involved. He was able to take the scripts that I’d written as part of my proof of concept and incorporate them into a tool that we could share with other engineers. That, in turn, meant we could migrate from RequireJS to Webpack without forcing all the engineers working on code related to the dashboard to stop while we did it; instead, they were able to use the tool to automatically bring any code they were working on in sync with the overall changes.

The tool ended up being so fast—it only takes about two minutes to run—and worked so well that while we were making preparations for the migrations, we actually had an engineer leverage it as a workaround for the slow builds associated with RequireJS. They just converted their branch over to Webpack, made the change they needed to make, and then converted it back so they could commit it in the old code.

With this new capability at our disposal, our migration plan was to run Greg’s tool on our main branch every night for a few weeks and get people to manually review in the QA environment off that branch, just to see if anything was broken. Once we were confident that everything looked good, we briefed the rest of the organization about the planned update, walked them through how they could migrate their code from RequireJS to Webpack, and gave them a heads-up on a few key considerations before they got underway.

Thanks to our approach, a project that was expected to take over a year ended up being wrapped up in just three weeks, which is pretty incredible. Even more unexpected was the impact of the migration—in particular, the build process on Webpack now generally only takes about a second, reducing the time needed for each code check by more than 99%.

At Braze, we’re committed to building an environment where individuals like Guerra can make the most of their unique perspectives and talents. Are you someone looking to push boundaries and reimagine what’s possible? Check out our careers page to learn more about our open positions.