by author Kristofer Selbekk
In this article, we’ll look at some of TypeScript’s main benefits, and what alternatives are out there.
In order to look at how relevant TypeScript really is, we need to look at the main benefits we get from using it in our codebases. Here are some of the main upsides from going from .js to .ts:
Applying a type system to your codebase makes you much more confident your code will work. You can specify what kind of arguments are required, and enforce those constraints with near-instant compiler feedback. This makes it much easier to remember to cover all edge-cases, and to write clean, expressive APIs.
TypeScript has kept on improving its type system, adding improved type inference and even template string type support in later versions. All of these continuous improvements has made TypeScript’s type system pretty bullet proof over the years. Now, if they could only make those error messages a bit more readable 😅
Another upside is that you can move from very general types (like
unknown) to more specific ones whenever you have the time. Iterating on your types like this – especially while developing a new function or class – makes the typing process incredibly smooth.
A little caveat here - by adopting TypeScript gradually, you’re going into a weird state of “type limbo” for a while, where you’ll have some, but not complete type safety. Just make sure you push on through to where all of your codebase is transitioned into the warm grasp of type safety.
TypeScript is actively maintained and developed by no other than Microsoft, the new knight in shining armor of open source software. With their financial means, the TypeScript team is sure to keep on improving both the language and the tooling surrounding it.
Being owned and operated by a tech behemoth hasn’t stopped a huge community from forming though, and the development process has been made much more open and collaborative over the years. With both a substantial backer, and a tight-knit community, TypeScript is sure to thrive for the foreseeable future.
Dart has been around for a few years, but has really blossomed the last couple of years. One of the main reasons of its latest upswing in popularity is the cross platform app development platform Flutter, and how it’s used there.
That being said, Dart has a much smaller community behind it than TypeScript has, which comes with a bunch of tradeoffs. It’s a different language with different syntax, and it feels more like learning a new language than adding a few features to an existing one, like TypeScript does. Finally, there’s no incremental adoption path for Dart - it’s all or nothing.
You can read a much more in-depth analysis of Dart vs TypeScript here.
Elm is known for two things - having the “world’s most polite compiler”, and guaranteeing you no runtime errors. The compiler comes with really nice suggestions whenever you goof up, making it a lot easier to pick up the unfamiliar syntax. The no runtime errors guarantee is nothing short of extraordinary, but it comes with a lot of restrictions to how you can do things.
There are still a few features missing, like code splitting, but if you’re building small apps, or have a micro frontend architecture, this might be right up your alley. Read more at elm-lang.org.
A couple of years ago, Facebook’s own type system – Flow – was competing neck and neck with TypeScript for the crown of type systems. Flow’s claim to fame was that you really didn’t need to write that many type definitions; great type inference and refinements would give you precise types at breakneck speeds.
Flow is pretty simple to get started with - you add
Flow is backed by Facebook. This used to be a great asset - some of the world’s greatest developers would be working on this codebase non stop! It made Flow gain traction and build a huge community quickly. However, soon, the Flow team had to prioritize Facebook’s internal needs over the wants of the community.
Flow is still a great tool, but its popularity has fallen drastically the last couple of years. It might be the right fit for you, but be ready to implement a few type definitions yourself.
Debugging a web application in production may be challenging and time-consuming. OpenReplay is an Open-source alternative to FullStory, LogRocket and Hotjar. It allows you to monitor and replay everything your users do and shows how your app behaves for every issue.
It’s like having your browser’s inspector open while looking over your user’s shoulder.
OpenReplay is the only open-source alternative currently available.
Happy debugging, for modern frontend teams - Start monitoring your web app for free.
There are some great alternatives out there, but to me at least, TypeScript is still the best tradeoff between community, features and adaptability. What do you think?