Given that the majority of the Discourse client code is already in CoffeeScript, if the core developers have a personal preference for it I don’t see a compelling reason to change course. It’s not as though you’ll be stuck if CoffeeScript suddenly “falls out of style” or something.
Is it really fair to call it a hybrid platform when those are libraries we are using and haven’t written ourselves? Isn’t that like saying our server side is a hybrid of Ruby/C because gems we use have FFI?
When I wrote the original prototype of Discourse I used CoffeeScript because it’s less code and provides protection against basic mistakes. Since then I’ve seen how EmberJS uses jshint to avoid the common mistakes CoffeeScript prevents and the advantages became mostly aesthetic.
I would be happy to compile all our CS to JS and replace it with that if we can find a compelling reason that isn’t a personal preference as you say, Sam.
Do we have any evidence that CS is preventing contributions? Any evidence that it hurts productivity or performance?
True. The discussion, however, is pivoting around a choice between the two and I think it’s focusing on adoption moving forward, not necessarily what would happen if CoffeeScript exploded (which I think I suggested and derailed the point).
The bottom line is this: CoffeeScript requires a compile step and additional understanding. People find it worth it to take those steps because JS syntax isn’t pretty and CS helps you avoid problems. Rails takes care of the compile step - but now you’ve introduced another dependency (understanding the Asset Pipeline) and while it’s safe to say that “well if you use Rails you should understand at least that” is absolutely true - you’re still piling up the list of dependencies.
The more machinery you put between people and patched/contributions the harder it will be to gain contributions… to me that’s just human nature :).
Whereas with something like Wordpress it’s Notepad >> RUN.
Frankly I think the choice of Ember is the biggest problem you have in terms of contributions. But that’s another thread.
Haha, as someone who has done WP customization before this is a troll but I do understand your bigger point about a barrier of entry. Here’s a serious question though: is requiring them to pass jshint any less of a barrier of entry?
I’m familiar with JS but not CoffeeScript or Ember. I don’t feel encumbered by CoffeeScript after looking at a few docs that explain the basic syntax differences. Ember is more of an undertaking, I haven’t yet grokked how everything at Discourse is put together.
CoffeeScript jeopardizes the ability to stay up-to-date with the web platform. Parts of CoffeeScript require new syntax that is incompatible with features coming in ES6 and ES7. By using CoffeeScript, you are locking yourself into always using ES5. One of the principles of TC39, 1JS, means that if you author ES4 code today, it will guarantee to continue working in the future, and be easy to upgrade when new features start landing in browsers.
I think this is the biggest issue with using Coffeescript. It is a quite different language, and while it is much nicer to write CS, it is unreadable to anyone who hasn’t used it before.
As I said, it’s trivial to fork->decompile and work from there, or even to use the two in conjunction. The biggest issue with going in between CS and JS is that current (de)compilers don’t transfer comments. If they did, you could work on the main source, in Coffee, with no issues whatsoever, as it would transparently convert to and from JS.
As far as I understand it, the idea behind CoffeeScript is exactly to have some higher level language that just compiles to “some standard” JS. And if somehow CoffeeScript was abandoned and no one could update the compiler anymore, you still could just compile your CoffeeScript one last time and use the compiled JS in the future.
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.