Is TypeScript the future of web development?

I’ve already talked about how much I love TypeScript in some of my previous posts. It allows me to be more productive, but most importantly - it improves my development experience.

Basing on the recent trends, TypeScript NPM download stats, and the general “buzz” around it, I’d say a great many people agree with my opinion. But it doesn’t mean that all do, as indicated by all the TypeScript critics out in the wild. That’s why I think it’s important to consider all different opinions regarding TypeScript, to determine what the future holds for now-successful JavaScript super-set.

Advantages

So, to try to determine what the future of any kind of product might look like, we first need to get to know its pros and cons to understand what kind of value it provides for the end-users.

In the case of TypeScript, I guess if you’re reading this article, then you probably have already heard about most of its advantages, so I’ll be brief.

Less (runtime) errors

The statically-typed nature of TypeScript is believed to result in fewer errors during runtime when compared to dynamic JavaScript. Common issues like typos, data inconsistencies, etc. can be easily caught by TypeScript during the compilation step.

Better development experience

Yet again, thanks to static typing, TypeScript can be used by modern code editors and IDEs (like VS Code) to provide the developer with almost real-time feedback, autocompletion and error highlighting.

Better code quality and documentation

Because correctly (i.e. strictly) set-up TypeScript forces you to add proper typings to all functions, classes, and other constructs, it almost automatically results in better code quality and documentation. Now, surely it won’t bring from the dead the worst of the worst codebases, but when paired with proper naming strategy, TypeScript still performs better in this area than bare-bones JavaScript.

I told you I’m gonna be brief. ;)

Disadvantages

So, while TypeScript advantages are commonly-known, its cons and all the reasons why you might not want to use it - aren’t. That’s why I’d like to take a bit more time to discuss some of the more “popular” of these disadvantages (or should I say “believes”) and possible contradictions related to them.

It doesn’t fit JavaScript’s dynamic nature

Because of TypeScript fundamental characteristics like static-typing and compilation, some say that it doesn’t fit with the JavaScript’s dynamic nature. JS is primarily the language of the Web, where nothing is static, changes happen all the time and data comes from multiple sources throughout time. TypeScript isn’t suitable for such an environment… right?

There’s a bit of truth in that claim, but it’s a bit like saying that no statically-typed or complied language is good for any “dynamic stuff”. That’s obviously not true. Sure, there’s a bit more work involved, but you can pretty easily create proper interfaces and other type structures to handle all the dynamic data in your codebase. And if you’re not willing to do that then you can utilize the any type and “fallback” to what is pretty much just JS, while utilizing TypeScript features in all the other places.

TypeScript is usually misused

So, TypeScript with its any type is perfectly fine for any dynamic code, but this leads to another problem. The any type itself, while definitely useful in a great many cases, spreads quickly and violently when not used properly. This in result, leads to pretty much all TypeScript benefits being negated. Why even use TS, when you don’t utilize its full potential?

This argument of TypeScript being commonly misused is very much realistic. Especially among TS new-comers coming from JS, or during JS to TS codebase transition, the use of any type often goes out of hand. However, a simple fact that some developers don’t utilize TypeScript correctly is not a reason to not use/recommend the language to others. TypeScript any type is a feature that can work wonders - it can save time, help transition the codebase from JS, etc., but if and only when used properly.

TypeScript rewrites are a waste of time

Speaking of codebase rewrites, you most probably have heard the stories of

Big company X transitioning their codebase to TypeScript and catching Y percent more bugs before deployment while doing all this Z percent more efficiently.

These scenarios are quite common, but it’s also well-known that rewrites of any kind result in a boost to the development experience and error minimization. So, why bother?

The time and resources required to convert JS codebase to using TS, while also familiarizing the entire team with the new tooling can indeed outweigh the potential benefits. Especially when working with huge codebases, TypeScript rewrites can even cause slowdowns and unnecessary confusion - especially when having top-of-the-line, well-tested, and well-documented JS code already.

With that said, it’s not like there are no benefits to TypeScript rewrites. It’s just that they’re a bit more… long-term. After the initial hassle of rewriting everything with proper typings included, you can expect better and faster development experience down the road.

