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?
— TypeScript (@typescriptlang) April 12, 2017
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
increasingly dislike the term/philosophy of “trade-offs”. don’t pick between things, find the right balance. pic.twitter.com/JT0gK5nfDq
— Luke Wroblewski (@lukew) March 9, 2017
In fact, is this the right balance, or are we failing to take a further step to a better place?
I honestly don't understand the draw to #TypeScript. Once you decide you no longer want to write JS, why stop at TS? 1/
— Phred (@fearphage) April 12, 2017
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!”