TypeScript: JavaScript + Types = Awesome Developer Productivity

🔥 Jaime González 🔥 on January 17, 2019

This article is a chapter from JavaScript-mancy OOP: Mastering the Arcane Art of Summoning Objects in JavaScript a breathtaking story of EPIC propo... [Read Full]
markdown guide

It seems "TypeScript" boom has started. I think it would have been great if the article was split in parts.


+1, but huge kudos to Jaime for putting it out. I will go through it while learning TypeScript.


In all seriousness, we need to organize a special task force to lynch people who complain that "it's not just JavaScript". They are the reason nice syntax like newtype constructors and methods on these primitive newtypes isn't getting added.
Why do the people actually using TS every day have to suffer just because of criticism of those who haven't been onboarded yet, and maybe never will?


No lynching! Just hugs!

I think that anything on the side of type annotations is fair game.


First of all thumbs up for mentioning the disadvantages as well. I think we should all try to be a bit more objective in our opinions than just merely following trends.

Well basically all the points you mentioned as advantages doesn't sound like they are worth the trade-off. But that's just me. I can agree only with the:

Great for large-scale applications and teams.

But do we all really work in such conditions? I highly doubt so.

The disadvantages on the other hand surely look like minor things:

  • TypeScript requires a transpilation step
  • You need to learn type annotations syntax and related artifacts
  • It is verbose
  • It sometimes falls out of line with the ECMAScript standard

But that's what hampers your productivity and slows you down.

The whole point of the dynamic languages to exist is to allow faster prototyping.

And the first thing we think about prototyping is the initial phase of a project.

But (micro) prototyping happens all the time:

The act of human being sitting behind a keyboard and writing commands to a computer to execute is an act of prototyping.

Anyway, apart from probably being a good fit for really large projects, TypeScript also helps to alleviate the fact that the majority of the web developers had started their careers using dynamically typed languages, and know nothing about types.

Types are always there, but the dynamic languages, like JavaScript, require a bit more diligence on the developer side, and a prior knowledge of typed languages.


This Cost vs Benefit Analysis of TypeScript recently came out. You might want to check it out.


Awesome! Thanks for sharing! I really enjoy reading Eric Elliot 😀


What do you think about the alleged "Cost of TypeScript"?

Personally, I think it's definitely a velocity improvement, both in legacy code and greenfield, because the main benefit is developer tooling and not release testing, unlike what that article focuses on.

Do you think this article is just capitalizing on the TypeScript hype?


I think it's great that people have different opinions and points of views. We're all the richer for it :D You need sceptics to keep us all honest and continue improving things.

I read the article a while back but I remember it had a couple of things that bugged me:

  1. It seems to present a false dichotomy which is TypeScript vs Code Reviews/TDD, etc. As if adopting TypeScript means letting go of great development practices like code reviews, TDD, automated testing, etc. TypeScript is just one tool more that makes you more productive in addition to all your current arsenal of tools and practices.
  2. It seems to equate the ease of use of TypeScript with other type inference tools like tern-js that are much harder to setup. TypeScript works out of the box. tern-js doesn't.

But as said, I read it a while back and I may have misunderstood him. I think that regardless of the costs, all in all, he seemed to have a good opinion of TypeScript. I think that a lot of the pain points that Eric is experiencing with TypeScript stem from the fact that he uses a very FP-like way of programming in JavaScript and TypeScript isn't as feature complete for specifying the types of FP constructs he favours like higher order functions, etc.


TypeScript seems like mollycoddling for developers who are unwilling to work / are incapable of working with JS as it is, and don't want to change their habits coming from a strongly typed language - at the expense of more complex tooling, and a runtime overhead


I see this exact same comment on pretty much every article written about typescript. It outs you as someone who doesn't fully understand what typescript is or how it works (or at the very least hasn't had a chance to work with it for a long period of time).

This statement is almost like saying, "RUST seems like mollycoddling for developers who are unwilling to work / are incapable of working with C". Nope, RUST is simply just a better, safer alternative for system level programming.

Typescript is simply just an better alternative to javascript for web and node applications ( "applications" is the keyword here). Should you take time to migrate your small local business websites to typescript. Probably not.


1: The tooling complexity is a 1 time cost. A lot of times you already have bundling or babel setup and it's as simple as adding 1 additional step.
2: You can still write the EXACT same javascript that you were writing before, but now with the options to have types. The transpired code will be pretty much the exact same as what you would have had without types.

3: The dev productivity and code resiliency gains that you get from having a fully typed code base are immeasurable.
4: The additional code features that it does add, are added with the sole intention of fixing things that javascript has messed up. The typescript team has expressed that it is a priority to keep typescript as close to js as possible.

I've yet to find someone who has really made the transition and regrets it (I'm sure they are out there but they must be a minority). In fact, once you pick-up typescript you will DREAD the thought of working without it.

There's a reason it's growing so fast. My most sincere advise would be to not be one of those guys who resists change and gets left behind because they are simply stuck in their old ways!


The compiler removes all types during the compilation process, which means that there is no possibility of runtime overhead. Maybe you are referring to some polyfills for things such as async/await when you target ES5.

