Is it better for Discourse to use JavaScript or CoffeeScript?


(Dan Neumann) #6
  • Rails has an asset pipeline so there’s no build step penalty since it already exists.
  • I doubt the people that are (1) drawn to contributing to Discourse and (2) proficient enough to make substantial, nontrivial ember/js contributions are going to be encumbered by coffeescript.
  • If coffeescript was to go extinct tomorrow, you’d just delete the .coffee source and move on with the javascript it compiled to with a skip and a hop.

Coffeescript probably filters out the creaky religious-war people, though. :v:


(Robconery) #7

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.


(Robin Ward) #8

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?


(Robconery) #9

LOL you know what I mean :slight_smile: didn’t mean to troll :). There are concepts you need to understand sure but getting it to run is quite small.

I don’t think so (JShint). To me, you’ll likely find some great UX people out there who know their JS and want to help. The main questions here are:

Do they know Ember?
Do they use CoffeeScript (and/or like it)

Frankly I don’t know the odds here but I’ll guess not many will know Ember but even more important (to me) is how many are willing to learn it, and your code?.

Of those… how many embrace and love CoffeeScript?

So many questions!


(Alexander) #10

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.


(Tom) #11

Two points in favor of JavaScript:

Every CoffeeScript developer knows JavaScript. The inverse is not true. Because CoffeeScript emits JavaScript, and any debugging you do in the browser is in JavaScript, by definition CoffeeScript developers must have at least a passing familiarity with JavaScript.

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.

Edit: ES5, not ES4.
:blush:


(Sebastienstettler) #12

i agree with @tomdale 's second post

i believe ember.js is a good choice, in terms of having a sleeker code base, yes you have to learn the framework but that shouldn’t be an issue


(Benaiah Mischenko) #13

I am a devout CoffeeScript user, but I think the official client should probably be maintained in Javascript. Anyone can write and distribute another fully-functional front-end, or even do a fork of the current one and decompile the JS to CS.

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.


(Chris S.) #14

TypeScript!

Tumbleweed

It’s still Javascript, but sadly the compiler is Windows only and a bit VS centric.


(Simon) #15

I don’t understand the problem here. Which parts of CoffeeScript require “new syntax” in JavaScript? Isn’t the problem exactly the same if you were using “plain” JavaScript, that at some point in time, if some breaking change occurs in some future version of JavaScript, you would have to change your code? And who says that the CoffeeScript compiler couldn’t be updated to emit proper ES6/ES7/whatever code in the future, just like any compiler (C/C++/Java/…) is able to produce binaries for different platforms or is able to use different language versions.

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.


(Tim Stone) #16

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.

I imagine that if the codebase was purely JavaScript, which I’m confident with, I’d be able to focus more easily on understanding the Ember side of things without worrying that I missed some CoffeScript shenaniganery that might not produce exactly the behaviour I was after.


(Dan Neumann) #17

While we’re deep in bikeshedding zone,

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.

:bike: :house:


(J.A.) #18

CoffeeScript has significant whitespace.

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).

Stick with JS. More people are experienced with JavaScript afterall and critical mass in attracting developers is important for Discourse.


(Yehuda Katz) #19

Actually, this problem could not occur in JavaScript, because ES6+ will always be backwards compatible with the current version of JavaScript. Further, the “1JS” principle means that you will be able to take existing code and opt into new features simply by using the new syntax (there will be no “use es6” pragma or version switch).

The core difference is that ES6 is, by definition and by requirement, a strict superset of current JavaScript. By definition, there can be no new syntax that is incompatible with existing JavaScript.

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.

You could imagine an incompatible CoffeeScript 2 that targeted ES6 syntax, but existing CoffeeScript code would not work. Again, this cannot happen in future versions of JavaScript, because new JavaScript features are required not to break existing JavaScript code.

It may be a bit difficult to wrap your mind around the difference, but I assure you, it’s true.


(David Murdoch) #20

JavaScript all the way. There are way more JavaScript developers than CoffeeScript developers (and more JavaScript devs than Rails devs, I assume). I think you’ll get more contribution by opting keep the codebase in JavaScript.

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.


(David Stone) #21

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:

MyApp.president = Ember.Object.create({
    fullName: function() {
      return this.get('firstName') + ' ' + this.get('lastName');
    }.property('firstName', 'lastName')
  });

This requires you to use parens in CoffeeScript, which kind of defeats the purpose of the significant whitespace:

MyApp.president = Ember.Object.create
    fullName: (->
     @get('firstName') + ' ' + @get('lastName')
    ).property('firstName', 'lastName')

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.


(Sam Saffron) #22

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)


(Robin Ward) #23

It seems like the people have spoken.

I’m convinced! I am on board to convert the coffee to regular JS, assuming of course we set up jshint as part of our testing system.


Why coffescript?
JavaScript type safety is hard, and "I'm not smart enough to handle them"
(Peter Wagenet) #24

This seems like a sound decision. If you want any help with setting up automated jshinting, let me know.


(ryanflorence) #25

Wise choice @eviltrout.

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.

Worth noting, CoffeeScript fell off the top 10 list on github. CoffeeScripters usually still like and write JavaScript, including the language’s creator. Discourse will get more contributors with JavaScript without question.

Better create a style guide first.