You can achieve the same results with JSDoc

The biggest incentive for using TypeScript for me is definitely the development experience that it provides when paired with proper coding software. But the truth is, it’s not a TS-only feature. A well-known documentation format known as JSDoc can provide the same set of benefits (and some times even more), without a need for changing file extensions or “polluting” your JS code with custom TS constructs. Just good, old JavaScript comments.

If you haven’t already seen it, here’s a small example for you:

/**
 * Example function description.
 * @param {number} param1 - Number parameter description.
 * @param {string} param2 - String parameter description.
 * @returns {boolean} - Description of the returned boolean value.
 */
const exampleFunction = (param1, param2) => {
	// ...
}

So, basically a multiline comment with special marking and some @tags for different things. It’s that simple and with it, we’ve already properly documented our function with type information included! Sounds too good to be true, right? Where’s the catch?

Turns out there’s pretty much none. JSDoc is just really cool. It can easily be used to provide similar development experience to TypeScript, can be adopted incrementally without any compromises, and can also be used to further describe your code and even generate dedicated documentation from it!

But TypeScript still has some tricks in its sleeve. Check out the following comparison of TypeScript interface and variable type declaration vs JSDoc.

/** Description */
interface Example {
  /** Description */
  prop1: number;
  /** Description */
  prop2: number;
}

/**
 * @typedef {object} SecondExample - Description
 * @property {number} prop1 - Description
 * @property {number} prop2 - Description
 */

/**
 * @typedef {{prop1: number, prop2: number}} ThirdExample - Description
 */

const exampleVariable: Example = { prop1: 1, prop2: 2 }
/** @type {SecondExample} */
const secondExampleVariable = { prop1: 1, prop2: 2 }
/** @type {ThirdExample} */
const thirdExampleVariable = {prop1: 1, prop2: 2}

I think you already see where I’m going with it. TypeScript “syntactic sugar” while not necessarily more capable than JSDoc, is certainly much cleaner and plain better for defining complex types and interfaces. In addition to that, JSDoc can still be used with TypeScript for better describing your code, while types are handled the other way, or during the transition period from JS to TS codebase, without relying on any any types.

Lastly, even though you can configure your tsconfig.json to type-check JS files with the help of JSDoc as well, getting it into strict mode - the one in which TypeScript is the most well-known for - can yield results that are described as “surprising” by the official documentation (aka not working greatly).

So what’s the future?

With all these pros and cons of TS in mind, I think we can now see where it’s going. Honestly, as you’ve probably heard a couple of times now - TypeScript isn’t going to replace JavaScript any time soon. Personally, I’d go even further than that and say that it’ll never do - it wasn’t even designed or meant to in the first place.

TypeScript builds on JavaScript as a solid foundation. It’s meant to improve the development experience and code quality, but that’s it. It was designed this way and this way it should stay. Because realistically, how would you even imagine native TypeScript support in the browser? It could speed up the execution time because of the additional typing information and potential optimization related to it, but would also increase the bundle size by a noticeable margin, slowing down the entire process of downloading and executing the code, thus negating any potential performance benefits. And if it was to compile to some custom, highly optimized format, then we’d lose the any type which is, after all, one of TypeScript’s fundamental features, and potentially end up with just another WebAssembly (or should I say AssemblyScript).

To sum it up, I think TypeScript will continue to grow in popularity for the foreseeable future. It provides great development experience, doesn’t have much competition, and enjoys high adoption rates among (especially new) open-source projects.

Bottom line

So, that’s my opinion. But again, I’m a kind of guy who’s capable of rewriting entire libraries in TypeScript just to get these somewhat negligible in such cases benefits. What are your thoughts on TypeScript? Are you using it? Why/why not? Do you see any additional advantages/disadvantages that I didn’t mention? Leave all your thoughts in the comments below!

For more up-to-date TypeScript and web development stuff, follow me on Twitter, Facebook, or through my newsletter. Thanks for reading and happy typescripting! ;)