Farewell CoffeeScript(github.com)
github.com
Farewell CoffeeScript
https://github.com/staltz/rxmarbles/commit/57e37f176e0e005abd2c4fa0253bbd8f57fe1bd9
20 comments
I really don't understand how coffeescript is cleaner or easier to understand. To me the syntax is much more confusing and ambiguous and takes more time to understand where things go... or just to hunt down the little comma responsible for delineating two arguments. When the code you're looking at is large and complex it's even worse. And just because we don't like typing "var" or using curly braces? That is seriously what we're calling bloat?
I was originally very intrigued by it, and used it heavily in one of my projects, but after working with it for a year I went back to JS for the next project. I still want something better than JS but coffeescript definitely isn't the answer.
I was originally very intrigued by it, and used it heavily in one of my projects, but after working with it for a year I went back to JS for the next project. I still want something better than JS but coffeescript definitely isn't the answer.
Because at the end of the day, each browser has its own set of JavaScript bugs. Now you spend time debugging your code and the code generated by the tool.
If I already need to be a JavaScript expert to make my code run properly across all target browsers, I don't see a value adding another layer to debug.
If I already need to be a JavaScript expert to make my code run properly across all target browsers, I don't see a value adding another layer to debug.
I'm interested to know what value TS/CS devs get from their code translating to "legible" JS?
I used TypeScript for a project earlier this year. As a C++/C# expert and a JavaScript noob, I found the clarity, the readability of my code to be far superior with TypeScript, well worth the extra tooling.
Then I found that after working that way for a number of months I no longer needed it. I picked up enough JavaScript along the way that I could I drop the training wheels and I am not looking back.
Then I found that after working that way for a number of months I no longer needed it. I picked up enough JavaScript along the way that I could I drop the training wheels and I am not looking back.
So this is a kind of teenage hubris thing ? In which other field this would be normal ?
I play the devil's advocate there, but please bear with me : IMHO, this attitude is among the causes of the high failure rates of many projects (personnal or pro).
The constraints are minor, the gains of coffeescript quite clear. There is no important gains in sight that justify moving to js. So why changing ?
Changing for the sake of change, is silly and something all of us do. A successful project needs as much technical stability as feature stability.
The constraints are minor, the gains of coffeescript quite clear. There is no important gains in sight that justify moving to js. So why changing ?
Changing for the sake of change, is silly and something all of us do. A successful project needs as much technical stability as feature stability.
the gains of coffeescript quite clear
As someone who has been writing JavaScript for 15 years and has never felt like writing it is a struggle I would ask... are they?
I don't know what it solves. Writing a language designed to be written by hand in another language and then transpiled to the first language you have to know in the first place to be any good at it has always seemed like a horrible non-solution. You don't know what you've actually written at that point.
As someone who has been writing JavaScript for 15 years and has never felt like writing it is a struggle I would ask... are they?
I don't know what it solves. Writing a language designed to be written by hand in another language and then transpiled to the first language you have to know in the first place to be any good at it has always seemed like a horrible non-solution. You don't know what you've actually written at that point.
I feel a lot of folks are not mentioning a huge thing CoffeeScript is valuable for - its list comprehensions and proper for-each. JS has them too as part of ES5 spec, but CS still is an elegant solution. It creates a whole new way to speak code, like in Ruby, Python and others.
Syntax, variable niceties are great too, of course, but do not define CS alone.
Syntax, variable niceties are great too, of course, but do not define CS alone.
[deleted]
For you, it has no advantage. You have integrated all js by now and you avoid the common mistakes instintively.
For me, it is the gray area, I am a language geek so the semantics of js are quite clear but js bytes me sometimes. In coffeescript, The syntax is better and the semantics are better exposed , so it may be a net win.
For a guy who is already familiar with coffeescript, the change will be likely negative. Familiarity with coffeescript is likely to generate bugs in javascript. You're moving from one language to another after all. The impact won't be huge as the two are quite close, but there is no reason to change in the first place.
For me, it is the gray area, I am a language geek so the semantics of js are quite clear but js bytes me sometimes. In coffeescript, The syntax is better and the semantics are better exposed , so it may be a net win.
For a guy who is already familiar with coffeescript, the change will be likely negative. Familiarity with coffeescript is likely to generate bugs in javascript. You're moving from one language to another after all. The impact won't be huge as the two are quite close, but there is no reason to change in the first place.
Can you give a few examples of common JS mistakes that coffeescipt prevents?
I'm not deep in either CS or JS, but I suppose one could find some pitfalls from the differences between == and ===, and from checking the existence of a variable?
Also, JS switch/case statements follow the good-old maldesign from C where each body has to end with break or it falls through.
Variable hoisting?
This: http://dorey.github.io/JavaScript-Equality-Table/
Also, JS switch/case statements follow the good-old maldesign from C where each body has to end with break or it falls through.
Variable hoisting?
This: http://dorey.github.io/JavaScript-Equality-Table/
It depends a lot on the context. Richard Stallman defines hacking as "playfully doing something difficult, whether useful or not". In the context of hacking, change for the sake of change is perfectly fine. You don't always have to move forward and get things done. Leave that for the corporate world where your goal is to make money. Many of us have learnt a lot just by switching programming languages many times and rewriting stuff. We're not losing time, we're learning in the process, and most importantly, we enjoy it, because that's what hacking is about.
For many projects of playful hacking, you want to reach a goal. If the goal is learning the language itself, it's allright and we are in agreement. But more often, you want to build an app, a toy and changing language midway is a shortcut to failure and disappointment.
>There is no important gains in sight that justify moving to js.
Getting rid of a dubious build step that doesn't get any real advantage in this project, but makes it slightly more obscure for people unfamiliar with CoffeeScript (and a lot of new developers don't bother to learn it now that ES6 is quite tolerable)?
Getting rid of a dubious build step that doesn't get any real advantage in this project, but makes it slightly more obscure for people unfamiliar with CoffeeScript (and a lot of new developers don't bother to learn it now that ES6 is quite tolerable)?
> this attitude is among the causes of the high failure rates of many projects
It's a battle of philosophies. I value efficiency and just getting things built, so I love CoffeeScript. It's a breeze to read and write. OP wants control and customization, more 'freedom.'
If I was working on a team with OP and he instituted this, I would quit on the spot.
It's a battle of philosophies. I value efficiency and just getting things built, so I love CoffeeScript. It's a breeze to read and write. OP wants control and customization, more 'freedom.'
If I was working on a team with OP and he instituted this, I would quit on the spot.
Ungrateful 4 year old, he'll back before supper. If Ruby raised you well, I know python is a bit of a sloppy father though its heart is in the right place and he brings home the bacon, you'll know it's not just about the 5% code reduction. It's about abstracting away the inconsistencies of the language, revealing its inner elegance and power. CoffeeScript is not a cloak to hide JavaScript, it's the suit that makes you see and respect its power.
I recently migrated a fairly large CoffeeScript project to JS, after using CS for more than three years. ES6 and ES7 addresses many of the pain points of JS right now. So my sugggestion would be to use an ES6/ES7 transpiler instead of CoffeeScript.
- JS produced by the CS compiler isn't that great, to be honest.
- Plain JS is easier to debug than CS, even though you have source maps.
- Source map chains don't always work. So using CoffeeScript together with another tool which produces its own source maps could be a problem.
- Build time could go down without CS
- Way more devs understand JS than CS
- I might have considered sticking with CoffeeScript if it had plans to evolve, perhaps add more functional features. But jashkenas considers CoffeeScript mostly done. As michaelficarra mentions in https://github.com/jashkenas/coffeescript/issues/3073, "CoffeeScript needs to evolve or die"
- When ES6 gets implemented, just get rid of the ES6/ES7 transpiler and you have plain JS
I haven't read the article, but if you ask me CoffeeScript is dying.
- JS produced by the CS compiler isn't that great, to be honest.
- Plain JS is easier to debug than CS, even though you have source maps.
- Source map chains don't always work. So using CoffeeScript together with another tool which produces its own source maps could be a problem.
- Build time could go down without CS
- Way more devs understand JS than CS
- I might have considered sticking with CoffeeScript if it had plans to evolve, perhaps add more functional features. But jashkenas considers CoffeeScript mostly done. As michaelficarra mentions in https://github.com/jashkenas/coffeescript/issues/3073, "CoffeeScript needs to evolve or die"
- When ES6 gets implemented, just get rid of the ES6/ES7 transpiler and you have plain JS
I haven't read the article, but if you ask me CoffeeScript is dying.
I wish there was a bit more to the explanation, like examples of the naming issues listed.
I've found that coffeescript prevents whole classes of bugs, and makes lots of javascript warts nicer to live with.
For example, you don't seem to run into scope issues, and it's a lot easier to bind this to what you expect.
5% more code (if it really amounts to that) is still more code, too! No code is like no code.
I've found that coffeescript prevents whole classes of bugs, and makes lots of javascript warts nicer to live with.
For example, you don't seem to run into scope issues, and it's a lot easier to bind this to what you expect.
5% more code (if it really amounts to that) is still more code, too! No code is like no code.
Look at the commit beneath the commit message.
From the README: "The architecture is a simple MVC heavily dependent on RxJS" and that's exactly how it looks, just linking different components together without hardly any glue code.
If all his code looks like this, he certainly doesn't need it to be in CoffeeScript.
From the README: "The architecture is a simple MVC heavily dependent on RxJS" and that's exactly how it looks, just linking different components together without hardly any glue code.
If all his code looks like this, he certainly doesn't need it to be in CoffeeScript.
[deleted]
I'm glad I don't have to deal anymore with people who irrationally cite such "articles" as argument fodder. They exist, in large numbers. But not on my team.
Without CoffeeScript, automated JavaScript linters are your friend. Run them in your editor, test suites, and asset pipelines. They'll catch those pesky "var" and "===" typos.
http://www.jshint.com/docs/
http://www.jshint.com/docs/
> They'll catch those pesky "var" ... typos.
So will "use strict";
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
So will "use strict";
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
But what if you're targeting the browser? Is the strict mode supported?
We just transitioned our code base to "use strict". If you use it in combination with a module system it works painlessly, and indeed prevents some classes of bugs.
Surely you can (and should) 'use strict' in browser.
[deleted](1)
ReSharper also has great support for JavaScript. ReSharper isn't just a refactoring tool - it also points out errors and other potential issues in your code and offers to help fix them.
I'm just waiting for ReSharper the Vim plugin!
I'm just waiting for ReSharper the Vim plugin!
Oh and if you're using VS, you could use TypeScript, which in my limited experience seems to make JavaScript better 'just enough'.
Linting CoffeeScript is a good idea, too (using coffeelint).
"Also, in the end of the
day, your generated JavaScript is just about 5% more verbose than
actual CoffeeScript code, so I don't see real benefit."
I disagree with this sentence.
Anyone use coffeescript only to reduce the code verbosity, maybe wrong.
It's a simple evolution of thejavascript language that currently has an old syntax. Do not confuse old syntax with popularity and power of the language itself.
Many programmers have figured out that readability and clarity code are a good stuff, especially looking forward if the project will become big and much complex.
It's why Swift or Rust were created, not why their code is less verbose of Objective-c or C, but because they have a clear syntax, and it helps programmers in their productivity.
I disagree with this sentence.
Anyone use coffeescript only to reduce the code verbosity, maybe wrong.
It's a simple evolution of thejavascript language that currently has an old syntax. Do not confuse old syntax with popularity and power of the language itself.
Many programmers have figured out that readability and clarity code are a good stuff, especially looking forward if the project will become big and much complex.
It's why Swift or Rust were created, not why their code is less verbose of Objective-c or C, but because they have a clear syntax, and it helps programmers in their productivity.
JavaScript is a wonderful place to sow your wild oats and create your own object-orientation schemes, its prototypal inheritance is wonderfully powerful and fun to play with.
However when you get to building non-trivial systems with javascript you need to pick a style and stick with it. In that regard you can do much worse than CoffeeScript.
However when you get to building non-trivial systems with javascript you need to pick a style and stick with it. In that regard you can do much worse than CoffeeScript.
If I could choose I would choose Ruby over Javascript ANY DAY (I am not saying that is better, just that sintax is easier to pick for an hobbyist as me).
But I can't. JS is everywhere and I don't have time to learn several programming languages.
CoffeeScript was a way to make JS more enjoyable to me. You can say that CoffeeScript is still another language to learn but once that is related to JS, you learn both simultaneously, killing two birds with one stone.
But I can't. JS is everywhere and I don't have time to learn several programming languages.
CoffeeScript was a way to make JS more enjoyable to me. You can say that CoffeeScript is still another language to learn but once that is related to JS, you learn both simultaneously, killing two birds with one stone.
Ever heard of Opal (http://opalrb.org/)?
I'm not quite sure what the point of this is. A scan of the diff doesn't reveal anything particularly interesting being done in Javascript that Coffeescript would get in the way of. It's fine to argue that Coffeescript gets in your way and prevents you from doing things that you couldn't do otherwise, but at least demonstrate examples to that effect.
Even more perplexingly, there are methods like `merge` in examples.coffee/js which, in the Javascript version, are effectively compiled Coffeescript, and which are less concise than they should be; why does the Javascript version call `Array.prototype.slice.call(arguments)` when arguments is never treated as an array outside of length and subscripting, both of which the arguments object already supports? Coffeescript does it specifically so that using arguments as an array is transparent to the user. Why is it necessary in the Javascript version, when the only effect is the creation of an additional object?
It's somewhat silly to argue for Javascript on the basis of it offering finer control over the code, and then not using that control. If you just don't like Coffeescript, fine, but let that be your argument.
Even more perplexingly, there are methods like `merge` in examples.coffee/js which, in the Javascript version, are effectively compiled Coffeescript, and which are less concise than they should be; why does the Javascript version call `Array.prototype.slice.call(arguments)` when arguments is never treated as an array outside of length and subscripting, both of which the arguments object already supports? Coffeescript does it specifically so that using arguments as an array is transparent to the user. Why is it necessary in the Javascript version, when the only effect is the creation of an additional object?
It's somewhat silly to argue for Javascript on the basis of it offering finer control over the code, and then not using that control. If you just don't like Coffeescript, fine, but let that be your argument.
Despite their share of problems (the author explained what's wrong with CoffeScript in his opinion), languages compiled to JS will keep flourishing unless some future ESx will turn it into a more conventional language. Even in that case, being the native language of the "internet virtual machine", people wanting to use a language-X-look-alike for the front end will keep designing their transpilers.
In my case I never considered CoffeScript because of the indentation/semantic spaces thing. I had to work with those languages sometimes and the troubles I had when moving blocks of code around and copy/pasting examples from the net have been enough to undo any gains from a cleaner syntax (assuming it is cleaner). No Python either here, obviously, nor HAML or SLIM for templating. Irony: they've been invented in the Ruby community which somewhat prides itself of using a language with a better syntax than Python (I second that, Python looks too much like a C with defs which is maybe the reason for its success: familiarity.)
In my case I never considered CoffeScript because of the indentation/semantic spaces thing. I had to work with those languages sometimes and the troubles I had when moving blocks of code around and copy/pasting examples from the net have been enough to undo any gains from a cleaner syntax (assuming it is cleaner). No Python either here, obviously, nor HAML or SLIM for templating. Irony: they've been invented in the Ruby community which somewhat prides itself of using a language with a better syntax than Python (I second that, Python looks too much like a C with defs which is maybe the reason for its success: familiarity.)
Whenever I see someone using significant whitespace as a downside of any language, I can't avoid thinking "man... I wouldn't like to see your code..."
My main gripe with significant white space is that it forces a specific level of formatting that is generally less attractive and readable then what I would otherwise use.
Please elaborate. Usually, significant whitespace only forces code at the same nesting level to have the same indentation, it doesn't specify what that indentation should be.
I dislike significant whitespaces because when there's a lot of code that has multiple nesting levels it becomes a bit hard to follow. I like it when my code has a beginning and and ending token ({ and } in JS/C/C++ or `begin` and `end` in Ruby). Whilst writing CS I found myself writing `# end` a lot.
Also, not to mention (maybe my editor lacks this feature) I like using ^M to jump from end to beginning braces of blocks, and I can't seem to do that in CS.
However, all of these arguments just boil down to "this is my personal preference"
Also, not to mention (maybe my editor lacks this feature) I like using ^M to jump from end to beginning braces of blocks, and I can't seem to do that in CS.
However, all of these arguments just boil down to "this is my personal preference"
My main gripe is that it makes moving code around painful and it introduces bugs that are difficult to spot. Literally.
I never got the point of all these alternative languages.
I rather use the real thing without any extra layers.
I rather use the real thing without any extra layers.
Same here, every now an then something 'new' pops up where creators claim that its better™ than what it compiles to and that it solves all the problems but after a while this 'new thing' fades away entirely.
But then again, that's the same way C (and many other languages) was invented (as far as I understand), to replace assembly, for example, and it's still alive and kickin'.
I guess there is a subtle difference in here somewhere.
But then again, that's the same way C (and many other languages) was invented (as far as I understand), to replace assembly, for example, and it's still alive and kickin'.
I guess there is a subtle difference in here somewhere.
So you do all your coding in assembly language? Respect!
I used to, kid.
Back when portability didn't matter to me and languages like Pascal and C only had compilers that produced blooty slow as molasses code.
The thing is, JavaScript is portable.
Back when portability didn't matter to me and languages like Pascal and C only had compilers that produced blooty slow as molasses code.
The thing is, JavaScript is portable.
And a steady hand... http://xkcd.com/378/
Coffeescript is just a short-hand for best practices javascript. It enhances readability and consciseness.
But nothing more. Bad (or neutral) practice is still possible in coffeescript. Mixing coffeescript and javascript files is easy. Classes can be defined any way you please (if you don't mind using something other than the "class" keyword).
I think the only reason for me to switch to something else from coffeescript is if some similar language where to get a nicer type system exactly right. I'm not holding my breath though.
But nothing more. Bad (or neutral) practice is still possible in coffeescript. Mixing coffeescript and javascript files is easy. Classes can be defined any way you please (if you don't mind using something other than the "class" keyword).
I think the only reason for me to switch to something else from coffeescript is if some similar language where to get a nicer type system exactly right. I'm not holding my breath though.
Purescript FTW! :)
Meh, he doesn't like Coffeescript, who cares? Why all the fanfares and huge deal? :-)
Programming language wars over languages that have significant differences are often silly, the whole coffeescript vs JS debate is just ludicrous.
That's crazy talk, next thing you'll be saying we don't need AngularJS to make web applications.
RX is awesome by the way.
The author makes some odd assumptions about CoffeeScript's intentions, ie language reduction and protecting against "evil code". All of this ignores the real main benefit, which is cleaner syntax, which means less finger typing and easier comprehension of a large and complex code base.
There was a time when JavaScript was the only real choice for browser-based web development. There were compilation tools like GWT, but they were heavyweight and generated the JavaScript equivalent of binary, completely detached from the source code. Now that the JavaScript++ languages are here (CoffeeScript, TypeScript) and well-supported in the browser thanks to source maps, I find it hard to imagine why people continue using raw JavaScript with all the bloated keywords, curly braces, etc (apart from legacy code bases). Usually it's because they haven't used anything else, and are content to focus on the negative of Coffee etc and stick to what they already know.