Comment by arp242 | Hacker News Reader

Comment by arp242 | Hacker News Reader

Parent Full thread

> I wrote a bunch of CoffeeScript back in the day, and everyone I've spoken to about it feels the same, that it was a bad idea in hindsight

I don't think it was a bad idea in hindsight.

JS of the era was a pain to use; CoffeeScript made writing and reading things much easier, which is the reason it took off. Since then things changed and many "CoffeeScript features" are now "JavaScript features". Only with knowledge of that future would it be a "bad idea", but it was absolutely not clear that was going to happen back in 2010 and in alternative universes we're all writing CoffeeScript today.

I also think CoffeeScript was probably helpful in getting some of these features adopted in the first place.

The same applies to TypeScript – maybe typing will be added to JavaScript, and TypeScript will become redundant – I think there was some proposal and who knows what will happen. In 15 years we can say the same about TypeScript, but that doesn't mean TypeScript wasn't useful today, with the current state of JavaScript and uncertainty what the future may or may not bring.

> CoffeeScript made writing and reading things much easier

My point is that it kinda didn't. It looked prettier on the surface, but didn't actually solve any of the deeper problems of writing JavaScript. To write CoffeeScript you had to still know JavaScript and all its oddities.

TypeScript solved those problems, and that's why it has taken off and had a meteoric rise to the point that it's practically synonymous with JavaScript.

> I also think CoffeeScript was probably helpful in getting some of these features adopted in the first place.

This may be true, but if so that suggests a benefit as a research language not a production language.

Coffeescript had some great features: classes, array comprehensions, default parameter values, arrow functions, optional chaining. Many of these eventually made it to ecmascript.

And then it ruined us with implicit returns, optional parentheses and brackets, and the isnt vs is not fiasco.

I worked a lot with Python and coffeescript at the same time back in the day. In Python you mess up your whitespace and 95% of the time it's an indentation error. In coffeescript it's a valid program that means something completely different than what you intended. Combined with the optional punctuation, which the community encouraged leaning into, it was far too easy to write ambiguous code that you and the compiler would come to different interpretations of.

In case you wondered how Civet compared to CoffeeScript in these regards:

* `is not` is the textual equivalent of `!==`. You can use `isnt` if you turn on the feature explicitly (or even the weird CoffeeScript `is not` behavior if you want it, mainly for legacy code)

* Implicit returns are turned on by default. They are really useful, most of the time, and don't get in the way much if you use `void` return annotations (which turns them off). But if you don't like them, you can turn them off globally with a compiler flag.

* Civet's compiler is built on very different technology from CoffeeScript's (PEG parsing, similar to Python), and it is much more strict about indentation. None of those weird bugs anymore.

* We do have implicit parentheses and braces and such, but you're free to use explicit parentheses and braces as you like. We encourage people to rename their .ts files into .civet (which mostly just works without any converison) and just embrace the features/syntax they like.

> but you're free to use explicit parentheses and braces as you like

I’ve been eying Civet and I quite like it so far, but I dislike having this option because it means I’ll have to see it in other peoples code. I prefer strict rules for readability.

Regardless, I like pretty much everything else.

> And then it ruined us with implicit returns

What was so ruinous about implicit returns? That's one of the things I missed most when leaving CoffeeScript. ECMAScript only partially adopted it (single statement fat arrow functions) which probably muddies the waters for people trying to learn and understand the language's behavior.

Since it's optional for the caller to use or assign the return value of a function, I don't see much problem with functions defaulting to returning something. Maybe it just fits with my personal preference of functions returning a value and not having side-effects..

probably gets better with use but having to remember not to put a loop as the last statement of a function, because it would make it return an array of the last statement of the loop body, caught me off guard enough times to get annoying.

easy enough to add an extra line with just 'undefined' as the last statement of the function of course. but then you do need to remember that.

I came from Ruby and Elixir. It is always implicit returns. When I started writing TypeScript, having to have explicit returns was my number 1 bug.

People can adapt either way. You can write more concise code with implicit returns and "everything is an expression".

> implicit returns

Oh man, that brings memories. When I joined a coffee-shop (pun intended), and learnt about implicit returns, I was screaming internally until we got rid of all the coffee (which was massive long team-wide migration effort that took like 2y to finish).

