Why Sentry rewrote its codebase from JavaScript to TypeScript


  • Sentry is a billion dollar startup that makes open source error monitoring software.
  • Over the past 18 months, Sentry has rewritten its entire front-end code base from JavaScript to TypeScript.
  • The developer team has now increased their productivity and fewer bugs in production.
  • See more stories on the Insider business page.

After 12 months, 95,000 lines of code, and the work of dozens of engineers, Sentry – a startup that makes open source development software – has finished rewriting its entire front-end code base from JavaScript to TypeScript.

The company decided to embark on this massive endeavor because its engineers realized that with JavaScipt, they were shipping software bugs that Typescript would have detected automatically.

26-year-old JavaScript is the most popular programming language – a stunner 97.3% all websites use it – but TypeScript is a newer, more modern language: Microsoft launched it in 2012 as a powerful alternative to running large-scale applications, better at automatically flagging potential problems for them. developers.

While the effort to make the change took Sentry much longer than expected – the engineers had an “over-ambitious” plan to complete it in about four months – it created a wave of benefits, including productivity. increased, the company said.

Here’s why the startup (valued at $ 1 billion following a $ 60 million fundraiser in February) decided to make the change – and why it’s recommending it to other companies if they’ve encountered any JavaScript errors.

Why Sentry decided to make the switch

When the founders of Sentry started building their product in 2008, TypeScript didn’t even exist yet. However, for nearly a decade the company had a “source of trouble” with JavaScript, according to Sentry lead developer Mark Story.

“JavaScript isn’t exactly a very sustainable language,” he told Insider. “He’s not known for his resilience.”

In the fall of 2019, the company was shipping “more front-end bugs than was acceptable,” many of which were so-called runtime errors, or bugs that occur while software is running.

Story and others realized that TypeScript’s features would have allowed it to catch these kinds of errors before the code was uploaded to the website. The team estimated that it would take between five and eight engineers about four months to switch to TypeScript. While some feared that this was an inefficient use of engineers’ time, they realized that in the long run it could help the company save time by avoiding mistakes.

“There was initially some reluctance from some people about the cost and complexity that it introduces,” Story told Insider. “But these people didn’t have good solutions to avoid all the runtime bugs.”

So in August 2019, the team planned to change their codebase by the end of the year, an aggressive schedule that would have required engineers to convert 74 files per week. They would quickly understand how unrealistic this initial timeline would become.

Reality was much more intense than expected

The team has divided their switching strategy into three phases.

The first was to train the team on how to code in Typescript, which involved providing additional resources and materials. Sentry shared a list of introductory articles and set up a tech committee that helped train the team and carefully reviewed all of the new code.

“We didn’t approach it from a ‘stick’: it was more of a ‘carrot’ approach. So instead of hitting people up and saying ‘Use TypeScript!’ more like, “If you use TypeScript, you won’t get those kinds of bugs,” Story said. “Internally, we approached it from a pedagogical rather than a punitive angle.”

Once the team was trained in the new language, the second step was to write all the new projects using TypeScript. Creating new features in TypeScript also helped developers gain experience while working on low-risk parts of code that customers weren’t exposed to.

In the third and final step, the team had to convert all existing JavaScript files to TypeScript. They predicted the project would be finished by the end of the year, but by that point the team had only completed 40% of the files they needed to convert.

Sentry's progress to the end

Their progress was only 20% after 8 weeks, which meant they were not close to their goal.


The workers had too much new work to spend so much time on the conversion.

“We didn’t factor in the ability to maintain energy levels for that long for so much work,” Story said. “People just didn’t have the time to focus on the backfill job, so it just blew our deadlines.”

Throughout 2020, contributors have felt exhausted and discouraged by the duration of the project. However, a moment of light at the end of the tunnel happened over the summer: the team hit the 70% conversion mark and felt excited to cross the finish line.

They rushed to the end of the project, which took a total of 18 months from start to finish. In the process of migrating from the frontend codebase to TypeScript, the team created over 1,915 Typescript files and ultimately did not have any JavaScript files.

The benefits of TypeScript and what the team learned

Since the team completed the change, the company has now increased productivity and better error protection, including fewer bugs in production, Story said.

Because of the way annotations work in TypeScript, developers also have a better experience where they spend less time on documentation. TypeScript also has an active community, which came in handy when the Sentry team needed to ask questions of other developers.

He recommends that any other interested business making the switch slow down as well (instead of trying to extract all the JavaScript at once).

“The approach we have taken is the route I would suggest – it has the downside of being slow but does not require stopping other products to work and allows you to focus on accuracy versus completion, ”Story said.

Once the team agreed to miss their initial schedule, they gave themselves permission to gradually and carefully scale down the project instead of rushing. This allowed them to balance the enterprise scale with the other important work they needed to do to continue developing the Sentry software.

Overall, Story says the project has been of great benefit to the company and that he would recommend a similar strategy to other companies in the same position.

“I would recommend it if other organizations encounter the types of errors that TypeScript can help with,” Story said. While TypeScript may not be able to solve all of the problems in an organization, “it can help solve a number of problems that are difficult to spot during testing and revising code.”

Leave A Reply

Your email address will not be published.