Is it better for Discourse to use JavaScript or CoffeeScript?

JS is entrenched for sure. “JS replacement” is worded a bit strongly :slight_smile:

I guess my gut is that CS is a good thing, and provides a LAEOT for faster training and smoother learning curves to incoming tech talent. There are a gazillion things that could be built to improve the dev cycle for CS such as migrating comments and debugging linkage across to the compiled JS. Plugins for browser dev tools that provide ability to use the debug linkage to trace back to CS source, in browser CS compiler plugin for real-time code edits in browsers, and more.

I see Discourse as a total standout on UI, functionality, and stack. If we rolled back the clock, It’s hard to say where Discourse would be without CS at this point. :slight_smile: Come to think of it, I’m only participating in this discussion because I like discussing with Discourse!

I’m out. :sunny:

I agree with this.

Choosing between JS and CS is about the preferences of the contributors. Why did the core developers choose CS to begin with and why did they switch back to JS?

I prefer CS because it’s such a pleasure to read and write; it gets rid of the ugliness of JS. I have an understanding of JS so CS is not “shielding me from the real thing,” and I have no problem reading through the compiled JS when it comes time to debugging.

Lastly, why are we still having this discussion when it seems the decision has already been made?

1 Like

Personally, I think that converting to JavaScript is obviously a step backwards. CoffeeScript is a lot less code, easier to read, and it solves a significant number of problems. The only reason I can see that someone would want to change it back to JavaScript that is if they either hadn’t learned CoffeeScript or they had just spent so many years writing JavaScript that they couldn’t get used to CoffeeScript.

I don’t think it is a priority to do any major conversion, but if, down the line, you wanted to start converting stuff, I would go in the opposite direction.

I suggest that you consider converting the entire back end to CoffeeScript and Node.js.

And then, if you are really trying to make a language improvement, you can convert everything to LiveScript (http://livescript.net/).

I’m miss a “dislike” button right now :slight_smile:

1 Like

I find it quite ironic that the best technical reason for avoiding coffeescript (as @wycats said) is to future-proof against the ES6/7 syntax changes… which to many observers look like Javascript finally waking up to the fact this so many hate the syntax - which is what made coffeescript so popular. Quite a few changes appear heavily inspired by improvements made by CS.

One point no-one has made, but I see it frequently when mentoring, is that people new to web languages will typically pick up Coffeescript much faster than javascript, but at the same time actually learn good javascript patterns because of reading the javascript emitted by the CS compiler whenever they are working in the browser. Source maps may change this.

We use CoffeeScript at my workplace, and have done so for that past 9 months or so (or well, that’s how long I have been using it for). What I love about it is that if you know JavaScript - once you glare over the main page - you can quickly read and understand a very large part of CoffeeScript (I’d argue about 95%) - whenever you hit something you do not understand - hit the main page and you’ll quickly figure out how exactly it works. The fact that the documentation lists 1:1 what CoffeeScript code will get compiled down to is a huge plus.

The great part is, that you’re also quickly able to write CoffeeScript code. Granted to begin with you may make it more “JavaScript like” - but you can write working code very quickly. As you get more and more used to the syntax and shorthands, your code starts looking more like CoffeeScript. But the biggest selling point for me with CoffeeScript over JavaScript is the simple fact that so many of JavaScripts pitfalls are simply not there anymore. Yes - there’s still quite a few left, but far from as many.

Personally I see the biggest problem with writing the code in CoffeeScript is that the same kind of simple operation can be written in so many different ways - and I would suggest using something to ensure consistent syntax being used all around the code base. We do not currently do this where I work - and it is actually the only thing that annoys me about CoffeeScript at the moment. Not that every other programming language (except maybe Google Go) doesn’t have this problem, but I think CoffeeScript is especially susceptible to this (parens or not? Braces or not? Comma or newline separation between arguments?, etc).

All in all, I think the pros far outweigh the cons.

Since Discourse is a future web project, why not embrace code-to-code compilers like CoffeeScript or LiveScript or etc. from the point they are able to produce the asm.js subset of JavaScript?

  • Worst case scenario is, nothing happens, but at least you have code better readable than JavaScript. Ok, that’s a matter of
  • Best case scenario is, most browser vendors pick up those optimization and you have faster code than handcoded JavaScript would probably be.

Since Discourse is a reference for JavaScript browser applications, why not encourage or even help “transpiler” and browser developers adopting asm.js? (Given, you have the ressources, of course.)

Edit: Here’s a link to asm.js. http://asmjs.org/faq.html

I am strongly against using anything that is not ECMAScript, though when the time is right and ES6 is ratified I am not against us embracing a transpiler to bridge us while browsers catch up.

2 Likes

Also, for the record. Ever since we moved back to JavaScript we have noticed a significant raise in the amount of JS contributions.

Overall, in retrospect, I still stand by the decision.

8 Likes

I can not argue with that.

If you get more contributions by sticking to JavaScript, then I guess it is a no brainer.

Nothing wrong with JavaScript, I think the way CS writes my JavaScript for me

Have you guys considered using Google Dart instead of javascript? I only now it for an hour myself, so I don’t really have an opinion if this would be an good idea or not. But from what I’ve read, some people seem to think that using dart instead of javascript, is like using ruby/python instead of php.

It’s a bit late for an entire language change at this point; that would also require finding a replacement for Ember and many other client-side libraries that Discourse uses.

2 Likes

I think, if you really want a decision is on, weighing the benefits.

You really have to ask yourself the question, why did we use CoffeeScript quoting you, “most our stuff”?

Better?
If your conclusive answer is; because it’s better, then you have failed to convince others (possibly newcomers) about the benefits you once believed in.

You should be asking what has changed? Is it the people who refuse to learn something new? or is it because CoffeeScript is no longer holding true to the reasons you initially believed in.

CoffeeScript has a really quick learning curve, takes no more than a week or a month to get started (at least it was for me with no help apart from google-ing), my point being is, that by investing a little time to learn CS, you will save a lot more time than continuing to write JS in the long run.

If your answer is not better, then you should know what to do.

To those who say, JS trumps CS, I think it’s untrue