Was it always an early adopter, “look how forward we are” kind of thing, or was it just popular with Rubyists?
I’m trying to calibrate it with other possibly-next-big-thing front end languages.
I think the main thing to note is that we were supporting IE7+ when we adopted coffeescript. So we couldn't even write standard ES5 - ES3 would have been the lowest common denominator supported. So having classes, optional chaining, array comprehensions, for-in loops that actually looped over items in an array (like ES6 for-of) - all those features were super useful. And you didn't need to worry about function declaration hoisting (or any confusion it could cause) because coffeescript only compiled to function expressions, which got bound to variables.
Unfortunately, coffeescript came with some others like implicit returns and tons of optional syntax that we didn't realize was problematic until far too late.
And being a python-based org, having a frontend language that looked similar (space-delimited, a lot of similar features e.g. array comprehensions were like list comprehensions, ternaries that looked more readable) seemed like features. But some of these features bit us hard at times, because they didn't work like python - the worst, in my opinion, was that `is not` and `isnt` looked the same but meant very different things in coffeescript. `is not` meaning `=== !` and isnt meant `!==`.
But given the alternative was writing prototypical-inheritance by hand, and dealing with various IE7isms directly? It was a sensible tradeoff at the time.
Edit: here is an example
https://coffeescript.org/#try:-%3E%20%0A%20%20for%20i%20in%2...
My favourite implicit return gotcha comes from the intersection of CoffeeScript and jQuery, where implicitly returning `false` from an event handler implies `preventDefault()` and `stopPropagation()`. This can even cause heisenbugs if your logging throws booleans around.
We have that in our codebase still. Not sure if it was intentional or not but it's going to be hard to undo.
* fat arrow functions
* classes
* template strings, multiline strings
* destructuring and ...rest values (splatting)
* elvis operator (foo?.bar?.baz - in TypeScript)
honorable mention
* list/iterator comprehensions (made some good progress in the ES speccing process, but ultimately didn't land)
From the Wikipedia entry ( https://en.wikipedia.org/wiki/ECMAScript#4th_Edition_(abando... )
---------------
By August 2008, the ECMAScript 4th edition proposal had been scaled back into a project codenamed ECMAScript Harmony. Features under discussion for Harmony at the time included:
- classes, - a module system, - optional type annotations and static typing, probably using a structural type system, - generators and iterators, - destructuring assignment, and algebraic data types.
---------------
I enjoy working in TypeScript in VSCode since it feels just like working in ActionScript 3 in FlashDevelop. except a bit slower.
It had a lot of hype behind it, in much the same way TypeScript does now.
>Was it always an early adopter, “look how forward we are” kind of thing, or was it just popular with Rubyists?
Hard to say. Groupon still used it even after they ditched Ruby for node.js (and lost a whole bunch of engineers that wanted to continue using Ruby).
>I’m trying to calibrate it with other possibly-next-big-thing front end languages.
There is always another next-big-thing front end language/framework/library/tool. They all promise to change the world. I've personally used C with CGI-BIN, Perl, ASP.net, PHP (back when it was Personal Home Page), Java with servlets, J++ (the Microsoft "embrace, extend, extinguish" version of Java. Seriously, fuck Microsoft for doing this), J2EE, Struts, Seam, Spring, Struts2, SpringBoot, Jquery, AngularJS, Angular without TypeScript, Angular with TypeScript, React (and that whole ecosystem) and I'm sure I'm forgetting a few - every one of them promised to be "the future".
In the end, most front-end developers seem to spend half their working hours learning a new stack because of the constant change. This is fine - learning stuff quickly is part of the job, but sometimes I wish we would collectively take a pause for a year without any new frameworks, transpilers, meta-languages etc. etc. and just focus on seeing what stuff works best in the longer term.
I'd like us to collectively remember Antoine de Saint-Exupery's maxim "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." instead of adding three hundred "essential" node.js libraries on to the next CRUD app we build.
I think it's important to learn the basics well first. Just make some stuff with hand-coded HTML, maybe a bit of CSS, some forms (or AJAX-like calls if you must) and something on the server to do some processing on the stuff you send it and spit back a result. Or, even, just spend a bit of time appreciating the beauty of motherfuckingwebsite.com
The second nicest thing about it was the way it eliminated a lot of ceremonial redundancy around code, parentheses in particular. Just like Ruby, it's not actually a great idea to leave those out due to ambiguities, but when you want a micro-DSL to encode some pattern, it really helps reduce the syntactic noise.
Third thing was being opinionated about how you structure classes and objects. This, again, didn't feel like the future; it felt like papering over a big gap in JS.
Speaking strictly for myself, while I liked a lot of what CoffeeScript was trying to do, I didn't love the "one layer removed" feel of writing in a language that wasn't the one actually being executed. Also, I often found CoffeeScript to be cryptic in ways that vanilla JS, for all its quirks, really wasn't. So I think it felt like the future for a couple years, until JavaScript ES6 took off and it started feeling kind of superfluous -- ES6 felt like it was taking the good parts of CoffeeScript while leaving a lot of the quirks behind.
If TS doesn’t figure out how to provide this in a nice way, I imagine there will be a fork or a new dialect eventually, or JS will get types added natively like you say, and lots of people will move in that direction.
Who would do that apart from existing type-checkers? A team like TypeScript, that's who. :)