These polyfills are required if you don't want to work with callback hells. A polyfill adds some runtime overhead but it is not a TypeScript weak point: you will have the exact same problem if you use JS with Babel.

Also, assuming that TypeScript fans are "unwilling to work / are incapable of working with JS" seems completely bias to me.

After working many years with TypeScript I can say without doubts that daily work tasks such as refactoring can take a significantly smaller amount of work thanks to the help of the TypeScript type system.


TS is designed for large projects with lots of people.
JS is just fine in small projects, with people that know what they are doing and communicate well.
I wouldn't dismiss strong typing as just a habit, it does have some benefits.
Also, there is no runtime overhead - TS compiles to JS, readable JS at that.


I work on a big team writing typescript every day. The more I use typescript the more I dislike it. Yes, there are all the "super cool reasons" people have about typescript "being safer" (it's not) or speeding up project development by shortening the debugging process (it doesn't). It is very, very hard for me to see any true value to writing a bloated version of a language that trans-piles to the same language it bloated in the first place. My experience, lots of claims about typescript that look good on paper, don't really pan out in real world development (as in, if it does help in the ways that it claims, the amount it improves is so minimal that I can't perceive it). I've said it before and I'll say it again, typescript is made for developers that hate javascript and want to not write javascript, simple as that.

Just to be clear, I personally hate typescript, but to anybody out there who loves it, relax, its cool. I'm glad you like it. And as a stand alone language, I would love writing typescript, I just hate writing a bloated superset of javascript that is trans-piled back to javascript. I think the maker of Node.js is actually about to release a new project, basically Node but with typescript (not using typescript to write javascript, but actually server side code that is just written in typescript). And if/when that happens, I'll fully support it and hope it takes off. But until then, I'm hoping that Hypescript stops being cool...

Yeah good point. I suppose that is pretty much what I meant. In all honesty it isn't something I've been keeping up with strongly, last I heard about it, it was still in the planning to do this but haven't started phase (so quite a while...) so thanks for sharing that link! ;)


The last time I looked at the resulting compiled JS, it was readable, sure, but the amount of superfluous 'belt and braces' code that ended up in there messed with my head. JS written by hand would have done the same job more efficiently - minus all the tooling, transpiling etc.

It just seems a waste of time to me. Each to their own I guess

Really? That sounds shocking to me.

Can you please post some of the

superfluous 'belt and braces' code

The only thing I ever found superfluous in TS output was the import/export syntax when converting to commonjs modules.


I disagree, but I would as a lover of TypeScript. The last language I preferred wasn’t strongly typed, and I find it to be a relief.

The tooling isn’t all that complex—today you can throw Parcel into a project and mostly forget about your TypeScript configuration, and my editor is built in the same language, so the tools work very well together.

I’m not sure what you mean by runtime overhead. It’s JavaScript by then, and Interfaces—the biggest win for the work I’m doing—don’t even compile.


Totally agree I have to do c# back end and it takes so much longer and is so much more complex while trying to defend having the front end converted to typescript.


Hi Jon! Thanks for your comment! :D hehe Did you know that the whole point of the JavaScriptmancy series was to teach C# developers that vanilla JavaScript was pretty awesome (when you actually got to learn it)? xDD

I remember that when TypeScript came out (I think it was around 2014 for the 1.0 release) I was quite sceptical about the whole thing. I went from C# to JavaScript and even though I loved C#, I really enjoyed the freedom from types in JavaScript. Particularly when doing object composition patterns that required a lot of boilerplate in C#. So I was worried that TypeScript would be just C#-ifying your JavaScript :D.

Anyhow, I think that the project has improved a lot since the early beginnings and I celebrate their success and the new ideas and great developer experience they've brought to JavaScript.

One cool thing about web development is that it is the meeting place for a lot of different communities of developers that wouldn't interact (so much) otherwise and, as such, it becomes a great place for cross pollination and sharing ideas and things that have worked great for these particular communities. One of those examples was CoffeeScript, and another one is TypeScript.

I see TypeScript as, "yo! We've been using static typing to provide great compile time checks and awesome developer productivity for years. Perhaps we can bring that same experience to the web". This developer experience naturally feels more comfortable to developers with strongly typed backgrounds since they get to use a lot of the things they're accustomed to.

A great thing for the rest of the JavaScript developer community is that TypeScript is very respectful of the nature of JavaScript. A good example of this is that TypeScript has structural typing (that is duck typing) as opposed to a nominal type system like Java or C#. The types of things are defined by their structure rather than by a name.

In regards to more complex tooling, I think that for most projects there's not gonna be a big difference in tooling since either you're gonna have TypeScript or Babel. Since types disappear after transpilation and you're left with JavaScript, I'm not sure there's a big runtime overhead. The polyfilling generated by TypeScript is negligible and varies based on the target you set in your compiler configuration.


Introducing TS into your codebase is useful in two cases to me:

  • For a large project with many developers working on it.
  • For a small library, which has a nearly stable API.
code of conduct - report abuse