Hacker News Reader

Comment by meowface | Hacker News Reader

Why not both? This makes a good argument for ES6, but CoffeeScript's fundamental changes to syntax are just preferred by some.

View on HN

Because one day ES6 will run in browsers without a build step.

In my experience all non-trivial frontend project I've worked on have ended up with some kind of build step (minification, linting, concating, ect), with or without a compile2JS language.

This isn't an issue for node projects as you can simply `require` the `coffee-script/register` module and node handles coffee scripts for you via normal `requires`.

You don't actually need a build step for either in development. Any client-side loader can compile your CS code on the fly.

I'm not sure that's a convincing argument – you will in almost every conceivable case have a build pipeline in place anyway, so there's not really a cost there.

I don't set up a "build pipeline" until I'm sure the app is going to deployed to a production environment. Why would I set up a build for what is essentially a fiddle, or if I'm just experimenting? The now-common workflow where people write build scripts at the start of a new project is just bizarre to me.

Sure, and why do people use C anyway? You can write binary directly without any kind of make utility.

Probably because machine code is not very human comprehensible.

Neither is minimized JavaScript

You're partially right, but every build step has a cost when you're working on a large project.

Yeah but then we'll just be compiling our ES8 code with 8to6.

Is that a major concern? In practice, it's unlikely any serious use of ES6 will run in a browser without a build step due to concatenation, minification etc

Some reasons why I will stick with CS:

* Optional braces and parenthesis. Results in visually cleaner and more compact code, especially when dealing with large objects.

* Requiring backticks to do string interpolation seems like an ugly hack.

* CS uses dots to slice and splice ranges:

    host?.split(".")[-1..][0] == "dns"

BTW, notice in the example above two additional CS features that don't exist in ES6:

* The existential operator `?` soaks up null/undefined references.

* `==` is compiled to `===`

* Expressions always return a value in CS, just like in Lisp, so no need to explicitly `return`

* Block strings and regular expressions.

And more: http://coffeescript.org/

Plus, CS just seems like it's always a step ahead of JS. In using it, you can code in a more intelligently designed language that enforces best-practices better than JS does. Doing so supports diversity, innovations (after all, many of these ES6 features are obviously inspired by CS).

Why abandon such a wonderful language when it still has so much to offer, and at the same time seems to be driving innovation in JavaScript itself?

I looked at 6to5 and started re-writing a few files of CoffeeScript in ES6. First impression was not great. I'd forgotten how many curly braces are required in JS. ES6's fat arrow is just not as nice as CoffeeScript's (required parentheses, no option for thin arrow). I'll no doubt try it out again soon, but I'm not a convert yet.

ES6 fat arrow syntax doesn't require parentheses if there is only one function parameter. If there are more, parentheses make the code more readable in my opinion.

'is' is also very cool: makes it harder to write '=' instead of '=='

> The existential operator `?` soaks up null/undefined references.

This seemingly minor feature is so huge for me. Accessing deep objects?.is?.a?.horrible?.pain?.sometimes?()

If you're accessing objects that deeply, something is breaking the Law of Demeter about locality of reference and looseness of coupling.

It's a syntactic convenience, but it leads to questionable patterns. Do you really want to silently collapse the hierarchy of whatever was null? I'd rather identify it and fail with a specific message or behavior rather than generically.

I wonder if CS will evolve further now that ES6 is about to land.

Reply on news.ycombinator.com