Source
r/javascript•
doubleo7

Javascript vs CoffeeScript vs Dart vs Traceur?

I'll be starting a new large web project at work soon. I'm currently trying to decide what language to use but am a bit overwhelmed by all of the options. I have a lot of Java and Python experience and moderate amount with Javascript. Not really a fan of Javascript as a language so am researching the alternatives. (probably going with AngularJS as the front-end framework and either Python or Nodejs for the REST/JSON backend)

Current impressions:

  • CoffeeScript : Includes many of my favorite features from Python. The syntax seems a bit unintuitive but maybe it's not bad after you get used to it. Not sure if the overall benefits CoffeScript will be worth the extra hassle?

  • Dart : Sounds cool enough. Honestly I'd probably be happy to use either Coffee or Dart. Not sure which one will "win" in the long run, though, and am afraid to bet on the wrong one...

  • Traceur : "Traceur is a JavaScript.next-to-JavaScript-of-today compiler that allows you to use features from the future today."

Traceur seems like it might be the best choice because it would presumably make Javascript more tolerable and I wouldn't have to gamble on the unknown future of "yet another" language. Haven't really seen any buzz about it, though, which seems kind of strange.

If anyone has experience with one or more of these options I'd love to hear about it! Thanks

Posted Oct 19, 2012, 10:36 PM UTC

459
remcoder•

Stick with plain old Javascript until you understand it's problems.

30
homoiconic(raganwald)•

This^ time 1,000. Tools are either vitamins or aspirins. Vitamins are nice, but aspirins solve headaches. Until you know what kinds of headaches you'll have, all we can do is recommend Zinc and Vitamin D.

Besides, even if you were leaning towards my current choice (CoffeeScript), I'd ask you to think very carefully before deciding that the beginning of a new, large web project is the right time to take on a new language and new tooling and find yourself asking "Backbone or Ember.js or...?"

Better to try a new language on a small project, where if worst came to worst, you could lock yourself in your office over the long weekend and port everything back to JavaScript. You'd still have all your domain knowledge and you wouldn't be fucked.

3
doubleo7OP•

For what it's worth, I've written almost 10,000 lines of Javascript. Not a ton but enough to know that I'd rather not do another 10k of it if I can avoid it. :-)

I agree with your point about trying it on a smaller project first. I'll see if that's a possibility.

6
Gefrierbrand•

TypeScript is rather new, but it's adds features to JS instead of re implementing a total new language. I would check out that.

4
visarga•

I've always disliked JavaScript vanilla, but recently I kind of fell for jQuery event driven programming and nice DOM search operators. It is smooth. Otherwise, I use Perl, which is also very smooth in its own way.

1
doubleo7OP•

Funny you mention that. JQuery is probably the main reason I got back into javascript. I did a smattering of javascript years and years ago and hated it. JQuery has made it soooo much better!

1
[deleted]•

Could you explain to me how jQuery helped you write event-driven code? I'm genuinely curious, because I know it's possible with vanilla as well. Also, I've seen a whole lot of cases where jQuery encouraged novice javascripters to write bad code, and I'd be interested in seeing the opposite.

1
homoiconic(raganwald)•

I've written almost 10,000 lines of Javascript. Not a ton but enough to know that I'd rather not do another 10k of it if I can avoid it.

In that case, it would be really helpful if you could tell us why you personally would rather not write another 10,000 JS/LOC. Then it would be easier for us to recommend the right analgesic :-)

1
RobertWHurst•

Mind if we see some of your code then?

1
[deleted]•

[deleted]

-2
Gefrierbrand•

Agree. At the end everything compiles to JS and you need a solid understanding of Javascript before you should move on to a different language. Personally after getting over the flaws of the language I started to like JS a lot.

2
dazonic•

Personally, I learnt more about JavaScript, and loved it, only after I switched to coffeescript.

4
JL235•

I've met plenty of PHP programmers who have the same mentality. They have only coded in PHP, and see no point in ever trying Ruby, Python, JavaScript, Java, C#, Haskell, whatever; because they feel "I can do it in PHP, so why switch?".

Nothing wrong with PHP, but there is something wrong with a closed mind.

2
remcoder•

True, but I didn't say that. In fact when you're comfortable enough with javascript it makes sense to go for something like Coffeescript or Typescript. But only then! The difficulty with languages that compile (or 'transpile' if you will) to javascript is that they add an extra layer of abstraction. In the long run that will be helpful but at times you will need to understand the code at the, say, Coffeescript level and simultaneously at the javascript level. The languages you mention don't have this caveat.

So I'm not argueing against coding in languages on top of js but I'm saying you better know js very well.

0
JL235•

True, but I didn't say that.

You more or less did, and your point certainly wasn't related to the complexity brought by additional layers of abstraction.

In fact when you're comfortable enough with javascript it makes sense to go for something like Coffeescript or Typescript.

Again, I disagree. Why go with something that is as close to JS as possible? just like JS? You won't learn anything, you'll just have a new tool to play with. Again it's the closed mind mentality, where if you have a hammer, everything looks like a nail.

I'd recommend just trying lots of languages, learn what makes them different, and different at solving problems. Even if you stick with JS, it'll help you approach problems from a different perspective.

Those other languages don't all have to be JS-like ones; plenty of stuff compiles to JS these days.

-3
remcoder•

I'm sorry, I guess I was under the assumption that the OP was debating what JS-like language to pick. Now I see he didn't make that explicit buit it certainly looked that way to me :-)

3
[deleted]•

[deleted]

1
averyv•

You more or less did, and your point certainly wasn't related to the complexity brought by additional layers of abstraction.

this is why I hate talking to people on the internet. we are in a javascript forum, on a javascript thread, talking about the differences in different javascript related languages. how in the fuck could you have possibly thought he meant what you thought he meant? Beyond that, once you made the initial mistake, how in the fuck could you possibly come back here and try to defend yourself in your misunderstanding? Just accept that you made a mistake and move on.

Why go with something that is as close to JS as possible? just like JS? You won't learn anything, you'll just have a new tool to play with.

like the man said, stick with plain old javascript until you understand its problems.

and, let's face it, using anything else is just asking for trouble if you are planning on deploying to the wild.

your idealism is heartening, but incredibly misplaced, and your attitude just plain stinks.

1
[deleted]•

[deleted]

1
robotfarts•

And just hope your code works in all browsers? or use js with something like jquery?

-6
[deleted]•

If you don't know how to write vanilla javascript that works in every browser then you really shouldn't be looking at libraries like jQuery yet.

1
filterspam•

That's kind of the point of jQuery so you don't need to care about the differences. Why stop there? Maybe you should be able to code up a JavaScript vm in every OS before you write any js code or maybe you need to be able to write all of the different OS's before you start writing applications or vms for them at all or learn how to start with a pile of sand and build a CPU...

1
[deleted]•

I didn't mean be able to write a complete polyfill for addEventListener, I meant knowing what does and doesn't work cross-browser, so that you don't end up doing something stupid like posting to StackOverflow asking "how can I use jQuery to find the text in a textarea?"

1
robotfarts•

That's the most idiotic bullshit I've heard in a long time. I doubt anyone can do that, unless it's for a small subset of Javascript, like Javascript that doesn't involve the DOM.

-1
[deleted]•

[deleted]

1
[deleted]•

[deleted]

12
runvnc•

I really like CoffeeScript and feel that it has advantages over the other options.

First of all, someone mentioned TypeScript. If you are writing your system in Visual Studio then you should definitely try it out and compare it to CoffeeScript. Otherwise, I see no point in adding types, because you aren't going to get the Intellisense without Visual Studio, and its just going to be more typing and less readable.

Not having to look at types makes JavaScript more readable and straightforward than languages with types. The types are mostly a distraction from the actual problem at hand.

I think CoffeeScript is a no-brainer. For one thing, no one tolerates inconsistent indentation in their source. So using the significant whitespace doesn't require you to code differently. It just means less typing and fewer curly braces etc. to look at.

So you get class, extends and super. As simple as that can be.

As far as the syntax of CoffeeScript, at first I was a bit turned off by @ and -> / => and thought it was making things more complicated, but once I realized that @ just means this. and -> / => means function, it wasn't confusing at all. You just have to get used to looking at arrows and at signs. Once you look at it for a few days, its just as easy or easier to read the -> instead of the word 'function' all over the place. Actually that stuff makes the code a whole lot more readable/writable, because all of times you don't have to read/write function() { }) or whatever adds up. Also, using two spaces instead of 4 really helps.

The syntax of CoffeeScript is NOT a hassle. Its much more convenient actually. Also, as far as compiling CoffeeScript, you can just make a run.sh bash script which does something like coffee -c *.coffee before starting up your Node program or whatever (for the client-side code).

So with CoffeeScript I don't ever have to worry about whether 'this' is really the instance of the class whose method I'm in or some random thing like window. All I do is define my methods with =>

When you can always just write for object in thearray instead of for (var i=0; i<thearray.length; i++) { or use the for key,val of object, that starts to add up. Similarly with other types of control flow, like if/else, switch.

There are some things that I am not sure I like, such as putting the if/else at the end of the line, or using unless. So I usually just don't use those.

Not having to write parenthesis or return all of the time adds up. Being able to define objects like YAML without extra commas or {} adds up.

Splats make it easier to implement decorators. The 'in' keyword is useful for checking if an object is in an array. 'And', 'is', 'or' are easier to read. The syntax for embedding data in strings is nice ("e.g. #{somedata}.")

The 'do' keyword is very convenient in for loops that have callback code in them.

The scoping in CoffeeScript is a big improvement over JavaScript. Some people don't like it just because its different. But it definitely is an improvement.

All of this stuff adds up. I think CoffeeScript is literally the best programming language as far as utility (since you can use it in any web browser on any platform or also on the server with Node.js) and also as far as usability/readability.

7
robotfarts•

Otherwise, I see no point in adding types, because you aren't going to get the Intellisense without Visual Studio, and its just going to be more typing and less readable.

I would use something with types because the type safety it grants you, not because of Intellisense, but you can't sell soap to a pig.

4
x-skeww•

Not having to look at types makes JavaScript more readable and straightforward than languages with types. The types are mostly a distraction from the actual problem at hand.

Just putting types at the API boundaries (parameters and return values) is enough to give you most of the benefits. You don't have to put them everywhere.

2
JL235•

TypeScript doesn't really work like that, since if it's not typed, it becomes any, and so is freely allowed to cross any API boundary without checks. Only very direct code fails.

The reality is that you do have to add types to everything.

1
x-skeww•

It works fine in Dart and I don't see why that wouldn't work fine in TS, too.

2
JL235•

Have you tried?

I've been programming in typescript for the last few weeks since its been out, and this is actually one of my biggest annoyances.

2
doubleo7OP•

Thanks very much for your detailed response. You helped convince me to take deeper look at CoffeeScript. I'm still concerned about its readability but it does appear to have a lot of very cool stuff.

Even seemingly small features like string interpolation and triple-quote-block-strings can make a huge difference for everyday tasks like constructing dynamic HTML, etc.

I really wish CoffeeScript didn't have optional parenthesis and commas, though. Seems to make it significantly harder to correctly parse and comprehend complex statements. Hopefully some of that can be avoided by enforcing a few style guidelines.

2
runvnc•

Awesome, glad I could help. I think the trick to giving it a chance is just to take the time to try it out. Up until I had actually used it for a few days or maybe a week or two, I really didn't like the @ and -> .. now I really much prefer the -> over 'function' in terms of readability.

Probably the same thing goes with Dart.. if you don't try them both out seriously you won't be able to judge.

Anyway here are a few examples from my github of the type of code I prefer with CoffeeScript

https://github.com/ithkuil/remember/blob/master/public/trial.coffee

https://github.com/ithkuil/mcchunkloader/blob/master/public/scripts/nbt.coffee

2
expose•

If you're pre-compiling coffeescript in node you're likely doing it wrong. CoffeeScript should already register a require.extensions on the .coffee ext to automatically compile those files in node: http://coffeescript.org/documentation/docs/coffee-script.html#section-6

-1
runvnc•

I know you don't have to precompile it for Node.

I am using that for the client-side code.

3
robotfarts•

Coffeescript seemed the number one choice for node users at desertjs.org. I'd want to try out Dart, too, since it has static typing, which might help you avoid those last minute errors where you do something like accidentally modify something to pass in/receive an array/scalar instead of the opposite.

5
[deleted]•

Additionally, isn't the plan to eventually have native browser support? That would mean that, instead of disappearing in the future, it could get a whole lot faster.

1
metamatic•

Yes. There are already Chromium builds with native Dart support.

2
dazonic•

CoffeeScript has the biggest community backing, loads of resources out there. I was worried about debugging when I first heard about it, it's a total non-issue, you just console.log event just like you would in JS. At the end of the day with CoffeeScript it's just JavaScript. Dive in.

4
Jack9•

CoffeeScript Javascript has the biggest community backing, loads of resources out there

ftfy

-4
x-skeww•

Dart is my favorite. The much better tooling makes it very easy to use. It also doesn't contain any of JS' bad parts or things which are similar to those. Block scope is also very nice to have. There aren't any radically new features, but that's okay. This way, everyone can learn it very quickly.

CoffeeScript isn't very good from my point of view. The syntax has a lot more quirks than JavaScript. There is that strange shadowing issue. And it doesn't help with scaling at all. The trade-off just doesn't look very appealing to me.

Traceur and (untyped) TypeScript are very reasonable approaches when they are used for backward compatibility. E.g. back when Java 1.5+ introduced a bunch of new language features, someone created Retroweaver which allowed you to use all of that on 1.4 VMs. That was really cool. However, things are a bit uncertain if these features aren't actually standardized yet and if they aren't even available in any browser. Some of those things might change.

TypeScript is somewhat disappointing. It doesn't support let, so you still got that silly function scope going on, and the neat IDE stuff only exists for Windows (Visual Studio). I'm also not a fan of AS3-like type annotations.

2
JL235•

E.g. back when Java 1.5+ introduced a bunch of new language features, someone created Retroweaver which allowed you to use all of that on 1.4 VMs.

I thought the whole point of the Java 5 features, is that they were added at compile time, and so didn't need any JVM specific features.

Why couldn't you have just used '-target 1.4' when compiling?

1
x-skeww•

Why couldn't you have just used '-target 1.4' when compiling?

Because that didn't work if you used any of the new features. Would have been nice if it would have worked that way though.

1
JL235•

All of those features work on java 4, because they are handled at compile time. I.e. there is no generics, the compiler just uses Object + casts.

Which of the java 5 features are not handled at compile time?

1
x-skeww•

Read the source if you want to know everything about it:

https://retroweaver.svn.sourceforge.net/svnroot/retroweaver/

Also, there is Google. There are about 21k pages which mention RetroWeaver.

Seriously, -target 1.4 did not the trick. Feel free to try it with a 1.4 VM.

1
spankalee•

Dart : Sounds cool enough. Honestly I'd probably be happy to use either Coffee or Dart. Not sure which one will "win" in the long run, though, and am afraid to bet on the wrong one...

I wouldn't worry about which one "wins". The world of web development is so large that there will be many winners. My prediction is that plain JS, Dart, TypeScript, CoffeeScript will all be around with active communities.

To me, Dart fixes the most problems, has the nicest syntax, with the least amount of surprises, and looks like it'll have a great core library, so I'm going with that.

1
[deleted]•

[deleted]

1