4 ms·

As someone who came into development after the Coffeescript wave I’m interested to know: how much did it feel like the future? Was it always an early adopter,

As someone who came into development after the Coffeescript wave I’m interested to know: how much did it feel like the future? 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.

wahnfrieden 6y ago
Personally speaking from what I saw around the internet and my own experiences with peers using it, it was contentious whether it was so forward-thinking or sufficiently differentiated to make it worth it.
- bartread 6y ago
  Back in 2013/14 I remember on a couple of occasions being quite annoyed when I found npm packages that I wanted to bugfix were written in Coffeescript rather than plain old JS. It always seemed so unnecessary, and tended to push me towards alternative solutions.
chipotle_coyote 6y ago
I think CoffeeScript was definitely popular outside the Ruby community, too, for a while. (After all, Dropbox was/is a Python shop, not Ruby!) 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.
dgoldstein0 6y ago
It was definitely popular beyond Rubyists - Dropbox was originally a python-based engineering organization, and we picked it up, and a lot of us liked it for a few years. 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.
- danenania 6y ago
  What’s wrong with implicit returns? I’ve always liked those in CoffeeScript and Ruby.
  - city41 6y ago
    It can cause surprises. One of the biggest ones is turning a loop into an expression if it’s the last thing a function does. Edit: here is an example https://coffeescript.org/#try:-%3E%20%0A%20%20for%20i%20in%20%5B1...3%5D%0A%20%20%20%20console.log%20i https://coffeescript.org/#try:-%3E%20%0A%20%20for%20i%20in%2...
    - rraval 6y ago
      Accumulating loop results in an array is bad for perf, but won't necessarily cause logic bugs. 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.
      - dgoldstein0 6y ago
        Another bad one: returning a jQuery.ajax object, and then consumers of your api may start using it directly. We have that in our codebase still. Not sure if it was intentional or not but it's going to be hard to undo.
    - brlewis 6y ago
      That's specific to Coffeescript. Implicit returns in Scheme don't do that.
nevir 6y ago
CoffeScript had quite a bit of influence on JavaScript and TypeScript today (and/or really great timing w/ similar thinking). All of these were in early releases of CoffeeScript, and showed up in modern JavaScript years later: * 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)
- dgoldstein0 6y ago
  ah, I forgot coffeescript had destructuring! yes, that is a great feature.
- BurningFrog 6y ago
  Yeah, is this sense Coffeescript didn't only feel like the future, it was a preview of the future.
- wonnage 6y ago
  I think it was also a forcing function for a lot of modern development patterns. Bundlers, sourcemaps, even chrome's prettyprint, all became mainstream around the time coffeescript was relevant (~2011?) I think they all existed before then, debugging coffeescript was a huge pain in the ass without them.
- dugmartin 6y ago
  I agree with some of items on your list but a lot of those features were part of ECMAScript 4 (ES4) which was largely abandoned in 2008 (with the exception of it being the basis of ActionScript 3). CoffeeScript's first commit was December 13, 2009. From the Wikipedia entry ( https://en.wikipedia.org/wiki/ECMAScript#4th_Edition_(abandoned) 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.
chanind 6y ago
Coffeescript definitely felt soooo much nicer to work with than JS at the time. Writing in Coffeescript back in 2012 felt like Typescript does now, where going back to working in base JS felt miserable after using it. ES6 took a lot of ideas from coffeescript which basically made it redundant. I wonder if the same will happen to Typescript if types get added into a future version of JS? We'll probably have another post about switching a massive codebase off Typescript onto whatever the next big thing is.
- danenania 6y ago
  TypeScript almost seems designed to be transitional, and I say that as a huge fan and heavy user of TS. Gradual typing is fantastic for learning, porting a codebase, and interop with JS libraries, but as TS gets more ubiquitous and everyone goes toward strict mode, people are going to start wanting runtime enforcement of types, and to stop adding a ‘type’ or ‘tag’ or whatever metadata key to all their objects. After getting a taste of a good type system, people naturally want to go all the way. 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.
- DanRosenwasser 6y ago
  This gets brought up a lot - but I work on both TypeScript and within TC39. Adding a type system needs consensus from the committee, and ideally we would never leave the existing community behind (because that'd be a standardization failure) and at some point someone will need to implement the static type checking portion. Who would do that apart from existing type-checkers? A team like TypeScript, that's who. :)
agilebyte 6y ago
Some things still remain in the "future" bucket and I miss in JS/TS, like the native support for literate programming which lets you write your code and documentation together and generate e.g.: https://github.com/radekstepan/metalsmith-related#source https://github.com/radekstepan/metalsmith-related#source
barrkel 6y ago
Probably the single biggest practical thing it did was fix `this` via `=>` when using jQuery or jQuery-based frameworks like Backbone.js. This didn't feel like the future so much as a fix for a giant painful wart in JS. 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.
- karatestomp 6y ago
  Yeah, just getting rid of the "interesting I guess but I'd never use them on purpose because they're just not helpful and likely to cause confusion or bugs" parts of JS, like direct fiddling with prototypally-inheriting objects (ew), worrying a bunch about what "this" means and shuffling it around for little to no useful reason, or entirely-unhelpful scoping rules. Most of those are better in regular JS now. For me, the syntax was at best neutral, leaning toward undesirable. I just wanted the extra ergonomics and safety, which didn't require such a departure from JS.
alasdair_ 6y ago
I was at Groupon when we switched to 100% CoffeeScript. Honestly, it was a pain in the ass - from what I can remember there were multiple implementations of the spec that were supposed to do exactly the same thing, but occasionally didn't, which lead to weird bugs. 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
arkanciscan 6y ago
I got turned down at a job interview in 2014 because I couldn't code coffeescript. The guy interviewing me went on-and-on about how cool it was. It was exactly like how Typescript is today.

