141–150 of 220 posts
Earlier quoted context omitted.
I felt the same way when I switched from CoffeeScript to TypeScript but the type checking was worth all the braces, returns and lack of existential operator. If CoffeeScript added an (optional) type system I'd switch back in an instant.
It’s not elegant, but there is a way to do type checking in CoffeeScript: http://coffeescript.org/#type-annotations
But wow, "not elegant" is an understatement.
Earlier quoted context omitted.
And 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.
I 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.
Wasn't able to promote it at work though, because of the lack of support at that time (it felt kinda rusty, most 3rd party libraries were deprecated, and no jsx).
Glad to see things are changing, the new release looks great !
As much as I love CoffeeScript (because I love Python), I think over time the project is loosing it's value due to ES6 (Frankly I believe even TypeScript is going to suffer the same plague soon). One possible incentive for me might be the toolkit and the pre-built stuff that I can get out of box from such transpilers (JSX is a good addition for example, however I am surprised why something like PUG, or HAML was not a…
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".
I 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…
As for () =>, it can make a big difference in scenarios like `myArray.map(a => a.foo)` versus `myArray.map(function(a) { return a.foo })`
This is honestly the first time I have looked close at CoffeeScript. At a passing glance, it looks really close to Python with javascript elements added in. Is that a correct assessment? If it is, this might be for me. My other question is: how nice does coffee script play with other libraries? We (unfortunately) use jQuery a lot. I have also been using underscore and lodash as well. Are those two even needed when wr…
In open source, it's lovely, and fairly rare, to see someone pick up the ball on a quiet project, and run with it to completion without getting frustrated or losing interest first. Geoffrey Booth — with big assists from Simon Lydell and Chris Connelly — has really gone the distance here, spending a full year working on drafts of CoffeeScript 2.0 to upgrade it from a language designed around ES3, to make it as ES6+ fr…
CoffeeScript is still very relevant for me. I have two medium-sized Ember projects written in CoffeeScript (and Emblem and Sass--the original, indented variety, thank you very much). I have been looking at React (will probably skip due to the patent license) and Vue, but cannot imagine going back to semicolons and (excessive) curly braces and parens. If you married CoffeeScript just out of convenience (being able to…
I loved CoffeeScript, but I felt it was a double edged sword. I would still use it though, if there were JSX style xml/html tags. But React changed everything for me and as a full stack dev, I can use only few frameworks on one level. Edit: Ok, JSX is now supported. http://coffeescript.org/v2/#jsx And I'm glad they broke the different behaviour of =>. It might need a fix in a lot of code bases, but this price is chea…
I wrote a comparison about it a couple years ago: http://rapin.com/blog/2015/02/03/reactjs-with-coffeescript/
I'm not doing much react these days (cough elm), but I think it's still mostly relevant.
That's entirely possible, and the setup would look like this:
CS would produce a babel-compatible AST, instead of producing the final ES6 source code. It would simply leave the job of generating the final code to babel (via babel-generator).
You'd then be able to re-use some (though not all) of babel plugins on top of CoffeeScript. babel-macros for example will work out of the box: https://github.com/kentcdodds/babel-macros
ESLint would mostly work out of the box. Syntactic rules won't be relevant anymore, such as the one that enforces semicolons, but other rules will be fully useful. You could still enforce no undeclared vars for example. Importantly, you'd still see ESLint errors in your editor exactly where they occur in the .coffee source file, and not in the final transpiled file. This would work, because ESLint can read a babel-compatible AST which is what CS would produce. I've already tried in a small POC.
I'm sure it would be trivial to patch TypeScript to accept babel-compatible AST instead of doing the parsing itself. You'd then use TypeScript as a type-checker and not as a transpiler (This is already possible iiuc with babylon 7). Type checking would then work in .coffee files just like it would in .ts files. Some language-server commands like find-references, goto-definition, and show-type would also work. Refactoring commands of course wouldn't work, because they are specific to the typescript syntax.
Flow would work out the same way too. Right now it has its own parser written in OCaml, which produces an AST that is compatible with that of babylon 7. All you have to do is to bypass that parser and get the AST from CS. You'd then get type errors inside .coffee files, and all the other goodies you expect from flow.
---
There is no reason why one should have to choose between CS and the rest of the JS ecosystem. The fact that you have to give up type-checking and linting in exchange for CoffeeScript/SweetJS/your-favorite-stage-1-proposal, is only because the tools don't play nicely together. They could. And with all the recent standardisation work already done, that is a low-hanging fruit.
CoffeeScript is still very relevant for me. I have two medium-sized Ember projects written in CoffeeScript (and Emblem and Sass--the original, indented variety, thank you very much). I have been looking at React (will probably skip due to the patent license) and Vue, but cannot imagine going back to semicolons and (excessive) curly braces and parens. If you married CoffeeScript just out of convenience (being able to…
I loved CoffeeScript, but I felt it was a double edged sword. I would still use it though, if there were JSX style xml/html tags. But React changed everything for me and as a full stack dev, I can use only few frameworks on one level. Edit: Ok, JSX is now supported. http://coffeescript.org/v2/#jsx And I'm glad they broke the different behaviour of =>. It might need a fix in a lot of code bases, but this price is chea…