Is it better for Discourse to use JavaScript or CoffeeScript?

(Peter Burns) #36

Typescript is totally not windows only. It’s vanilla node.js code and runs anywhere.

(SkinnyGeek1010) #37

What if you would convert each module/script to vanilla as it’s modified? This would gradually convert everything over to JS as time permits. A solid style guide would be a must though!

I find that you can tab-trigger your way out of the ‘vanilla’ JS is more typing problem. You can have presets setup for almost everything… methods, functions, anon callbacks, AMD modules, etc…

One advantage that CS has is that it’s more readable if you work with CS a lot. However, I found it hard to parse blocks when I first started writing it ( I mainly use it for tests currently).

(Chad_Lancour) #38

From a personal perspective, the only reason I would contribute to discourse is because the client base is coffee script. JavaScript… All the amazing innovations in tech… JavaScript? Kids don’t like it, and I’d put 50 bucks that JavaScript is the mainframe tech stack of the next generation(to be replaced). 5 years from now your coffee script can be compiled into JavaScript’s replacement. Discourse is awesome BECAUSE coffescript was used and enables creativity to trump syntax. Switching to JS might just send you “off course”.

(Sam Saffron) #39

I would hope you would like to contribute to the project because you believe in the mission, like the software and want to evolve and improve online Discourse, not purely because we chose js or cs.

(Nathan Long) #41

5 years from now your coffee script can be compiled into JavaScript’s

Javascript has been running in browsers for 18 years. It’s been adopted by every browser on every platform.

It’s possible that in 5 years, an alternative language will be supported by some browsers (and that would be nice). But it’s near-certain that Javascript will still be supported by all browsers. It has too much inertia to disappear that fast.

(Chad_Lancour) #42

I agree with you on your point. To clarify: It’s not that I would only contribute to CS projects, it is that I’m not a JavaScript guru (I’m more of a devops/data warehouse/automation creature). I see CS as a tool that enables others to create clean & functional JS, is easier to read (opinion), and would provide an easier entry for me as a contributor.

Though come to think of it, it seems there are other barriers to contributing to open source other than the language itself. Contribution processes, Git pull requests, anxiety around being publicly chastised for janky pull requests, etc. :smile:

How about streamlining the contribution process? Seems like there could be an opportunity here for some interesting open source development as well… a “GitHub” like service that manages contributions, integrates with github(others), and makes the contribution process more welcoming for developers who may be coming from varied backgrounds.

(Chad_Lancour) #43

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:

(Rahil Sondhi) #44

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?

(Jason Livesay) #45

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 (

(ThiefMaster) #46

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

(Brad Murray) #47

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.

(Kaare Skovgaard) #48

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.

(Forentroll) #49

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. asm.js - frequently asked questions

(Sam Saffron) #50

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.

(Sam Saffron) #51

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.

(Forentroll) #52

I can not argue with that.

(Kaare Skovgaard) #53

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

(Tony Brown) #54

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

(Kasper Peulen) #55

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.

(Kevin P. Fleming) #56

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.