Materialized Typescript Risks

Risks when converting a javascript codebase that’s typed with JSDoc to Typescript.

PDF (drucken)

This is a concise look back on a (still) partial typescript conversion of a Javascript codebase with around 200k LOC.

Before we started the conversion, I wrote down risks I saw. A year later I looked back and reported to the team which of these actually materialized.1

TL;DR: most did.

I was critical from the start, so take this with a grain of salt.

The overall assessment of the outcome of the conversion differed between people (many like it) but the general agreement is that there is no way back.

Upsides you would miss by only looking at the risks: Many of our formerly pure Java-devs are happy with Typescript and we now have API description through autogenerated types. Also JSDoc-tooling is worse than Typescript tooling in most IDEs. But not in Emacs … (insert snark about other tools ☺)

Expected and came to pass

  • Loosing time with bike-shedding all the things again
    • Many Discusssions about TS instead of our own codebase.
    • Lost at least 3 months of structure discussions, so the structure became more inconsistent, making it harder to find stuff by intuition.
  • Use more and more TS features that make programming more complex
    • Adding many options quickly, problems to understand the many ways to define types. Need more time to think about stuff.
  • Rush the conversion, so the path back will be too expensive: compiling TS away will be worse than with the old JSDoc
    • Had to remove some JSDoc typings because of inconsistencies in the IDEs.
    • After three months 30% were already converted ⇒ old JSDoc typings lost.
  • eslint-changes due to problems with TS => infrastructure worsens; worse linting
  • Changing more flexible approaches that did not work well with TS
  • Typescript nudges us towards more complexity.
    • Java-Style in Web => More code in pure TS instead of using the browser as a platform
  • Developed dependencies on tooling that doesn’t work as well in Emacs.
    • Working with Typescript is much slower than with JS, because the native JS2-mode does not support TypescriptDependency on the much slower language-server interaction.2
  • IDE performance
    • All deactivated Sonar Lint for Typescript in IntelliJ, because it is too slow.

Expected, unsure

  • Increased build times?
    • they tripled within a year of the introduction of TS, not sure about the cause.
    • avoided most direct build time effects by transpiling via Babel instead of via tsc.

Expected, can only be seen over time

  • Disconnect from JS standard / being locked in a Microsoft-controlled language.


  • Emotional Lock-In of Java devs.
  • Code reviews take 50% longer due to weak or strange typings.
  • Cannot simply cherry-pick a fix from a converted Typescript file to its Javascript original in an earlier release (we could have expected this).

General drawbacks

  • With typescript we leave the path of using only transpiling that will go away automatically as support for modern Javascript improves in the browsers of our customers (IE11 now died — we were so close — now the culprit is Safari).
  • Browser-based debugging of typescript-tools gets us into source maps, but we cannot test code live in the web console and then copy it verbatim into a file (except if Browsers gain native TS support — would that be available in Firefox, too, or would it create more lock-in?).

Conclusion: conversion from JSDoc to Typescript

  • ✔ Many Java devs lost their fear of the web as platform.
  • ✔ More people write type information.
  • ❢ Most of the expected risks materialized.
  • ❢ Our infrastructure suffered due to incompatibilities.
  • ❢ We will never get rid of transpiling. What we ship to the browser will never be what we write.
  • ❢ We spent three months mostly talking about Typescript during which the codebase grew with too little coordination. Whatever you choose, avoid this!
  • ❢ We moved faster than planned, so we have no viable way back, even if we decided to go back.

This is a comparison to a pure Javascript codebase with JSDoc. From that experience, I consider such a conversion as a net-negative. Others like it a lot, though, so — as said earlier — take this with a grain of salt.



I asked for — and got — the OK to write about these here.


The language servers used via other IDEs are also much slower than JS2-mode, but devs using these are used to the slowness. And yes, our codebase is kind of big.

ArneBab 2023-02-27 Mo 00:00 - Impressum - GPLv3 or later (code), cc by-sa (rest)