12 Aug 2017

This is why TypeScript is worth looking into

It may seem strange to introduce "more compilation errors" as an advantage. But in recent years, JavaScript is increasingly used for the development of large applications and libraries - the language that was adapted to write small scripts on a handful of lines is beginning to seriously grow out of their shoes in dealing with issues like modularity, complex dependencies, and thousands or hundreds of thousands of lines of code. In such a situation, it is good to have early errors in compilation than to break things while driving.

Imagine JavaScript is a pen. You're not so excited about it, but it can at least put ink on paper so you can do your job. TypeScript is when someone says to you "Here, use this pen instead: it does the same things as your old pen, but it helps you write correctly and also gives you some handy tips on what works and what needs to be fixed".

TypeScript is a better version of JavaScript?
In the end, you will be able to submit higher quality work, as TypeScript has already found a lot of mistakes along the way that you do not need to run the program to detect. And you can work faster, more efficiently, and with greater confidence that things get right.

One thing I've realized on the road is that there's not much about "errors found during compilation" like "errors found while writing the code." Modern development environments like Visual Studio and WebStorm have excellent support for finding errors and giving tips about one's code while writing. People who come from the major static languages ​​are already familiar with this, and it is usually felt like TypeScript restores the order a little after missing IntelliSense in regular JavaScript.

In StackOverflow's survey 2016, TypeScript came one in response to the question "Which technology would you prefer to use?". It is remarkable for a language to climb to first place in just a few years. It shows little that there is a real need for TypeScript; that you see the value.

Okay, but what's the chin? Why do not all TypeScript use? Are there any disadvantages?
Anders Hejlsberg (Creator of TypeScript) got that issue in a podcast once. His response was "TypeScript is a value proposition that is not rational to say no to". You can type the same JavaScript code as you did before, but you get early warnings about things that can go wrong or will go wrong, or just be risky or problematic in any way.

In reality, a decision like "switch to TypeScript" is always taken in a context. You have existing JavaScript code, external dependencies, etc. Even in such a situation, there are good opportunities to consider TypeScript. For example, an existing project can choose to migrate source file for source file; TypeScript is smooth enough to manage a code base with a mix of JavaScript and TypeScript code. You also choose to use different configuration flags how strictly you want TypeScript to be with one's code. There, one can balance between stricter / better type controls on the one hand, and easier migration on the other hand.

I've heard that using Flow instead. Is it true?
Flow is an interesting option with about the same selling points as TypeScript. (Flow is developed by Facebook and TypeScript by Microsoft. Both are open source.) However, it is quite clear that TypeScript has "won" in the sense that it has a large community and lots of support from all directions. A little like the situation with Git and Mercurial; The latter is a good alternative, but it has a significantly smaller market share.

You have done a course for people who want to know more about TypeScript?
Yes! In this course you can clearly see how JavaScript has grown, and how to combine the best of TypeScript, modern tools, test-driven development, and modern development methods to build non-trivial software for the browser and for Node.js.

More posts

  • Now we launch Comma

     Now we are launching the beta version of Comma, an IDE for Perl 6 developers that will streamline their work.  

    Read more
  • Our view of Vue

    Are React and Angular still the only two responsible choices when selecting a JavaScript framework for the new project, or can Vue now be considered an actual contender also from a business perspective?

    Read more
  • Configuring CMake for success

    One common question I get on our Advanced C++ course is how the project structure should look, e.g. should I split the source code into multiple directories? How can I introduce unit tests? Should I compile into multiple libraries?

    Each project is unique in what it needs, so in this blog post I’ll go over my general preferred setup and then look at how we adopted it for C++ on Android where we also interface with Kotlin/Java.

    Read more
  • Working Remotely… Very Remotely

    Does your job let you travel? Do you want it to? Our job does! And we're taking advantage of it!  Read all about our plans for remote work... very remote work.  #waaayoutofoffice

    Read more
  • Focus on Business Value with Scrum

    How do we, as a company, keep our focus on Business Value, when we our teams are dominated by technical people and developers, who are not always even expected to see the bigger picture. How can Scrum be at help?

    Read more