Thoughts on TypeScript Development

I’ve been developing Ionic 2+ apps for a little over a year now. With the change to Ionic 2 was the introduction of Angular 2, a complete re-write of Angular.js. The language pretty much requires you use TypeScript to transpile down to JavaScript, unless you want to spend hours repeating yourself writing awful code.

TypeScript is awesome — absolutely love it. Object-oriented programming has always been one of the biggest flaws of JavaScript in my opinion. Though it is very possible to do, it definitely doesn’t feel like it was a primary goal, more of an afterthought… Even though the entire language is object-oriented. It’s kind of like building a road and being like “Here’s a boat”.

TypeScript fills that hole by giving you a truck. It’s not quite as nice as a sports car, but it gets the job done, even if it is carrying a couple tonnes of baggage.

Upsides

Proper Classes

Having real classes makes JavaScript a far more formidable ally. It gives you the feeling of Java along with the flexibility of JavaScript.

It also makes your code a lot more readable. Rather than prototypes, you can actually declare public, protected, private and static members. Inheritance becomes more like a real thing with abstract classes, interfaces, extending and implementing classes.

It’s really quite an overhaul in the way you code, and I think for the better.

Static Types

Obviously the main point of TypeScript is types. This is super freaking awesomely USEFUL. For me, this makes things like function headers, classes and option constructors (those ones where you use a POJO as the constructor’s parameters) much more readable and easier to use. You can’t accidentally forget what type of variable goes where. It only accepts what you tell it to accept.

What makes TypeScript types better than most languages’ is that you can define your own inline. Want an array of people?

people : Array<{name:string, age:number}>;

Awesome, right? But there are also some incredibly useful features such as forcing a value to be one of a few options.

If you’re lazy or don’t like static typing, you can always use the any keyword to just accept any type, as JavaScript would.

It tells you you’re wrong

TypeScript transpilers actually tell you where you’ve made mistakes. Sometimes it’s a little bit annoying, but for the most part it’s a feature I use all the time. It tells you when you have unused variables, incompatible types, invalid values, unreachable code and no returns. It feels more professional than relying on a browser terminal to tell you when things go wrong.

Future JS

TypeScript nicely takes future JS features like Promises, Await and Observable and some array functions and can transpile down in a way that it will work anywhere, which is absolutely awesome.

 

Downsides

There are some downsides to TypeScript development — some of which are partly JavaScript’s fault — that manage to get on my nerves every day or two.

All modules are modules, but node modules are more equal than others

The first problem is modules. Modules work super well in node. Just require(‘express’) and you’re set. A large problem I keep running into is finding modules that don’t actually work in the browser. Though some readmes explicitly write “THIS IS A NODE MODULE”, some neglect to inform you of this. So you npm install an amazing looking module, and what do you know? There’s a dependency that requires node.js. Bugger.

I think the fault of this is require was initially designed only for node.js, and has been creeping up in webpack projects, because it makes dependency management so much easier.

It would have been nice to see TypeScript move away from npm (or at least branch it) to provide a package manager a little bit more focused on TypeScript rather than Node.

Typings

Why oh why do I need typings for every module I download? Maybe one in every 10 popular modules have typings, and it’s almost never up to date or complete. I don’t see why TypeScript can’t just read the js module and quickly build typings for it automatically.

It is still possible to use the module without actually having typings, but it just makes it so much easier when your code editor gives you suggestions as you go, rather than facing that github project’s empty wiki page.

Development Bloat

This doesn’t really affect production much, but in development there is definitely bloat. In addition to a package.json, your src and dist directory, you now need some way of transpiling the code (which takes for bloody ever sometimes by the way), a tsconfig file, typings and many headaches because some things don’t always work.

I think it would be awesome to see a TypeScript interpreter that doesn’t first transpile to JavaScript, even if just for testing during development. It would save hours of waiting for all my 200+ .ts files to compile, just because I changed one line.

It’s not my code

As with all transpiled languages, you have less control over your final code. This can actually be a good thing sometimes, because it forces you to not be so focused on making your code as performance-enhanced as possible (I’ve heard of people not using indentation because it takes longer to process), and instead make it more readable and actually work. I’m mostly alright with it, but there are times that I want to be more in control.

 

Conclusion

TypeScript development is a major paradigm shift from typical JS, and it’s a welcome one. I’ll continue to use TypeScript until JS catches up, and then maybe some. I strongly recommend anyone interested in web development look into it, and anyone who hates web technologies might find it a bit easier to get into than plain old JavaScript.

Copyright © Matthew Evans 2017