Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing Eloquent JavaScript Without CoffeeScript

oscargodson.com

Post reply on HN
Print view View original

31–40 of 55 posts

Re: Writing Eloquent JavaScript Without CoffeeScript

#31

Post by fogus »

jashkenas wrote: post #13

Just to clear one thing up -- Oscar writes: > The examples on the CoffeeScript site are purposely written > to be ugly to make CoffeeScript look even prettier. ... not at all. The side-by-side examples on CoffeeScript.org are showing you the compiled output . The point is to demonstrate -- although it's certainly far from perfect -- how CoffeeScript features can be compiled into clean JavaScript. Really, our goal is…

This kind of clarification is exactly why I posted this link. It's great to clear the air in one respect and at the same time ask the question, "is there something on the CS site needing change to avoid this confusion?"

Re: Writing Eloquent JavaScript Without CoffeeScript

#32

Post by scarmig »

mquander wrote: post #24

Oscar, when your code itself is making little frowny faces at you after you write it, something has gone wrong. x == 1 ? alert(x) :( alert('Error'), x = 1, alert('All Fixed!') );

Does javascript guarantee a particular order of expression evaluation when there aren't any sequence points?

Alerting 'All Fixed' and afterwards 'Error' seems like it'd be just as valid an interpretation of the code.

Edited to add: Actually, I think the comma operator does do that, so no bad. Though the code is still unsightly...

Re: Writing Eloquent JavaScript Without CoffeeScript

#33

Post by 198d »

fogus wrote: post #31
jashkenas wrote: post #13

Just to clear one thing up -- Oscar writes: > The examples on the CoffeeScript site are purposely written > to be ugly to make CoffeeScript look even prettier. ... not at all. The side-by-side examples on CoffeeScript.org are showing you the compiled output . The point is to demonstrate -- although it's certainly far from perfect -- how CoffeeScript features can be compiled into clean JavaScript. Really, our goal is…

This kind of clarification is exactly why I posted this link. It's great to clear the air in one respect and at the same time ask the question, "is there something on the CS site needing change to avoid this confusion?"

This has come up A LOT more than it should. There's a line immediately before the first example explaining exactly what you're looking at. It's slightly absurd to assume that's how you'd actually write those examples in javascript. The compiled javascript is rather approachable, though.

Re: Writing Eloquent JavaScript Without CoffeeScript

#34

Post by dmauro »

He makes a great point in favor of CoffeeScript: making your JavaScript look nice takes much more work without CS. The fact that he is lining up the multi-line string line breaks says loads about how CS will more easily make your JavaScript look good. How many times have you tried to line up your equals signs or colons only to then later add a longer key or var name that required you to further tab over your = or : to keep things lined up.

But feel free to correct me if I'm wrong, but I doubt vanity is the primary reason people are using CS. My number one favorite feature is the list comprehension, and if it didn't have that, I might not be bothering with it.

Re: Writing Eloquent JavaScript Without CoffeeScript

#36

Post by pyeek »

I really don't understand the point of the blog post.

So Javascript can be formatted to look kind of like CoffeeScript?

While I agree that Javascript is often misunderstood, to me his formatting of Javascript is making things much worse, in terms of maintenance (yeah...let's all line up equal signs...).

I personally DO NOT write CoffeeScript but I think the difference between CoffeeScript and Javascript goes beyond formatting. Writing CoffeeScript seems to me to be a syntactic improvement and eliminates some of the need to really learn Javascript (which I think takes quite a bit of effort)

Re: Writing Eloquent JavaScript Without CoffeeScript

#37

Post by Stratoscope »

There are some real problems with these "eloquent" styles.

They work only in a monospaced font. I code in a proportional font, and none of the column alignment tricks will look right when I view the code.

Even if you like to code in a monospaced font, there's no reason to write code that becomes hard to read in a proportional font. It's very easy to write code that is perfectly readable in both monospaced and proportional fonts: you merely forgo these column alignment tricks.

Also, this style of code is a pain to maintain. If you add a variable with a longer name, you have to go up and down adding spaces in front of all the other = signs.

And I find it hard to read even in a monospaced font, e.g.

    var i                       = 123
    ,   j                       = 456
    ,   k                       = 789
    ,   aMuchLongerVariableName = 'foo';
Matching up the initializer values for i, j, and k means my eye has to scan way across a sea of whitespace and hopefully remember which line is which when I get there.

Finally, the example with the escaped newlines all in a vertical column does not do at all what he expects! All those extra spaces become part of the string.

Re: Writing Eloquent JavaScript Without CoffeeScript

#38

Post by danso »

fogus wrote: post #31
jashkenas wrote: post #13

Just to clear one thing up -- Oscar writes: > The examples on the CoffeeScript site are purposely written > to be ugly to make CoffeeScript look even prettier. ... not at all. The side-by-side examples on CoffeeScript.org are showing you the compiled output . The point is to demonstrate -- although it's certainly far from perfect -- how CoffeeScript features can be compiled into clean JavaScript. Really, our goal is…

This kind of clarification is exactly why I posted this link. It's great to clear the air in one respect and at the same time ask the question, "is there something on the CS site needing change to avoid this confusion?"

I don't know how Jeremy could make it any clearer. It says:

CoffeeScript on the left, compiled JavaScript output on the right.

Maybe the two halves should have the headers directly aligned above them:

> CoffeeScript

> The JavaScript that it compiles to.

Other than that, it's hard to make it any clearer for its intended audience (people who know JS and know what the words "compiled" and "output" mean).

Still, I'm tempted to upvote the OP as good Friday satire.

Re: Writing Eloquent JavaScript Without CoffeeScript

#39

Post by ryankshaw »

mquander wrote: post #24

Oscar, when your code itself is making little frowny faces at you after you write it, something has gone wrong. x == 1 ? alert(x) :( alert('Error'), x = 1, alert('All Fixed!') );

lol, after reading the article I came back in here to call out that exact same chunk of code and the exact same sad face. I will agree, however for small things the ternary operator is prettier than the if...then...else... syntax

thing[conditional ? 'show' : 'hide']();

instead of:

thing[if conditional then 'show' else 'hide']()

Re: Writing Eloquent JavaScript Without CoffeeScript

#40

Post by oinksoft »

Stratoscope wrote: post #37

There are some real problems with these "eloquent" styles. They work only in a monospaced font. I code in a proportional font, and none of the column alignment tricks will look right when I view the code. Even if you like to code in a monospaced font, there's no reason to write code that becomes hard to read in a proportional font. It's very easy to write code that is perfectly readable in both monospaced and proport…

> I code in a proportional font, and none of the column alignment tricks will look right when I view the code.

That's really your problem. If you think people will stop aligning things in their code because you are in the tiny minority that use proportional fonts, you're crazy.

> Matching up the initializer values for i, j, and k means my eye has to scan way across a sea of whitespace and hopefully remember which line is which when I get there.

Nobody's actually going to do what you just showed in real code. Instead, it would look like this:

  var i = 123,
      j = 456,
      k = 789,
      aMuchLongerVariableName = 'foo';
And still look quite good.

> Finally, the example with the escaped newlines all in a vertical column does not do at all what he expects! All those extra spaces become part of the string.

Absolutely, but if you are putting HTML in that string (a while other discussion there) 99% of the time the whitespace will not matter. And for all the other cases, this is no different from multiline string behavior in Python and other languages.

Post reply on HN