September 6, 2015

The JavaScript / TypeScript / CoffeScript / Dart choice 2015 (part 2 of 2)


Pages: 1 2

Evaluation

Based on this comparison, I’d like to present here the results of my personal evaluation for a JavaScript language implementation choice. Please note that I’m not a senior JavaScript developer, and I don’t have much experience with these languages. My opinion really mainly comes from reasoning about their features and the opinions of other users of the languages.

I encourage you to make your own evaluation and come to your own conclusions.

ECMAScript 5

Of course, ECMAScript 5 is just ECMAScript 5. It’s the fallback for whenever a more useful, efficient, concise, higher-level abstraction / language is not supported by the execution platform, which nowadays is the case for client-side programming on the browser for all the other languages discussed here.

But it’s no more than that. It is antiquated, tedious, sketchy and overall just a language you don’t want to work in anymore. Never use this language again, always use one of the higher-level alternatives presented here, and automatically transcompile if needed. This will ensure your code is expressive, concise, optimized and maintainable.

Of course, for very simple tasks such as small JavaScripts snippets within an HTML page, making some DOM manipulation with jQuery, it would be overkill to introduce another language for features you most likely don’t even need. This simplistic case is not addressed by this article.

Bottom line: No.

CoffeeScript

I’d like to start off the actual comparison with CoffeeScript. Of all the languages discussed here, CoffeeScript derives the most from original JavaScript. It also provides the most syntactic sugar and language enhancements of all these languages.

It does however hardly cover any high-level / static programming constructs such as enums or generics at all.

If you compare it with outdated ES5, it is clearly superior in almost every aspect. However, when comparing it with recent ES6, additions seem rather marginal; some things are even worse.

From what I understand, this situation arose partly due to the history of CoffeeScript itself: ES6 (luckily) took many concepts and constructs which were first introduced in CoffeeScript, and included it in its own syntax, overruling its original inspiration. Or as put by the decaffeinate npm module currently built to port CoffeeScript to ES6: “JavaScript is the future, in part thanks to CoffeeScript. Now that it has served its purpose, it's time to move on.”

Also, it apparently has the worst IDE support of all the 3rd party languages.

I wouldn’t recommend at this point, however, to force a switch from CoffeeScript to ES6 if you have a mature project and an experienced team working on it. CoffeeScript is not bad, much in the contrary.

On the other hand, I wouldn’t recommend starting a new CoffeeScript-based project now. I hate to say it, but its syntax and some of its concepts really are mereley interesting from an academic point of view now. It makes dramatic syntax changes when compared to traditional JavaScript, which are highly opinionated (and personally, I have to say, I actually like them). Still, now that we have a reasonable standard, we should go with it, for the sake of long term maintainability.

Bottom line: No.

Dart

When it comes to JavaScript similarity, Google’s Dart sits in between TypeScript and CoffeeScript (but very close to the TypeScript end).

As far as syntax and components are concerned, the language is pretty similar to TypeScript as well. One deviation for all other languages (which may be considered “major” by some developers) is the enforced semicolon at the end of a statement.

IDE support is good.

The biggest difference, however, lays under the hood: Much in contrast to TypeScript, Dart is technically not an extension, a superset, of ECMAScript, but a rewrite from scratch. This clearly diminishes interoperability and is a potential issue for migration paths. This is what Microsoft criticizes when they explain their commitment to the ECMAScript evolution: “Some examples, like Dart, portend that JavaScript has fundamental flaws and to support these scenarios requires a “clean break” from JavaScript in both syntax and runtime. We disagree with this point of view.”

When deciding between ECMAScript 6, Dart, and TypeScript, it’s this question of corporate politics which matters most in my opinion: Do you want to go for the “standard” way, or take the risk of a proprietary path with Google? For what I’ve seen so far, Dart doesn’t offer anything which in my opinion would be worth taking this risk.

Again, I would recommend here not to switch existing projects, but not to start new projects based on Dart, either. Sorry, Google.

Bottom line: No.

TypeScript

It seems that so far, Microsoft’s TypeScript is our best contestant to make the race. As mentioned earlier, TypeScript really delivers about the same ES5 addition as does Dart. But most importantly, TypeScript really shines when it comes to (as its name suggests) static typing.

Nowadays, TypeScript is trying hard to keep up with the features rolled out in new ECMAScript 6, but on top of that, it enables static typing and type enhancements, as they are known and loved by traditional high-level languages (and their developers) such as Java with concepts like Interfaces, Generics, and even Mixins. (Note that except for the strict static type checking part, these concepts are available in Dart as well.)

Most importantly, again, TypeScript is conceptually different from Dart (and CoffeeScript) in that it’s not written from scratch, but instead, based on original ECMAScript 6 proposals and with respect (and backwards-compatibility) to ECMAScript 5. This makes it a true ECMAScript 5 super-set and allows you to write any valid ES5 code within TypeScript. This really is a huge plus when it comes to standardization / long term maintainability considerations which should be a major part of any technology choice, let alone a swift ES5 migration path.

IDE support is apparently the best out of all the options. If you don’t like Visual Studio, there’s still an Eclipse plugin.

For the time being, you might consider TypeScript roughly equivalent to the new ECMAScript 6, but with static typing as a bonus. And I mean this quite literally: No major browser supports ES6 completely, so you might as well use TypeScript and transcompile everything to ES5. Then, at least, you get full IDE support (I’ll cover the ES6 side presenty).

Okay, let me round this up. I think the choice here primarily depends on the situation you are in:
  • If you’re client-side programming (browser), the choice is all yours, and it really depends whether you like (or need) static typing. Remember that it adds security at the expense of rapid development. If your team comes from a statically typed world like Java, you may try it. If however you’re used to a “soft fail” world like e.g. in AngularJS angular expressions, adding static typing may feel like and additional impediment.
  • On the server side, I think, the decision depends on the project size: For small projects (e.g. just a simple CRUD REST server, introducing static typing may be overkill or even counter-productive. If, however, you write huge parts of your core business logic in JavaScript, distributed in dozens of modules and classes, you should seriously consider adding that additional static safety net.
It’s absolutely mandatory that this is a team choice, and based on the team’s experience. Introducing static typing or not is a highly disputed topic, (and, by the way, so is TypeScript’s Scala-like static typing syntax), and this choice may be a deciding factor of which people, in the future, will be part of your team.

Bottom line: Depending on the situation, yes.

ECMAScript 6

ECMAScript is the future of JavaScript, and it will shape the future of the web. It’s that simple. When compared with ES5, it adds a myriad of syntactic elements and concepts, surpassing even the functionality of many well-established high-level programming languages such as Java. It also delivers several features out-of-the-box which up to now were covered by 3rd party JavaScript libraries only, most notably, module import / export and promises.

There’s that one well-known problem though. ES6 support by major browers is just not there yet. However, just as the 3rd party languages presented above rely on transcompilation to ES5, there are vanilla ES6-to-ES5 transpilers such as Babel and Traceur. You must thus put an additional automatic transcompilation step in your deployment pipeline to compile ES6 to ES5 until fully supported by your target browser / runtime (such as e.g. Node.js).

I have made my evaluation in the TypeScript section already, but to sum up:
  • Use TypeScript for big scale projects
  • Use ECMAScript 6 otherwise
Please, do also consider the lack of mature IDE support in your evaluation: Of all the major open source IDEs, only one Eclipse plugin currently seems to support ES6 whereas TypeScript’s IDE support is apparently very good.

Bottom line: Yes.

Conclusion

Within a few years, the JavaScript landscape has completely changed, and it really changed for the better. But with the new choices comes new responsibility.

I really believe in standards. And I believe that in terms of responsibility, one should stick with the standard unless it makes you miss great opportunities. Considering the excellent work put into ECMAScript 6, and how it clearly moves towards more progress in the near future, I do clearly consider this the way to go.

For certain situations, as explained above, TypeScript may also be an excellent option, but I would then really treat it as a separate, specialized language, and maybe even consider a mix of both dialects, with TypeScript in use for specialized cases only.

Other than that, I will concentrate my future studies of the JavaScript landscape focusing on the ECMAScript standard, keeping competitive dialects in mind, but without searching for dependency on them.

I really hope this overview post and my insights have helped other developers overwhelmed by the breadth of the JavaScript language landscape. Please let me know your thoughts, comments or critics in the comments section. I would also be highly interested in any experience of working with these new technologies in big-scale projects.


You may also be interested in

Pages: 1 2

No comments:

Post a Comment