Javascript to a strongly typed language..

What approach can one take to move an existing Javascript code base to a strongly typed language?

Published: Wednesday, Jan 19, 2022 Last modified: Sunday, Jun 9, 2024

Less bugs wanted

There comes a time when a weakly typed Javascript project wants to adopt strong typing to improve quality and avoid bugs.

Given the choice:

  1. TypeScript by Microsoft
  2. The Go language (aka golang) by Google
Typescript logo Go logo

What are the arguments for and against?

Pros of Typescript

  1. Assumed easier migrate an existing Javascript code base, doesn’t require a “rewrite”. However the process of getting Javascript 100% migrated isn’t as clear as it might be if you used Go. Update: Tools like might help!

Cons of Typescript

TypeScript is a scripting language for C# –

  1. Tied to the Microsoft ecosystem
  2. Package dependencies are a mess, some have Typescript bindings, some don’t. Lots of blind spots.
  3. Lots of churn and difficult choices need to made wrt tooling
  4. Different Javascript styles can make the code base confusing
  5. Slow
  6. Some argue that Javascript with JSDoc is a better approach

Pros of Golang

  1. Simple, well-designed end to end ecosystem supported by Google
  2. Better error handling
  3. Faster performance, which can be further enhanced to concurrent execution (not limited to being single threaded)
  4. Far better package design
  5. Easier to maintain in the long run
  6. Produces static binaries which are easier to deploy
  7. Go can be learned in a weekend
  8. Moving between Javascript and Golang is actually suprisingly simple

Cons of Golang

The biggest con of Go isn’t that people don’t know it - it’s that they refuse to learn it. They’ll die with a cold, hard grip on their overly-complicated polymorphic inheritance systems and useless utility libraries. –

  1. Less people know Go than Javascript
  2. Assumption that the JS isn’t front end code. Of course Go isn’t a browser language and hence JS is far better suited for dynamic frontends, e.g. using
  3. Again if you have JS on the frontend, you might argue it’s easier to hire or form a cross-functional team that can switch between front and back end.