Software often requires two or three iterations before you get it right. In our case this led to starting a rewrite of our hybrid mobile application. It had been developed over several years by a diverse group of people with varying coding practices, and it was deemed easier to rewrite it than to refactor it into a maintainable state.
Nowadays there are a multitude of language alternatives for JavaScript development. These range from simple syntax enhancements to full-blown language alternatives. After a bit of searching, we decided to evaluate three JavaScript alternatives for our rewrite: CoffeeScript, TypeScript and Dart.
Below is the results of our comparison between the three. This is not an extensive functional evaluation (a luxury not available for startups), but instead based primarily on reading the following books:
- The Little Book on CoffeeScript, by Alex MacCaw
- TypeScript Revealed, by Dan Maharry
- Dart: Up and Running, by Kathy Walrath & Seth Ladd
I can recommend these as good introductions to each language, as each one can be read in a few hours. You may also be interested in Anton Ivanov’s blog post comparing the three with code examples.
CoffeeScript – a fresh coat of paint
CoffeeScript is one of the oldest altJS languages and probably the most popular one (see update at the end). The slogan of the language is “It’s just JavaScript”. It is essentially an alternative syntax for writing JavaScript, and compiles one-to-one into equivalent JavaScript.
The goal of CoffeeScript is to expose the good parts of JavaScript and clean out the bad. For example, one thing that bites many inexperienced JavaScript developers is the type coercion when using ==. CoffeeScript removes this complexity by always converting == into ===. There is no possibility of accidentally using type coercion, you have convert types explicitly.
The syntax takes a large step away from JavaScript, most notably by the -> operator and using indention scoping. People with a background in C/Java-like languages may find this disturbing at first, Python coders will find it natural. While the -> lambda operator may take some getting used to, it reduces a lot of boilerplate code related to nested function definitions, common in event-driven languages:
$(document).ready ->
$.get '/', (data) ->
$('body').append "Successfully got the page."
The language has many other influences from scripting languages like Python, Perl and Ruby, such as post-conditionals, operator aliases and string interpolation to name a few. It heavily promotes brevity of code, with the risk of it becoming cryptic to non-experts.
CoffeeScript also provides a framework for classes and inheritance. One of the greatest pitfalls of JavaScript is having too many ways of doing things, and class definitions is one of the worst. CoffeeScript’s class framework allows working with classes in a consistent and easy manner.
Since CoffeeScript compiles directly into corresponding JavaScript, any external libraries can be used without any problems.
Overall, CoffeeScript provides a new syntax for JavaScript, promoting brevity and hiding many of the ugly bits of JavaScript. It is also one of the most common altJS languages, so documentation and support should not be hard to find.
Nonetheless, as a direct language conversion it cannot fix all of JavaScript’s faults. The syntax may appear rather geeky, excess cleverness using the syntax may backfire, and it can take some getting used to for people coming from Java-like languages.
Update: After using CoffeeScript for six months, I’ve written a post on CoffeeScript woes, which highlights some pitfalls we’ve run into.
TypeScript – the JavaScript of tomorrow
TypeScript is Microsoft’s take on altJS. It implements proposals of future ECMAScript standards today, allowing the compiled code to run on existing JavaScript interpreters.
The primary new language features provided are (optional) static typing and a class framework. The type system allows catching a wide variety of problems during compile time, instead of runtime. The class and module framework allows easier modularization and writing of complex applications.
Microsoft has also developed comprehensive IDE support for TypeScript for Visual Studio. The static typing allows it to perform many advanced refactoring operations, such as global renaming, reference searching and code completion, enough to make any scripting language developer envious.
TypeScript is the only one of the three that is a strict superset of JavaScript. This means that any valid JavaScript code is also valid TypeScript, and compatibility with existing libraries is a no-brainer. Also, if the proposals to ECMAScript 6 are accepted, your code will be valid (or almost valid) ECMAScript 6 code when it comes out.
This compatibility, however, is also the crux. As a superset, TypeScript cannot hide any of JavaScript’s ugly sides. All of the pitfalls of JavaScript are there lurking, waiting for you to step in. The static typing and Visual Studio plugin do a lot to alleviate the problems, though.
TypeScript is essentially a look at what JavaScript may be in a few year’s time. The addition of a type system, classes and modules, and an IDE that takes full use of these features makes it a tempting option to plain JavaScript.
Dart – a fresh look at the web
Dart is Google’s proposal for the future of the web. Dart takes the separation from JavaScript even further, and is a whole new language, designed from the ground up. It’s what JavaScript might look like if it were designed today.
The Dart language is not specifically designed for a browser, but more as a general usage language. Browser-specific functions, such as DOM manipulation, don’t rely on magic global variables, but are provided as libraries. The language resembles Java in many ways, and most programmers should be comfortable with it in a a day or two.
The fact that Dart compiles into JavaScript is about the only link between the two languages. In fact, the long-term goal is to have browsers natively implement Dart support – a version of Chromium with a Dart VM already exists.
While a clear distinction from JavaScript allows creating a sleek, modern language, it does come with a cost. Utilizing existing JavaScript code and libraries is more difficult, you need to access them through an interoperability library. You’re also further away from the code the browser sees. If there’s a problem on some obscure browser, it may be difficult to track it down and fix. Experienced JavaScript developers might also feel frustrated with the added layer between them and the browser.
Which one to choose?
So, which one is the best? As always, that depends.
If we were using Microsoft tools for development, TypeScript would be a very tempting choice. As it is, we’re doing the majority of our development on Linux and Macs using Eclipse. A major part of the benefit of TypeScript comes from the tooling within Visual Studio. As support is developed for more IDEs this may change – for example WebStorm 6 from JetBrain already includes TypeScript support.
If I was starting a new desktop web app, I would definitely consider Dart. It’s a very clean, modern language with extensive libraries out-of-the-box. However, our application must also run on rather old mobile browsers, and interface properly with our native code. If we later find out that Dart code doesn’t run properly or fast enough on some devices, we may be at a dead end. This is a risk we didn’t want to take.
For these reasons we ended up using CoffeeScript. While I don’t think it’s an ideal language, it does clean up a lot of JavaScript’s mistakes, reduces unnecessary code and provides structure to the code. Since it is close to regular JavaScript, we can be sure it won’t cause interoperability or performance issues.
An added benefit is that CoffeeScript is probably the most widely adopted altJS language, and there’s a considerable amount of manuals and explanations for it, and more developers in the community to answer questions. Without any clear numbers, Google Trends provides some idea on the relative interest in each language.
Update 2: This trend has changed during 2015, with TypeScript clearly overtaking CoffeeScript in search popularity.
In short, CoffeeScript was a safe choice that is nonetheless considerably better than plain JavaScript.
Which language have you chosen for your projects?
Code for Hire 
Checkout IcedCoffeeScript. Now that we’ve got sourcemaps (and Webstorm) If you’re going to go CoffeeScript you might as well got Iced
I quickly checked Iced a while back. We’re already using promises for all asynchronous control, and I think those provide a bit more flexibility than await/defer, though not necessarily quite as simple syntax. Still worth a look for everyone considering CoffeeScript.
webstorm doesn’t support IcedCoffeeScript
There’s also LiveScript http://livescript.net/ which is kind of a-little-bit-better CoffeeScript. — The problem with LiveScript is, I think, that all IDEs and toolkits focus on supporting CoffeeScript; no one cares about LIveScript because it’s a fairly new language, and while LiveScript is better than CoffeeScript, it doesn’t offer *that* many improvements (I think). — I’m using LiveScript by the way, but I’m thinking about porting to Dart, some years into the future.
Here’s the trend graph with LiveScript included:
http://www.google.com/trends/explore#cat=0-5-31&q=coffeescript%2C%20typescript%2C%20dart%2C%20LiveScript&date=1%2F2010%2048m&cmpt=q
LiveScript is amazing, yet there’s no types and it’s not supported well by major editors
Coming from a Python background, I’ve been very happy with RapydScript (https://github.com/atsepkov/RapydScript).
My primary language is python, so Coffeescript is godsend to me as an alternative to js.
However, I see it as a temporary solution to the real problem: JavaScript.
JavaScript is a messy language, and the internet platform deserves a much better language to keep growing and improving.
Dart is unexciting and boring syntax wise, but it’s a good project and I wish it luck. Besides, we can always create a CoffeeScript for Dart 😉
An unexciting and boring syntax might not be appealing to coding gurus, but may be easier to scale to 100s of developers when you’re forced to hire mediocre talents as well.
You can also check out:
– Script# (https://github.com/nikhilk/scriptsharp)
and
– ClojureScript (https://github.com/clojure/clojurescript)
First is an excellent practical option for .Net developers (There are multiple successful projects using it). It does not require learning new language because it is mostly good-old c# 2.0. Btw it is mature, actively developed and has nice integration with popular JS libraries.
Second is mostly for Clojure fans. Strong side is that it is LISP! And the weak side is that there is rather bid difference between original code and generated JS.
VS IDE is not by any means the only, or even always the best way to develop with Typescript: Typescript support in Jetbrains’ Webstorm is excellent using nodejs Typescript plugin, pretty much matching VS IDE without pulling in a lot of IIS/C# crap into your projects. It’s also available for MAc, Linux and Windows:
Pingback: CoffeeScript woes | Code for Hire
Web programming sucks.
I was very excited about Dart in my first two days of learning,but now It feels like it is an
1. Ornitorrinco ,a very strange animal that tries to introduce OOP for the browser programming ,but only if you want to be a serious programmer,.
2. But Thre are two thing in Dart that make me really sad
3. 1-In Dart everything is an object,even primitives,so You have to pass everything by reference,this not only makes the things very verbose(you have to create an object named StringBuffer in order to get its value property and then assign to a new variable,thats madness)
4. see this video http://www.youtube.com/watch?v=DWtvhdJkiRE
And last but the most weird thing, Ithink Dart is the only language in our galaxy that does not have an operand ,in order to concatanate strings,they say this way the VM can infer that only numeric fileds are use with +,So why not using another operator like LUA does ?
Phyton and Coffescript base their flow in identation,so I didnt even take than seriously,There are many phyton programmers who types //Enddo as a comment in order to mimic something “that other languages have” and to make sure they can rearrange the program if “something goes wrong with the file”.
Programming for anything that has to run in a Browser is very verbose ,because You have to find the component you want like this (from Sencha Forum)
Ext.ComponentQuery.query(CQselector)
Ext.getCmp(componentID)
Why all “modern languages and frameworks” make me do it by myself,In Intraweb(a Library that generates code based in what you write in object Pascal,a kind of layer of abstraction) I didn t even know that the Dom existed,if The component was created all Ihad to do is write code like:
lblAddress.color:=clred;
instead of Ext.getCmp(‘lblAddress’).color:=clred;
It´s been 10 days since I started learning Dart.
First,If someone says that every .NET and Java developer can get dart in 2 days they´re telling no more than lies.
I think that if someone knows Java,Javascript and RIA Applications than it would be easier to master DART.
The fact that DART was note made with a Class centric privacy model,makes it harder to someone like me that came from Object Pascal World.
Especially concepts borrowed for Javascript like closures,I never needed a closure in my hole life.
The code style borrowed from Python also bothers me,It seems like magic,something I´ll have to get used to.
For me DART is really an ornitorrico,not because its uglier than a Completely OOP based language,but also because their creators have adapted it to the environment they want DART to live .
I Really miss my protected,overload,override and all this stuff,but I´m at the very beggining,maybe in some days I will be eating my words.
Closures are extremely useful in event-driven languages / environments like JavaScript and web programming. You can just write code that continues where you left of when you called an asynchronous method with a callback. Such callbacks are made simpler and less verbose by shorthand notations such as -> in CoffeeScript.
I also recommend looking into promises, which essentially provide a try/catch/finally framework for asynchronous programming. (Dart seems to have Future for similar functionality.)
Ok,I´m not very used to assyncronous programming ,so I´ll give closures and promisses a chance.
thank you
I´m also getting used to some concepts of DART,like passing everything by reference,although I really have to write more ,I realized that the vas majority of times I don´t change what I used to pass by value,and sometimes It can even increase readibility.
The market is getting a wrong idea about Dart.
I really have a feel that the market has a wrong idea about DART.
DART is not a Javascript replacement, it is the Darwinian law in the Programming languages area, It is the thing that will made RIA and Saas to have the same maintainability that we always had in traditional client server applications.
It will not only replace JavaScript, but will enter in areas that were mainly dominated by Java and .NET, with the difference that this application will scale in a way that Cloud Computing will jump from the books into reality.
I myself was getting it wrong, because even books have misconceptions about the way DART was designed, DART was not designed with having to deal with JavaScript limitations, its based in many languages like Smalltalk,Strongtalk, Erlang, C#,and of course some JavaScript.
I think is a big lie from google that someone with experience in Java,C#,Delphi will get DART in two days, it does not work this way.
You probably have that feeling of “Why did they do it this way instead of doing it like C#”, but in the end you´ll see that you can do everything but having the advantage of having the power of RIA and Saas applications, architectures that not only appeal for the eyes of end users but are also easy to maintain and deploy.
Unfortunately not everything are flowers, although Dart has wonderful tools like the Dart Editor, it does not have a complete EcoSystem,it does not have a Jquery, EXTjS and so on, not now, but I think in at most one year the Polymer project will be ready and we´´ll be able to do this kind of applications but without Bugs and laziness.
Resuming,It think Dart is not the language of yesterday and today,It is the language of the next 30 years.
Choosing a technology because you want that some older browser run your application is just the evil itself.
That’s the unfortunate reality. A few years back we were all cursing IE6, now it’s IE9 / WP7 and Android 2.3…
I don’t understand why you didn’t choose Typescript: it is a pure super-set of javascript, so you can refactor your original code peu à peu, depending on your monthly workload; no need for big refactoring. There is a nice IDE Webstorm / Intellij that support it on linux and iOS. The article is good, but doesn’t explain why you did this choice!
We had already decided to do a complete rewrite of the code (which, in hindsight, was the correct course of action). So we didn’t have any legacy code we’d need to support.
When we made the decision, TypeScript support for other than Visual Studio was very new and the language itself had been public only a bit over half a year. We also liked some of the syntactic styles of CoffeeScript (especially the -> operator, which can greatly reduce boilerplate code and enhance readability).
TypeScript would probably have been a fine choice as well, perchance even better. But CoffeeScript seemed a safer option at the time, and we’ve been quite happy with it.
Thanks for this report. I quickly looked at those, and finally my conclusion is that it is almost harmless to use typescript. So it should be the right choice IMHO.
Isn’t one of the big advantages to dart the runtime speed. My understanding that because of the type restrictions built into the language – along with the non-mutable classes, the compiled code can remove a ton of the low level data checks that javascript normally needs.
Your Google trends graph ends at 2013. Graph for last year tells a different story http://www.google.com/trends/explore#cat=0-5-31&q=coffeescript%2C%20typescript%2C%20dart&date=today%2012-m&cmpt=q&tz=Etc%2FGMT-3
That’s very true. I added an update noting this change in trends.
Checkout Transcrypt: Python 3.5 syntax, multiple inheritance, lean and fast code, multilevel sourcemaps http://www.transcrypt.org
Functional programmers who like their types static and strong (but often inferred) and leading to correctness, you might want to take a look at [Elm](http://elm-lang.org/), [PureScript](http://www.purescript.org/) or [Haste](http://haste-lang.org/). (The first two are Haskell dialects; the third is Haskell itself). Elm emphasizes Functional Reactive Programming. PureScript is an eager-evaluation dialect with some JavaScript semantics and extensible records; the library shows some of those differences. Haste accepts anything GHC will compile, except for templates (for now). I know from experience that PureScript and Haste have good tooling support (at least for us Vim/Emacs coders). Both have concise FFIs.
Pingback: Coffeescript vs — Алкогольные напитки
хостинг картинок для сайта – хостинг картинок анимированный gif, хостинг картинок jpg