Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm not sure that this conclusion follows nor am I sure that discussions like this accomplish anything. CoffeeScript makes it easier to write "correct" JS and patches an institutional bug: Javascript's development crawls along. Even if it didn't the browser-as-environment handcuffs developers from taking advantage of new language features. (Have you used JS array comprehensions? No, because browser support is spotty, unreliable). And even in the best of development climates -- a thousand genius hackers ardently updating the code base -- these environmental restrictions would persist, drawn over the frame of IE-Mozilla-Google conflict and competition.

So we have languages that compile to JS that let the language evolve. I use CoffeeScript sometimes and JS sometimes. I'm not going to waste the time in the write-compile CoffeeScript loop for 100 lines of JS that I can write correctly. However, I no longer have to work on a 2k LOC, complex JS app without all the niceties of CoffeeScript. Furthermore, if I'm doing something that benefits from the special expressivity of a Lisp, I'll use clojurescript. If I'm very adventurous (and I need to write, say, an H.264 decoder), I'll use emscripten after any language that compiles to LLVM first.

But these are all for different uses, often things you would never have used POJS for anyway. It's not a discussion of plain ol' JS versions of H.264 encoders vs those made originally with Emscripten. It's a discussion of them not existing at all before, and now having the ability to express them and compile to JS. It's not a question of the old enormous apps we built in JS to the new, simpler ones we express in CoffeeScript. It's a question of not being able to build/maintain 5k LOC in POJS across many developers (whereas this task is less substantial in CoffeeScript). Live and let live and everyone benefits.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: