Programmers have debated type systems since the dawn of time, and maybe always will. When communicating with the machine, what level of information should we have to put into instruction for our digital friends? Do we have to be so explicit? Is it worth it? Can they just work it out for us? Can then even work it out better than we can?
This has cropped up on the JavaScript scene again with the rise of TypeScript. We keep hearing from engineers discussing what and why they are doing here, such as Slack’s usage in their desktop app, and Sir Tom Dale on how TypeScript is used in Glimmer (and how it is used differently to Angular 2 tools for example).
One of the key decision choices of TypeScript makes it a fantastic gateway drug. The first step to usage is mv foo.js foo.ts. Not only is this trivial, but it makes the process non-daunting, and you often get value as the compiler finds subtle bugs that you didn’t know you had.
When you get this value, you start to think things such as:
“An autocomplete system that only uses words in the current document feels barbaric afterward” — Felix Rieseberg
This is the heart of the trade off (sorry, balance) with TypeScript. When building large JavaScript systems many made the baby step to use doc comments to add @type info and more structure. This always seemed a sad hack. Rather than a first class solution we were resorting to hiding some extra goodness away from major parts of the system. Yes, we built special tools that would grok the comments, but man. It really didn’t feel right. If we feel the need to do types, can’t we put them more front and center?
In fact, is this the right balance, or are we failing to take a further step to a better place?
We are once again hiding valuable information from key parts of the system. The type erasure means that our runtime isn’t able to get the benefit of the information that we are conveying. This information could be gold when it comes to AOT compilation, especially important in the world of mobile. Will we keep pushing on from this next level of middle ground to take the next step with types? So many were burned by thinking that the experience of types == that hellish enterprise Java 1.1 codebase, but the grey beards have always been shaking their heads at us there. We have type inference and much sounder type systems abound now.
And then we have Web Assembly. Lin Clark did her usual magic talking though the performance implications. We are seeing increasing experiments with wasm as a compile target that allows the system to boot up predictably fast. Get going, and then improve from there. This can be huge, especially in a world where the time from user intent (a tap) to a running system converts to engagement and gold.
It is also interesting to compare the rise in TypeScript with the rise in Kotlin. In my mind, the window opened for Kotlin at a time where the type of source code you wrote for Android didn’t have some of the cool functionality that came to Java later. Similar to TypeScript though, it offered a really smooth learning curve. You can look at any Kotlin code and grok it really quickly, and you can start using it in your projects incrementally. That factor is so vital for adoption for these languages. You don’t have to wait for a new project, you can give it a try in many other ways. Once you dive deeper though, as with TypeScript, there are more advanced features, and you run into practical choices around making the system grok Kotlin even more, and creating extensions to access support library compat methods, or dealing with platform nullable types.
The allure of the incremental step is real. Is it an ideal end state, or will the masses go to a place where we push further? The good news is that there isn’t a shortage of experimentation, and the core platforms are getting better and better!
“We are programmed to receive. You can check-out any time you like, But you can never leave!”