Quitting CoffeeScript? First, Teach Everybody Typescript
These are the highlights from a fantastically in-depth episode of Tern Stories. The whole episode is on YouTube, Spotify, Apple Podcasts, or wherever you get your podcasts.
Recently, I talked with Hal Anil, Staff Engineer at Braze, who led a multi-year migration from KnockoutJS and CoffeeScript to React and TypeScript.
If you were writing frontend code in 2013, you probably used that stack too. CoffeeScript was everywhere. Knockout was the safe bet. React barely existed. But by the time Hal joined Braze, React had clearly won—and Braze’s old stack was clearly holding them back. Like a lot of early-2010s stacks, time wasn’t kind.
“I don’t think it was necessarily a straw that broke the camel’s back. There were a bunch of things that kind of coalesced together.”
Here’s what piled up:
- The tech was dead. KnockoutJS and CoffeeScript were no longer maintained, with few updates and shrinking community support.
- Hiring was hard. Few engineers knew (or wanted to learn) outdated tools, making it tough to attract talent.
- Developer velocity suffered. The stack made it difficult to write safe, scalable code—especially compared to modern frameworks like React and TypeScript.
- Design drifted. Without a shared system, the UI had started to feel inconsistent, like a patchwork of unrelated apps.
- The business felt it. All of the above made it harder to ship features quickly and confidently.
By the time Hal joined, the case for migration wasn’t theoretical—it was obvious. The stack had become a bottleneck, and the company needed a plan to move forward.
Teaching the Future Stack
As a first step, Hal’s team ran workshops. The goal wasn’t to migrate—it was to teach. They started with the fundamentals: what React and TypeScript actually are, how they differ from Knockout and CoffeeScript, and what life in this new stack could look like. They also used these workshops to build a strong testing mindset, wrapping new components in Jest and Enzyme (then eventually Cypress) to build confidence in the features they were building.
This wasn’t a stealth training program—it was an early way to build alignment. Engineers didn’t need to be convinced to love React; many were already curious. What they needed was a way in.
“We weren’t just dropping a design system on people and walking away. We were sitting down with teams, showing them how to think in React, and helping them imagine what building in this world could feel like.”
React Tables without Tears
One of the earliest signals that the migration was working came from a surprisingly simple component: a collapsible section used for surfacing real-time errors in marketing campaigns. It wasn’t flashy, but it solved an immediate problem—and that mattered. Teams saw it, adopted it, and told their peers. Hal’s team realized the best way to build momentum wasn’t mandates—it was usefulness.
The same principle applied to more complex UI, like Braze’s data tables. These had previously been powered by SlickGrid, a system deeply embedded across the product. Rather than force a rewrite across both frontend and backend, Hal’s team engineered a new layer using React Table, styled consistently with their design system, and abstracted enough to work with existing APIs. “We made it a frontend-only swap,” Hal explained. “That made a huge difference. The second it becomes a backend project, people get nervous. This way, they could just drop it in.”
Automation and the Art of Compromise
Some parts of the migration were easy to automate—mostly because they weren’t that different. CoffeeScript compiles to JavaScript, so moving between them was straightforward. But JavaScript to TypeScript? That was another story. Type inference broke, hidden bugs surfaced, and simple conversions turned into deep refactors.
Hal’s team knew they couldn’t automate everything. So instead, they built tools that made the hard parts feel safer. One set of abstractions wrapped common TypeScript patterns, helping engineers scaffold types gradually and avoid getting stuck on edge cases. It didn’t eliminate the work—but it made it feel tractable.
That’s what mattered. “If something makes your life easier today,” Hal said, “you’re more likely to keep going tomorrow.” The goal wasn’t perfection—it was locking in progress, one step at a time.
Don’t Say Migration
Migrations aren’t just technical—they’re emotional. Hal became acutely aware that the word “migration” alone could spike heart rates. So instead of pausing product work to focus on infra, Hal’s team did both. They built components that solved real problems for real teams—components that happened to move the migration forward too.
“It freaks people out,” he said. “You say ‘migration,’ and they picture five years of no new features.”
This wasn’t just about momentum—it was about credibility. By prioritizing useful building blocks, delivering fast, and helping teams ship product faster, Hal’s team proved the migration wasn’t a tax. It was a path to velocity.
And that made the rest of the change easier. When engineers feel like their day-to-day is improving—not being interrupted—they’re far more likely to embrace the new stack.
Key Lessons from Braze’s Frontend Migration
- Teach first. Before migrating anything, show people what the new world looks like—and why it’ll make their lives better.
- Build what unblocks. The best migration components are the ones teams already need. Usefulness drives adoption.
- Tool for momentum, not magic. You won’t automate everything. But you can build tools that make the hard parts feel doable.
- Ship while you migrate. Migrations don’t have to pause product work. They can accelerate it—if you’re smart about how they show up.
- Words matter. “Migration” can scare people. Break the work into smaller pieces, and make each one feel like a win.
The Outcome
Today, Braze’s frontend is fast, modern, and consistent. React and TypeScript power a shared design system used across teams. Developers ship faster. Designers see their work land accurately. And migrations, while never easy, feel possible.
All because one team decided to start by teaching—and then kept making the next right thing a little easier.
You can follow Hal Anil on LinkedIn and watch the full conversation on YouTube: