7 ms·
I can't imagine CoffeeScript will see much adoption these days as most people seem to think ES6+ is "good enough". I miss how concise functions are in CoffeeScr
by city41 9y ago
I can't imagine CoffeeScript will see much adoption these days as most people seem to think ES6+ is "good enough". I miss how concise functions are in CoffeeScript and also miss being able to do object literals without the braces. But there's no chance at all in convincing my team to adopt it, as modern JS really is "good enough".
- jashkenas 9y agoAnd that's totally fine! I don't get a chance to use it much these days either. But for the folks who still do — or have existing codebases — this update is for you.
- jonnytran 9y agoThank you! I love CoffeeScript! It's been so sad to see it slowly fade away in favor of, in my opinion, inferior and uglier things. I -- and many others, I'm sure -- appreciate this update a great deal. I hope I get to write beautiful CoffeeScript code again soon. To parent post, why should we settle for "good enough"?
- madeofpalk 9y ago> To parent post, why should we settle for "good enough"? Because it's an actual standard and benefits from wider mindshare and support.
- tmzt 9y agoHey, I'm working on a template language that compiles into Redux + IncrementalDOM. Part of it involves a pipeline syntax similar to underscore or lodash. I'm wondering what you would consider a modern equivalent of those two libraries using native methods, iterators, etc. or if vanillajs is sufficient now. If anyone wants to take a look it's at tmzt.github.io/isymtope and github.com/tmzt/isymtope The #cleanup-symbols branch is much further along and has a mostly working TodoMvc.
- jashkenas 9y agoHmmm. If you're doing the compilation yourself, I'd imagine you could rely on what browsers provide these days, and compile to what you need. For the kinds of data transformations that templates tend to need, I wouldn't imagine that you'd really find a utility library to be necessary. Check out the Svelte output, for example.
- acemarke 9y agoVery intriguing! I'm a Redux maintainer - please feel free to ping me if you've got any questions on the Redux side of things.
- anythrow123 9y agoI still use CS every day on multiple projects. IMAO CS is one of the best non-typed languages out there. It's really sad that so many modern/babel JS proponents fail to see the beauty of it. I hope that this release (and hopefully future releases) will help to keep CS alive. Thanks to all contributors!
- munificent 9y agoI think it's worth remembering too that the reason JS is "good enough" for most these days is because of all of the great language features that you and friends put into CoffeeScript and which then got adopted by JS.
- ethagnawl 9y agoThis is not said often enough. Thanks, jashkenas!
- melling 9y agoI was browsing the CoffeeScript docs and everything looks much more concise. It seems like your code would half the size. Have people done real world comparisons on large code bases? Rewrites?
- williamdclt 9y agoWe did. And had to "decaffeinate" everything a few months later because it is hell to work with implicit returns, objects without brackets, no spread operator, significant whitespace, no variable declaration keyword... It really is a matter of taste, but the large majority of us didn't like it. It is pretty, but I felt like fighting against the language all the time (implicitly returning an bracketless object is not something that's easily readable)
- DiThi 9y ago> implicit returns In my experience it has only been a problem when porting existing code bases. We only had to be a bit careful putting a return after a for loop at the end of a function so it doesn't build a list unnecessarily (otherwise implicit returns of unused random values don't hurt). For clarity, one of the few rules we have is to use return explicitly when a function is more than a single expression. > objects without brackets The language allows it but it doesn't mean you must use them. We have a loose style guide where we forbid a few confusing uses (like bracket-less one liners or returned objects). So loose it's shorter than this comment. > no spread operator It always had a spread operator (except for the first month of life). It's just called splat instead of spread, like in Python. Now it also allows ES6 syntax which is very similar (...foo vs. foo...). > significant whitespace That's not a bug, it's a feature ;) > no variable declaration keyword In the last year or two, that only bite us once. If it's more frequent than that your functions are way too long. But as you say, it's a matter of taste.
- jashkenas 9y agoFrom the perspective of how it was intended to be used, you've got it exactly right. Just because you can implicitly return a braceless object, doesn't mean you should.
- camus2 9y agoThe only reason most people used CS was short hand function declaration and classes, It really made writing javascript easier as dealing explicitly with prototypes is a pain in the ass AND it also eliminated differences between browsers when it came to JS implementation (yes IE8 was still a thing back then). All these things are irrelevant today. 1/ Most of CS features are supported by javascript 2/ ECMASCRIPT spec is big and complex. Learning another syntax on top of something every front end developer should know is a wasted effort in my opinion.
- DiThi 9y ago> The only reason most people used CS was short hand function declaration and classes And for loops (which double as list comprehensions). And the existential operator. And "this." shorthand. Among other reasons. To my team it's also more clean-looking than Python (which used to be my favourite language), esp. when using a good syntax highlighter like Atom's (or at least that differentiates function calls, like Github's). Yes, there's not much difference now from ES6 regarding features, but for some of us it's still worth it.
- jmcgough 9y agoI miss some elements of coffeescript (the existential operator was really cool), but I think in some ways it served its purpose: large parts of it were lifted for use in es6. These days we have typescript as another option, and I feel like there's more gains from that than the syntactic niceness of coffeescript.
- sandstrom 9y agoThis is true (few adopting coffeescript), but CoffeeScript influenced much of todays ES6+, so it still lives on :)
- clairity 9y agoi really wanted to like coffeescript, but the idea of compiling, transpiling or any other kind of piling of javascript just rubbed me the wrong way. this is true of scss, less and other css flavors too. i understand the problems these tools are trying to solve, but i don't like that you have to learn two (or more) grammars and syntaxes, and the quirky interactions between them, to get those benefits (because you can't debug one without debugging the other). it's a lot more cognitive overhead for what amounts to a little syntactic sugar. standard es-whatever javascript needs to be "good enough", and, despite my disdain for using coffeescript, the improvements that coffeescript induced in javascript are heartily welcomed.
- 8ytecoder 9y agoIf you automate it and it's part of your deployment pipeline, you'd hardly notice it's there. We use both SCSS and CS via Rails and it's a breeze. The occasional times when I don't understand why something is not working I go to the coffeescript website and read the transpiled code and it's usually obvious what's going on.
- clairity 9y agoyes, i have dependencies that use both scss and coffeescript, so it's part of the deployment pipeline. i just don't like using them much myself =P
- tedmiston 9y ago> it's a lot more cognitive overhead for what amounts to a little syntactic sugar. This isn't really accurate with respect to meta languages like SCSS that add new features not present in the underlying language, like variables. You really are missing out on a lot by not using the meta languages.
- clairity 9y agoyes, variables are nice. hopefully the glacially slow integration of them into css proper (css custom properties) will arrive soon: https://developer.mozilla.org/en-US/docs/Web/CSS/--* https://developer.mozilla.org/en-US/docs/Web/CSS/--*
- fiatjaf 9y agoOh, object literals without the braces, how much I miss you!
- tootie 9y agoI honestly think both ES6, Coffee and the like are going in the absolute wrong direction. Every release replaces more keywords with punctuation marks. That's the reason the community abandoned Perl. How much productivity do I gain by replacing "function()" with "() =>"? Round and round we go. Before anyone tells me, yes I know the semantics are slightly different, but muddling the semantics with arcane syntax is not an optimal solution.
- city41 9y agoI think the comparison to perl isn't fair. It's pretty accepted that () => is a function type construct. It mimics lambdas and function calls in many other languages. Perl did really crazy stuff like storing regex results in obscure global variables. As for () =>, it can make a big difference in scenarios like `myArray.map(a => a.foo)` versus `myArray.map(function(a) { return a.foo })`
- fineline 9y ago>> Every release replaces more keywords with punctuation marks. I can't think of any other examples. Closures get used heavily in JS and arrow functions do make their use quicker and more concise, as well as fixing `this`. Compared to other languages like Scala, OCaml, Elm and Haskell, with symbols for functional combination and pipelining, pattern matching, and whatever you call the thing where you can miss out parameters and use underscores in function bodies in Scala ... JS is relatively light on symbols.
- awinder 9y agoI’m going to tell you anyways :-D. function() { ... }.bind(this) is the correct comparison to () => { ... }, which is not only a productivity gain but a readability gain.
- hasenj 9y agoI don't miss how "concise" it is. Concise syntax usually means "fun to write, hell to read". It's not that ES6 is good enough; it's that CoffeeScript is actually "bad".
- DiThi 9y agoI find idiomatic CS easier to read than idiomatic JS. Matter of taste.