Hacker Newsnew | comments | show | ask | jobs | submit login

    > Knowing exactly which of these options CoffeeScript will take 
    > will give me a better understanding of the long-term viability 
    > of CoffeeScript.
Mmm, nothing like the whiff of uncertainty on a summer evening ;) For starters, you needn't worry -- CoffeeScript already being a heavily forked open-source project, I'm sure there will be versions (whether Coco, Live, Iced, Gorilla, or perhaps a cutely named CoffeES6cript) that track each of the options you've listed.

But you asked about my proposal. I'm most interested in targeting the useful subset of JavaScript that runs across the popular JS platforms at any given moment -- not what may or may not exist in the future, but lives currently as a spec; and also not features that actually exist, but aren't essential (read, harmful, error-prone, nasty), like getters and setters, or E4X (in my opinion, natch).

So in general, what I'd like to see mainline CoffeeScript do, is adopt useful ES6, ES7, and ES8 features, as soon as they land in enough platforms/browsers to be widely useful (yield may be at this point already, or very soon), and to continue to try and find a pleasing minimalist syntax for writing and reading them. If this means taking the ES* syntax wholesale, that's fine. If it means minting a new (and hopefully, but arguably, nicer) syntax, that's fine too. And if it means breaking backwards compatibility, that's also alright, as the compiled lowest-common-denominator JS output will still be perfectly compatible with the new stuff.




Thankfully E4X doesn't actually exist anymore (as of FF 21) :)

-----




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: