> 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.
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.
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.
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.
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.
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)
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.