Hacker News new | past | comments | ask | show | jobs | submit login

Often because the "standard" thing was not always the standard.

Like, all those people that chose Flow now have something "non-standard."




Coffeescript used to be "standard" in Ruby on Rails community.

(insert canned laughter)


Coffeescript had astonishing success, so many constructs made it to ecma standard.

Coffeescript is still better than js with many ideas - everything is an expression, comprehensions, existential operator, extended switch statement, chained comparisons overall terse, readable syntax.

Some things are terrible ie. type annotations through clunky comments.


I think the absolutely fatal mistake CoffeeScript made was implicit variable declarations, and how that worked with variable shadowing. Once it became clear that it was downright dangerous not to hack explicit variable declarations in using IIFEs, the entire language became a clunky mess.

I have a ton of respect for the language and all of the stuff it cross-pollinated into JS, but it’s an interesting object lesson in how a seemingly tiny design choice can turn out to be disastrous.


Yes, that was stupid. Also not embracing flow/ts when they had a chance still riding on atom/rails.

I guess when exploring uncharted territory it's a bit of a dice roll - you can't keep winning all the time.

Otherwise great contrib to advance frontier.


>implicit variable declarations, and how that worked with variable shadowing.

Coffeescript was before my time so I never used it, can you give an example of the problems this caused?


Basically, if you want to declare a local variable, you just assign it where you want it declared. It gets scoped automatically to whatever block it’s first assigned in. But if a variable with the same name was already declared earlier (for example in the parent block), then the language doesn’t provide a way to say “this is a new declaration”.

So what can happen is that you have some large block of code where, for example, near the top, you’ve said “x = 1”. Then, maybe a few hundred lines down you have a loop, and inside the loop you say “x = getWidget()”. You think you’re declaring a new variable, but actually you’re reusing a variable from the outer scope. There’s no way to know if you’re accidentally doing this except to search the entire enclosing scope.

It’s even worse in the other direction. You have a small block way down in a function where you’ve said “x = getWidget()” and this is all fine and correct. But you need to add something to the top of the function, and you add “x = 0”. You’ve now retroactively changed the scope of some random variable you weren’t even thinking about.

Edit: Actually my memory’s a little rusty, but I think they actually removed any kind of block scoping entirely by version 1, but everything I said above still applies to nested functions, which you tend to use liberally in CS.


> existential operator,

JavaScript has had this for a bit now and it is really nice.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...


Existential operator can be used as optional chaining operator but also in trailing position ie:

    if window?
      env = 'browser'
      ...
is equivalent to:

    if (typeof window !== "undefined" && window !== null) {
      env = 'browser'
      ...
    }
But yes, nullish coalescing and optional chaining that came from existential operator are good.


Why the laughter? CoffeeScript was great. TypeScript is even greater. All IMHO and YMMV, of course.


Some companies built a lot in CoffeeScript. Maintaining that won't be fun.


IIRC it compiled down to readable JS, so one reasonable option is just to delete the CoffeeScript and maintain the generated JS code.


Also it feels like LLMs were kind of born for that type of conversion.


And prototypejs before jquery!




Consider applying for YC's Spring batch! Applications are open till Feb 11.

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

Search: