Thoughts About Pre-Compiled Javascript Languages

At an internal discussion in Tikal's Javascript Group, I asked for an opinion about developing javascript with a precompiled javascript language such as - typescript, coffeescript, etc.

One of the go-to reasons for going with such a solution (typescript) is the fact that it enforces such classical class-based-language conventions and syntactic sugar as well as it feels natural. 

In my personal opinion, compiled to javascript languages are still - not in common use - and is hard to find developers with experience in it. Debugging such source languages (aside from few) as still not straight forward. Some pre compiled languages don't support any standard and aim to imitate some other non-async languages.

Still - javascript, the language - is the defacto nowadays and most common language talked over the web despite few attempts to make some wrappers around it. Also, as Douglas Crockford stated before - there's a reason for javascript taking over the web than java - it's lightweight ans easy to follow. If I would have to choose a pre compiled language - I would have go with the Traceur Compiler - which supports compiling standard ECMAscript 6 code - the future of javascript - to today's javascript.

Here are some of the pros and cons some of our engineers have had in mind regarding developing with such precompiled javascript languages.

Dart

pros

"If customer want a strongly typed language with JS fallback best choice the Dart (dartlang.org)"

Coffeescript

pros

"I can speak in the favor of CoffeeScript. Basically, it's not that different than coding in JS. I see it more as a personal preference, and not as a tool that promotes the generation of higher quality code. That statement can go either way. CS doesn't makes you treat your code as class-based object oriented code any more than JS, however, it does have a cleaner syntax with no boilerplate to define prototypal inheritance, if you choose to use it. One of the nicer features of the language IMHO, is the functional-query styled expressions it allows you to use. These mostly revolve around list comprehensions and object destructuring. Using these features is not that different than using a lot of underscore's utility functions in regular JS, and maintaining your code in a functional fashion, but it's certainly easier to use write, read and remember. I still find myself combining underscore functions with CS "native" expressions to deal with complex data processing. I think that the main draw point towards CS for me, is that it requires a lot less "mental syntax parsing" in comparison to JS. I don't have to watch out where I might missed a comma, parentheses, or curly braces, and my code is structured as its idented. Basically, for me it leads to a lot less pitfalls which I tend to come across no matter how many times I saw them before with JS, and my code is just written more fluently. The language does have some annoying pitfalls which may lead to frustration, like any other language that is new for you as a programmer. One that I've come across recently - 1. obj = {} obj.selection = item for item in collection when item? 2. obj = selection: item for item in collection when item? 3. obj = selection: item for item in collection when item? The first two produce a similar object, with 'selection' being just one of the items. The third's 'selection' is an array with all the possible matches. I couldn't make any sense of it. I guess that my final thought on this is- don't commit to CS unless most of your team mates won't enjoy it."

cons

"I had some experience a while ago when I spent about 3 month at one of Tikal's clients. The team that I have joined wrote it's client side UI with coffee script. It took me a short while to get adjusted. I guess my main setback was getting to know all the dark corners and common pitfalls coffee script has: Just to mark two examples: 1. Each method in coffee script always returns a value so the programmer should return null if no value is expected 2. Coffee script relays on correct spacing, you miss a space and the code doesn't compile Other than that it was quite natural. I haven't had any experience in developing a web-application using coffee script with an MVC framework. I'm currently developing using Ember.js and finding good sample is hard as it is, finding the same range of samples in coffee script may be a mush harder task. To sum up: * Using a pre-compiled language may look nicer but it requires an overhead of compiling * Debugging may become more complicated * Developers should abide with the chosen tool which may make them less productive at the beginning * Finding decent samples may be harder and sometimes throwing a sample javascript code into an automatic translator won't cut it."

GWT

pros

"I am not sure if you (or the client) did consider GWT. GWT is mature enough, and you have good examples on the web. The main advantage of GWT today is the strong typing, and the ability to develop with Java and use eclipse. finding java programer is not that hard.. i want to add some warnning: GWT is a technology that consider to be in risk, but for now it is a live (see here http://gwtcreate.com/). i think that in long run if and when DART will take place it will kill GWT. From what i know is that DART has new approch of optional type, which doesn't enforce you to use types. if GWT it is somthing that you consider i can elaborate more."

cons

"Several points that I can shade light on: * GWT "swallows" up any routing your server may receive so IT IS IMPOSSIBLE to use normal MVC based routing * Due the lack of routing support (at least with Ember) we must define, configure and maintain any MVC relationships we need for our Ember application * Debugging GWT requires at least one full time Java developer with GWT experience * GWT has the tendency to mess up other frameworks DOM timing sequence making it very difficult to tame any MVC framework that gets in the way."

Typescript

pros

"we have been using TypeScript internal in the .Net group and also using it on a personal project. none of the problems you mentioned exists in typescript. in any point at the project you can 'transfer' yourself back to JS or even mix the two. the syntax is VERY EASY to catch and the compiler is just a cool breeze to work with (but we do use Visual Studio and not the node.js extension) it works well with require.js modules and all the rest is just pure JS but with type safe and lambdas all around (many other features)"

Plain Javascript

pros

"I wouldn't touch GWT with a 2 meter stick! In the last year and a half I have seen 3 projects written in GWT that their owners were desperate to get rid of but couldn't because it meant re-writing thousands of lines. From my experience with CoffeeScript the indentation issues are a NIGHTMARE. Other issues that Dror mentioned are also unpleasant (weird loop definitions, unexpected value returns and so on) - not my cup of coffee (lame, i know...). Perhaps typescript is the solution (Never used it...) though I don't really agree that Javascript should be treated as a classical class based language - After all its naturally a lambda language and should be treated as such."

"Personally, I strongly favor javascript. I think you still need to know the ins and outs of javascript even if you use one of the other languages. I also think that there is something to be said for think in javascript and not in some foreign paradigm. Bottom line, if I'm going to invest the time in learning something new I'd rather focus on something where I fell that I'll get more bang for buck."

"A lot of cool features and syntax sugar is supposed to be coming out with ES6 support such as classes, modules, arrow functions and more which will kinda take the sting out of compiled languages such a as CS.

An interesting talk by (the) Brendan Eich earlier this year (@ Fluent 2013):http://www.youtube.com/watch?v=qrf9ONmtXbM
Some features are already supported by leading browsers : http://kangax.github.io/es5-compat-table/es6/ - I hope this table gets "geener" soon"

"stick with javascript because:
1. javascript isn't so bad at all.
2. i don't like the generated code.
3. i don't trust MS/Jeremy Ashkenas to keep up with the industry. 
4. i don't like the additional effort required for build/testing/debugging."

Thank you for your interest!

We will contact you as soon as possible.

Send us a message

Oops, something went wrong
Please try again or contact us by email at info@tikalk.com