Typescript is totally not windows only. It’s vanilla node.js code and runs anywhere.
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).
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.
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.
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.
JS is entrenched for sure. “JS replacement” is worded a bit strongly
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. Come to think of it, I’m only participating in this discussion because I like discussing with Discourse!
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?
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
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.
Edit: Here’s a link to asm.js. asm.js - frequently asked questions
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.
Overall, in retrospect, I still stand by the decision.
I can not argue with that.
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.