wahnfrieden 6y ago

Personally speaking from what I saw around the internet and my own experiences with peers using it, it was contentious whether it was so forward-thinking or sufficiently differentiated to make it worth it.

bartread 6y ago
Back in 2013/14 I remember on a couple of occasions being quite annoyed when I found npm packages that I wanted to bugfix were written in Coffeescript rather than plain old JS. It always seemed so unnecessary, and tended to push me towards alternative solutions.

chipotle_coyote 6y ago

I think CoffeeScript was definitely popular outside the Ruby community, too, for a while. (After all, Dropbox was/is a Python shop, not Ruby!) 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.

dgoldstein0 6y ago

It was definitely popular beyond Rubyists - Dropbox was originally a python-based engineering organization, and we picked it up, and a lot of us liked it for a few years. 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.

danenania 6y ago
What’s wrong with implicit returns? I’ve always liked those in CoffeeScript and Ruby.
- city41 6y ago
  It can cause surprises. One of the biggest ones is turning a loop into an expression if it’s the last thing a function does. Edit: here is an example https://coffeescript.org/#try:-%3E%20%0A%20%20for%20i%20in%20%5B1...3%5D%0A%20%20%20%20console.log%20i https://coffeescript.org/#try:-%3E%20%0A%20%20for%20i%20in%2...
  - rraval 6y ago
    Accumulating loop results in an array is bad for perf, but won't necessarily cause logic bugs. 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.
    - dgoldstein0 6y ago
      Another bad one: returning a jQuery.ajax object, and then consumers of your api may start using it directly. We have that in our codebase still. Not sure if it was intentional or not but it's going to be hard to undo.
  - brlewis 6y ago
    That's specific to Coffeescript. Implicit returns in Scheme don't do that.

nevir 6y ago

CoffeScript had quite a bit of influence on JavaScript and TypeScript today (and/or really great timing w/ similar thinking). All of these were in early releases of CoffeeScript, and showed up in modern JavaScript years later: * 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)

dgoldstein0 6y ago
ah, I forgot coffeescript had destructuring! yes, that is a great feature.
BurningFrog 6y ago
Yeah, is this sense Coffeescript didn't only feel like the future, it was a preview of the future.
wonnage 6y ago
I think it was also a forcing function for a lot of modern development patterns. Bundlers, sourcemaps, even chrome's prettyprint, all became mainstream around the time coffeescript was relevant (~2011?) I think they all existed before then, debugging coffeescript was a huge pain in the ass without them.
dugmartin 6y ago
I agree with some of items on your list but a lot of those features were part of ECMAScript 4 (ES4) which was largely abandoned in 2008 (with the exception of it being the basis of ActionScript 3). CoffeeScript's first commit was December 13, 2009. From the Wikipedia entry ( https://en.wikipedia.org/wiki/ECMAScript#4th_Edition_(abandoned) 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.

chanind 6y ago

Coffeescript definitely felt soooo much nicer to work with than JS at the time. Writing in Coffeescript back in 2012 felt like Typescript does now, where going back to working in base JS felt miserable after using it. ES6 took a lot of ideas from coffeescript which basically made it redundant. I wonder if the same will happen to Typescript if types get added into a future version of JS? We'll probably have another post about switching a massive codebase off Typescript onto whatever the next big thing is.

danenania 6y ago
TypeScript almost seems designed to be transitional, and I say that as a huge fan and heavy user of TS. Gradual typing is fantastic for learning, porting a codebase, and interop with JS libraries, but as TS gets more ubiquitous and everyone goes toward strict mode, people are going to start wanting runtime enforcement of types, and to stop adding a ‘type’ or ‘tag’ or whatever metadata key to all their objects. After getting a taste of a good type system, people naturally want to go all the way. 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.
DanRosenwasser 6y ago
This gets brought up a lot - but I work on both TypeScript and within TC39. Adding a type system needs consensus from the committee, and ideally we would never leave the existing community behind (because that'd be a standardization failure) and at some point someone will need to implement the static type checking portion. Who would do that apart from existing type-checkers? A team like TypeScript, that's who. :)

agilebyte 6y ago

Some things still remain in the "future" bucket and I miss in JS/TS, like the native support for literate programming which lets you write your code and documentation together and generate e.g.: https://github.com/radekstepan/metalsmith-related#source https://github.com/radekstepan/metalsmith-related#source

barrkel 6y ago

Probably the single biggest practical thing it did was fix `this` via `=>` when using jQuery or jQuery-based frameworks like Backbone.js. This didn't feel like the future so much as a fix for a giant painful wart in JS. 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.

karatestomp 6y ago
Yeah, just getting rid of the "interesting I guess but I'd never use them on purpose because they're just not helpful and likely to cause confusion or bugs" parts of JS, like direct fiddling with prototypally-inheriting objects (ew), worrying a bunch about what "this" means and shuffling it around for little to no useful reason, or entirely-unhelpful scoping rules. Most of those are better in regular JS now. For me, the syntax was at best neutral, leaning toward undesirable. I just wanted the extra ergonomics and safety, which didn't require such a departure from JS.

alasdair_ 6y ago

I was at Groupon when we switched to 100% CoffeeScript. Honestly, it was a pain in the ass - from what I can remember there were multiple implementations of the spec that were supposed to do exactly the same thing, but occasionally didn't, which lead to weird bugs. 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

arkanciscan 6y ago

I got turned down at a job interview in 2014 because I couldn't code coffeescript. The guy interviewing me went on-and-on about how cool it was. It was exactly like how Typescript is today.