Like most organizations building client-side web applications (SPAs), here at Oasis Digital we have most commonly written code in plain old JavaScript, i.e. ES5, with help from linters, unit tests, etc. Lots and lots of code is out there, written in ES5 plus AngularJS and other frameworks.
There are obvious weaknesses to this approach, or rather gains that are set aside by not embracing any of the numerous newer innovations. We have dallied with CoffeeScript, worked on minor projects with ClojureScript, and so on. There are a lot of great languages out there beyond the JavaScript, but statistically JavaScript/ES5 is the winner.
(For a bit of “inside baseball”: we at Oasis Digital are generally quite willing to use unpopular, better tools. So why ES5? Because of our secondary line of business, training. When trying to train someone to use a new JavaScript library or framework, the most likely common ground we will have with them is baseline ES5.)
However, the era of mostly writing JavaScript code as it will execute in the browser is ending rapidly. Innovation of the JavaScript language is running far ahead of what browser vendors will keep up with; and even to the extent browser vendors keep up, large projects will inevitably have to support today’s browser versions (with the JavaScript version embedded therein) for years to come. A build process with compilation to JavaScript will be part of most SPA projects in the future.
So the question is, which post-JavaScript language to pick up? My personal favorite is ClojureScript, though I also see much merit in type-inference-equipped functional languages like Elm. For mass use though, I suspect the answer is simply a JavaScript successor. This is where it gets tricky. ES2015 (wow, I miss the shorter “ES6”) is the standard, and it will eventually land in all the major browsers. It will “win” in terms of mass adoption. Today is a good day to start moving your server side (NodeJS) code, test code, and as much as possible all of your JavaScript development to ES2015 or even a bit beyond – we’ve already done so. Babel works very well. Traceur works very well.
But there is at least one major exception. Angular 2.0 (which is coming soon, who knows how soon?) is built in TypeScript. You can go look right now, the source code in progress is sitting there in GitHub, and it consists mostly of TypeScript files. Most of the examples out there (including those we have published) use TypeScript. It will certainly be possible to write Angular 2 applications using plain JavaScript or any other language that compiles to JavaScript, but the first class citizen will be TypeScript.
Therefore, if you are using Angular today, and want to upgrade to Angular 2 someday, start learning TypeScript. Start using TypeScript. Start using TypeScript in some of your AngularJS 1.x work (we do).
Even aside from the obvious Angular motivation above, type systems in general (and TypeScript in particular) can be very useful. They enable a much more helpful editing/IDE experience. Numerous bugs can be caught at compile time. The incidence of runtime errors tends to be much lower. Unit testing can carry less of the load when using a typed language, so that whatever amount of effort you devote to unit testing, a greater share of it can go toward important functionality versus more trivial tests.
Here are resources to get started.
- The TypeScript home page
- DefinitelyTyped, which adds type annotations to highly numerous JavaScript libraries.
- This older blog post, about TypeScript with Angular 1.x, it predates TypeScript 1.5.
- Another older blog post, also predates TS 1.5.
- A TypeScript Gradle plugin, which generally works (for simple cases).
We will follow up later with examples of moving Angular 1.x code to TypeScript; we might even add a class offering to teach TypeScript for AngularJS developers. Stay tuned.
2 thoughts on “Learn TypeScript Now, Prepare for Angular 2.0”
Comments are closed.