Writing Eloquent JavaScript Without CoffeeScript

Just to clear one thing up -- Oscar writes:<p><pre><code> &#62; The examples on the CoffeeScript site are purposely written &#62; to be ugly to make CoffeeScript look even prettier. </code></pre> ... not at all. The side-by-side examples on CoffeeScript.org are showing you <i>the compiled output</i>. 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 to make the JS look as nice as possible.

I don't want to sound like an asshole and I'm saying nothing about the author, but in my personal experience I found lining up variables or =s was something I worried about when I first started programming.<p>Now my mind's eye just totally skips variable declaration when visually code parsing, variable declaration is meaningless drivel that exists only to stop typos (a good purpose).<p>I had an opinion on the layout of them back then because I wasn't a good enough programmer yet to have an opinion on anything else, I had opinions on things that didn't matter because those were the only things I actually understood well.<p>Also, again in my personal experience, it's much better to declare them just before you use them for future maintenance, having 4 or 5 declarations at the same time is something I do so rarely now. If you start faffing around laying them out, you're going to be tempted to put them all together.

As someone who writes JS every day, ignoring the fact that I think most of these paradigms are terribly ugly (though the comma placement is acceptable for cleaner diffs), I expected this post to be about actually getting things done eloquently without CoffeeScript. What I got was a blog post about how ternary operators can be written on multiple lines.

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

The bit on the comma operator may be used in many other places, and I've seen it result in quite elegant code, particularly in small function bodies. Its use in the ternary here may be questionable, but in any case a good JS dev should know when it is appropriate.<p>My only gripe is with placement of commas in object literals and variable declarations which has become so common over the past three or four years.<p><pre><code> var x = 1 , y = 2; </code></pre> or<p><pre><code> var x = 1 ,y = 2 </code></pre> or<p><pre><code> { k: 1 ,k2: 2 } </code></pre> Are terribly unsightly, and do not in any way benefit the maintainer. It's just now you have to worry about the first line rather than the last one.

It should be pointed out that "var a = a || someDefault;" can bite you when 0, "", or null are valid values for a. The empty string in particular can be surprising here at times.

<i>JavaScript can be pretty too and the examples on the CoffeeScript site are purposely written to be ugly to make CoffeeScript look even prettier.</i><p>I'm not sure how many times this will have to be clarified, but the JS code on the CoffeeScript site are not examples, but the compiled JS. Even so, it's in many cases prettier than Oscar Godson's "eloquent" JS, IMHO.

I really don't understand the point of the blog post.<p>So Javascript can be formatted to look kind of like CoffeeScript?<p>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...).<p>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)

He's got to be trolling. Multiline ternary operators aren't in my book better than an if block.<p>He also completely misses the point about javascript's global-by-default variables and how easy it is to introduce them with typos, properly building classes, etc.

This is satire, right? ... right? Please?

I guess from MPOV, "eloquent" formatting shouldn't change based on the size of the content... ie the difference between standard indenting and tab-aligning commas vertically. There's nothing eloquent about stepping through a dozen lines of code, tabbing each out, because a value was added that's a little longer than the rest..

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

Using the ternary operator is more "eloquent" than conditionals? That's true iff "eloquent" means terse in terms of number of characters, but I find if(...){} much more readable.

There are some real problems with these "eloquent" styles.<p>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.<p>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.<p>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.<p>And I find it hard to read even in a monospaced font, e.g.<p><pre><code> var i = 123 , j = 456 , k = 789 , aMuchLongerVariableName = 'foo'; </code></pre> 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.<p>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.

So it's not just me, then. IMO, writing `someThing ||= {}` is much more eloquent than `var someThing = someThing || {}`.<p>The first point he raises is a valid argument; CoffeeScript's intro does uglify the JS a <i>little</i> to make its point. But it doesn't take much.<p>&#62; <i>...merely inaccurate due to a lack of knowledge on JavaScript...</i><p>Kinda think the <i>opposite</i> idea was how CoffeeScript came into being, amirite? It was written to make JavaScript look AND act better. It wasn't developed by people that had no idea how to use JavaScript, and it certainly isn't used exclusively by people who don't know how to use JavaScript, too.

"CoffeeScript has been getting a lot of press and that's not a bad thing, but it's giving JavaScript a bad wrap.".replace(' wrap', ' rap')

I have to admit that I'm resisting CoffeeScript. It looks interesting but for me it seems like just an extra step for something that isn't bothering me. I'd rather write code that's a little more verbose than to have to "remote control" it via another syntax. Am I missing the boat?

Putting alerts in what should be a vaguely mathematical/functional construct seems very, very wrong.

most of that made me feel sick

The style decisions used in this article do not adhere that well to Crockford's style guide "JS: The Good Parts" and generally not that JSLint friendly.

I can't stand how people assert CoffeeScript looks good compared to JavaScript, as if it's some universally accepted opinion.

I'm not sure, but somehow he made some of those examples look less eloquent then their "ugly" counterpart.

This page shows no content on kindle webbrowser.