My unpopular take on Typescript

So why not use Typescript you might ask? Great question. It looks a whole lot like an extended version of Javascript, so what is there to lose? A whole lot more than you'd expect, as it turns out.

My unpopular take on Typescript

In the last decade that I've been working with Javascript, I've used Typescript for a little over two years. After getting past the learning curve of types and interfaces, I really enjoyed it.

Those were the days when React was new, and the main AngularJS crowd was either moving to Angular 2 or switching over completely to React. I migrated to Angular, and wrote an cross-platform mobile application in Nativescript.

I wrote it all in Typescript, and was happy to- considering it was Angular's preferred language. At the time, I had no issues using Typescript, granted- I didn't use types or interfaces. Later, I worked at a tech company and developed core features for their Angular 2 app in Typescript.

So why not use Typescript you might ask? Great question. It looks a whole lot like an extended version of Javascript, so what is there to lose? A whole lot more than you'd expect, as it turns out. Let's use an analogy to paint a picture.

yomex-owo-bQF_9yrggvM-unsplash.jpg

Imagine two bicycles, one is Javascript, the other is Typescript. They're identical except for one thing. The Typescript bike can't drive on roads without some minor modification. So let's say it comes without tires, and you have to put them on yourself. Not too bad. You should only have to do this once.

Turns out the Typescript bike comes with some optional modifications. Nice! You get a "expansion kit" (actually two- the second kit is smaller but serves the same role) which you can use to install training wheels on the bike. Well that's pretty nice. It's optional to use, so should be fine.

Turns out it's not so optional. For whatever reason when teams start to use Typescript, code that used to be high quality isn't good enough anymore. If you're not specifying (non-any) types on every function, you're doing things wrong. Do solutions need to change because you have new tools, even if those tools don't add value for the end user?

Now imagine these bikes are in a race.

The Typescript bike rider ends up spending a whole lot of time fiddling with their expansion kit. Putting the training wheels on, taking them off. To no point other than making their own development experience "better".

The next developer who starts working on the project will almost have a different idea of what makes up a "better" work experience. Now we have training wheels on the back wheels, as well as the front.

Finally, A junior developer joins the project. They need to add extra data to an already defined interface, so they hack it in. Now the training wheels looks a lot like those shopping carts at the grocery store. The kind with one of four wheels busted and spinning in circles.

If features are available in a language, developers will often find a way to install them into a company's product. Even if it means for learning or experimental purposes.

So the Typescript bike rider was tinkering with their bike and feeling proud of their modifications. The Javascript bike rider was pedaling hard, and covering ground.

The Javascript rider might have fallen at one point on the course without the safety modifications, but they survived. That experience improved in their ability to pilot their vehicle in the process.

In the end, we have an improved rider on a leaner craft. Compare that to the modified bike that- at best, has issues changing direction (lack of agility). At worst, it has serious limitations on its max velocity from the improperly installed mods.

Okay, I do have some good things to say about Typescript. That's only fair.

Typescript makes sense for mature projects. Where the desire to keep the code bug free exceeds the desire to continue to innovate. Also for projects where "falling over" even once, poses too great a risk.

Migrating a project from Javascript to Typescript means it's greatest innovations are behind it. It's ready to settle down to a nice, peaceful pace of development with less surprises. Many projects have reached this point. There is a time to collect your chips and leave the table- if they didn't they might have gone bust.

I'll leave you with a final thought... When starting your new web project, ask yourself, what's your goal: to not fail, or to succeed?


Love it? Hate it? Either way, like and follow for more engaging content.