Live data from Hacker News

Announcing CoffeeScript 2

coffeescript.org

121–130 of 220 posts

Re: Announcing CoffeeScript 2

#121

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…

If you like Python, you will love CoffeeScript. :) I have not used Underscore/Lodash in production, but I use jQuery a lot with CoffeeScript. CoffeeScript does not replace jQuery, although it can make your jQuery a lot nicer. As far as other libraries, there really are no restrictions; CoffeeScript compiles transparently to JavaScript. The only thing holding it back would be poor support in the specific ecosystem you…

I figured jQuery would be fine. Now that I think about it, I can't imagine why most things wouldn't really, since all javascript libraries are just extensions of those things.

Does CoffeeScript just convert the modules methods/functions accordingly when needing to be called?

Just curious how that works.

Since so much of JavaScript development, especially nowadays, ties into a lot of frameworks/libraries (modules? I'm not always sure what we want to call it), I just didn't see a reference (maybe I missed it) on their page in regards to what it actually looks like to invoke module/framework/library specific things.

Re: Announcing CoffeeScript 2

#123

Earlier quoted context omitted.

If you like Python, you will love CoffeeScript. :) I have not used Underscore/Lodash in production, but I use jQuery a lot with CoffeeScript. CoffeeScript does not replace jQuery, although it can make your jQuery a lot nicer. As far as other libraries, there really are no restrictions; CoffeeScript compiles transparently to JavaScript. The only thing holding it back would be poor support in the specific ecosystem you…

I figured jQuery would be fine. Now that I think about it, I can't imagine why most things wouldn't really, since all javascript libraries are just extensions of those things. Does CoffeeScript just convert the modules methods/functions accordingly when needing to be called? Just curious how that works. Since so much of JavaScript development, especially nowadays, ties into a lot of frameworks/libraries (modules? I'm…

CoffeeScript does not do anything framework- or library-specific. It simply compiles your code to JavaScript, which is then parsed and executed as usual.

Re: Announcing CoffeeScript 2

#124

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

That would be really nice, but CoffeeScript will probably not be adding types unless they start adding them to JavaScript.

It is a dilemma, but so far I have gotten by without type-checking.

Re: Announcing CoffeeScript 2

#125
post #72

Earlier quoted context omitted.

> cannot imagine going back to semicolons Actually, Javascript does not require semicolons to be present. If you skip them, the only edge-case is when you try to start your line with `[` or `(`. In that case, you can prefix the line with `;`.

I like consistency. And I am paranoid. When I write JS, I always include semicolons. When I write CS, it is a non-issue.

> And I am paranoid

You should write tests when building a project in a dynamically typed language to alleviate some paranoia anyway. As long as you have decent test coverage and use a decent linter/formatter such as StandardJS[0] or prettier[1], you'll be fine.

[0]https://standardjs.com/ [1]https://github.com/prettier/prettier

Re: Announcing CoffeeScript 2

#126

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.

That would be really nice, but CoffeeScript will probably not be adding types unless they start adding them to JavaScript. It is a dilemma, but so far I have gotten by without type-checking.

Well, guess it's time for someone to build yet another layer of abstraction by writing a typed superset that compiles-to-CoffeeScript then!

(I'm joking, but actually.. why not?)

Re: Announcing CoffeeScript 2

#127
post #72

Earlier quoted context omitted.

> cannot imagine going back to semicolons Actually, Javascript does not require semicolons to be present. If you skip them, the only edge-case is when you try to start your line with `[` or `(`. In that case, you can prefix the line with `;`.

I like consistency. And I am paranoid. When I write JS, I always include semicolons. When I write CS, it is a non-issue.

I have my VSC set up to automatically format and insert semicolons when I save. Saves a lot of hassle.

Re: Announcing CoffeeScript 2

#128

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

> If CoffeeScript added an (optional) type system I'd switch back in an instant.

The home page talks a little about achieving this by using Flow annotations in Coffeescript source and then having the build system pass the Javascript output to Flow: http://coffeescript.org/#type-annotations

Re: Announcing CoffeeScript 2

#129

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

Re: Announcing CoffeeScript 2

#130
post #72

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…

> cannot imagine going back to semicolons Actually, Javascript does not require semicolons to be present. If you skip them, the only edge-case is when you try to start your line with `[` or `(`. In that case, you can prefix the line with `;`.

And with Typescript (or a linter, I guess) you would get a nice red line on that 1 out of a million line where a ; is needed.

; are eyesores to an already fairly technical debt heavy/bloated language.

Post reply on HN