Once the migration was finished, everyone was so tired, that at the mere proposal of using TypeScript instead of JS the whole team would just roll their eyes and silently say "nope" in terror. Which was a shame, because large JS codebases are difficult to maintain and explore.

In Ruby and Elixir, it is implicit returns. That's always been like that, and people working with those languages don't have a problem with it. When I started writing Typescript, I was screaming internally at the explicit returns.

So I think this has more to do with how people are used to thinking with the languages they are fluent in.

It didn't solve the deeper problems, no, but it also didn't error out when you accidentally had a trailing comma in your object, -> and => made dealing with "this" less painful (no more "var that = this"), and stuff like that.

Convenience does matter. The less I have to think about nonsense like that, the more I can think about actually writing correct code.

CoffeeScript wasn't perfect in that sense either and had some nonsense of its own. That probably contributed to its demise as much as any thing else.

My biggest gripe with CoffeeScript, beyond it's scoping being madness [1], is it made writing very inefficient JavaScript much easier. The language was full of footguns.

Many times something would look perfectly reasonable in CoffeeScript but when you would actually read the JS it would be iterating the same dataset multiple times to grab individual items that could have and should have been a single loop.

1. https://donatstudios.com/CoffeeScript-Madness

It's the Hibernate problem all over again. Any time one language is layered on another, the user is totally unaware of the degenerate cases that they are triggering, and the higher language is usually blocked from fixing those. Similar to C++ preprocessors which generated poor C.

You just about need some sort of ast optimizer or some such.

TypeScript even took off after the earth had been salted by CoffeeScript. Many people were sceptical about TypeScript because they assumed it was as big of a buy-in as CoffeeScript - rather than it just being JS with some (mostly) strictly-additive syntax, that you would have been able to strip out without risk had TS never taken off.

> TypeScript solved those problem

I don't think TS removed any peculiarities of JS. It just forced you to actually learn them which JS and CS didn't do.

Regardless of one's opinion on duck typing, Javascript was like feeling out for ducks with your hands in the dark, typescript was like being able to see for the first time.

> TypeScript solved those problems, and that's why it has taken off and had a meteoric rise to the point that it's practically synonymous with JavaScript.

It's also backed – nay, pushed – by one of the largest and most successful tech companies in the world. A company that also made a point of releasing a very capable IDE to go along with it. Surely this has had some impact on its meteoric rise? :o)

(Wait – aren't meteors falling?)

I never wrote enterprise apps in it but the short syntax and arrows made it easier to prototype/ reason with it.

It probably died fueling the whole js build/transpiler landscape that is in use today.

> JS of the era was a pain to use; CoffeeScript made writing and reading things much easier

It didn't. Anything you learn / are familiar with will be easier to write - Coffescript was easier to write for people who learned Coffescript. Which in hindsight wasn't time well spent as they would've eventually had to bite the bullet anyway & just learn JavaScript like everyone else.

JavaScript is much much easier to write and read for a person who has chosen to learn JavaScript & has not had the occasion to learn Coffescript (i.e. most people) so you were also doing others a disservice if readability was one of your goals.

> which is the reason it took off

The reason it took off was the Ruby was going through a popularity trend & Rails devs wanted to work in a front-end language that felt syntactically familiar. It was purely aesthetic.

Around 2012, I had sunk several years into becoming extremely familiar with JavaScript when I switched onto a team which was using CoffeeScript. I immediately liked it: it addressed some of the things I'd always found irritating about JavaScript, and I found it very easy to pick up. I was not a Ruby or even Python user at that time, so that didn't influence my decision either.

But you're right that you did have to know enough JS to understand what CoffeeScript was doing under the hood when things went wrong.

This sounds a bit like all design is just what you are accustomed to, which seems wrong.

> JS of the era was a pain to use

Was it really?

Outside of arrow functions, I don't really think CoffeeScript had a single important idea. And even then, the aversion to the `function` keyword in the JavaScript community never fails to make me laugh. Sure, sometimes the implicit scoping of the arrow function is nice, but man.

Reply on news.ycombinator.com