Hmm, I may have to backtrack on my original opinion after giving this more consideration.
While I have been able to figure out how things work without too much issue despite not having a deep familiarity with either CoffeeScript or Ember, the combination does introduce a level of friction that makes me far more cautious when making changes.
The pretext in the responses seem to be that enough hypothetical proficient Ember.js devs are going to be dissuaded from contributing to Discourse at such a substantial rate that it’s worth getting rid of Coffeescript.
And that it ostensibly outweighs the benefits that non-hypothetical, real-life Discourse contributors experience while maintaining a Coffeescript codebase, particularly that of the core dev team.
So instant no. It makes it a pain in the butt to parse. It’s annoying. Most people (except for Python developers) don’t like it. Due to being difficult to parse, you will have problems when you try to refactor. Not to mention the problems of re-indenting everything when you have really long and ugly blocks you want to clean up (happens).
In contrast, how would CoffeeScript target the new for/of loops, when they already have for/of loops of their own? Sure, they could add new syntax, but it would be massively confusing for for/of to target the old semantics, and some other syntax to target ES6 for/of.
Similarly, CoffeeScript classes and super have subtly different semantics than ES6 classes and super. If CoffeeScript started targeting the new semantics, they would break existing code. If they required a different keyword to target ES6 class, it would, again, be very confusing.
It may be a bit difficult to wrap your mind around the difference, but I assure you, it’s true.
And as for personal preference: I won’t write CoffeeScript (for free). So there is some evidence right there, @eviltrout! :-p
p.s. CoffeeScript reminds me of VB. And nobody likes VB.
Aside from the points that have already been discussed, I’ve noticed that writing Ember apps in CoffeeScript also just feels a little off. Several of the niceties of Ember, like computed properties, are expressed as extensions on the JS Function prototype:
In addition to that, there’s the CoffeeScript class vs Ember extend() stuff, CS iteration vs Ember enumerables, etc. I just think there’s enough of an impedance between using CS and using Ember to make it more appealing to just use pure JS with Ember.
I guess, but less of a hybrid, if every single time I debugged Ruby I had to run GDB and constantly found myself reading C source I think it would be closer. If every time I wrote I line of Ruby I had to construct a mental model of the way MRI is going to translate the thing to C (for example because I need to know its going to wrap up my switch statements in a closure or what have you), we would be a more of a hybrid system.
Well, we have seen almost no contributions from the community wrt refactoring our js and we are a HUGE js app. In contrast we have seen massive amounts of refactoring around the Ruby side of things. Impossible for me to pin this on CS as I have no crystal ball, but it is a fact.
On a personal level I would be happy to never use CS again, I feel my hands are tied in weird ways and it encourages me to write stuff that I probably would never have written in the first place (like 4 levels of nested functions)
I prefer CoffeeScript, personally, its the only language I write in that I don’t think about the language.
However, Discourse is going to (hopefully) be around for a very long time. There are so many things that are going to be difficult for CoffeeScript in the future. For example, default arguments. null in CoffeeScript will defer to the default while in ES6 it will not because null !== undefined. I can’t see how it will target ES6 successfully and keep backwards compat.
I prefer jS since it’s better to write in JS since the it will take a bit of time for another contributor to convert the current “Getting Started Guide” or “Tutorial” from Ember and another lib written in JS to coffeescript.
Second, significant indentation is not actually hard to parse. On the contrary, it’s very simple - I refer you back to the above article. Essentially, the parser simply parses the difference in indentation as and tokens, modifying the level accordingly. While this might be slightly more difficult to parse than bracket-based blocks, it is hardly a “pain in the butt” to parse.
There are several things significant indentation does make harder:
Parsing with regexes. Which you should never do in the first place.
Mixing tabs and spaces. Which you should never do in the first place.
This is completely subjective (and I suspect it’s probably not true).
… which is much easier than balancing brackets, because it’s obvious at a glance. You already have to reindent when you write code in a bracket language. Now you just don’t have to balance the brackets.
I disagree that indentation-sensitivity is not a type of whitespace-sensitivity, but even if that applies to Python it does not apply to CoffeeScript. CoffeeScript is more whitespace-sensitive than Python. Compare:
jQuery ($) -> bar
jQuery($) -> bar
It also doesn’t enforce consistent indentation in the same way as Python, allowing for silly cases like this:
Instead of causing a compile error, the mis-aligned -> alters how the indentation of subsequent lines is interpreted.
I followed the CoffeeScript project on GitHub for a while, and my impression is that there are tons of edge cases in the compiler whose behaviour is poorly defined, varies between versions and may be difficult to replicate without a direct port. Part of the goal of the CoffeeScript 2.0 project was to define the grammar more rigorously, but I don’t know the status of that project.
I concur with this if for no other reason than I use OTBS and the indentation is far more important to me than the closing brace. The closing brace is at best a handy visual aid to ensure I’m at the end of the intended logic branch, but only because braces are required.
On the flip side, braces allow me to use inline stubs for things like encapsulating API methods or throwing exceptions where code has not yet been implemented.
Does it come down to taste? I guess that ultimately it does, however I find that after working with coffeescript for so long writing, pure js just feels incredibly annoying, slow and unwieldy.
It certainly seems like I’m in the minority, however I don’t find that to be unusual when talking about coffeescript!