Regarding JavaScript trailing commas
dontkry.com
dontkry.com
Perhaps I'm just a lazy bastard, but it makes cut & paste a lot easier.
I'd love to start using trailing commas in JS, but I've definitely had syntax error problems and unparsable JSON from them existing in recent memory.
Trailing commas are certainly in that category. When I started getting into JS seriously in 2007, this wasn't a nitpick: your code would be outright broken in IE6 if you had a trailing comma, and would fail with a syntax error. This was a leading cause of IE bugs, since developers often developed in Chrome or Firefox (which handled them fine) and it was ridiculously difficult to trace it down.
Ditto a lot of other conventions. It was common to use innerHTML instead of DOM manipulation because IE was ridiculously slow at DOM manipulation (React just fixed this in their codebase this week). It was common practice to wrap every file in a closure because all your variables would pollute the global scope - now we have CommonJS modules and bundlers to handle this. It was common to avoid closures in favor of prototypes & _ naming conventions because Firebug & Chrome Devtools couldn't inspect variables in closures.
All of these are terribly obsolete now, and there's no reason to adopt them on a new green-field project. But the point of coding conventions is uniformity with existing code, so if you're inheriting a codebase that was written when these were actually important, it's often good to conform just for consistency's sake.
Languages change over time.
For a related idea, see Facebook's Haskell system, in which only type-safe code is allowed to be checked into the respository:
https://code.facebook.com/posts/745068642270222/fighting-spa...
Not sure if there are any other interpreter inconsistencies.
If you use babel, you can write your source with trailing commas, then let the build step remove them for older browsers.
nineties {
dude: true
awesome: true
rad: true
}But yeah, all of this stuff just makes me more convinced that Lisp syntax is the best ever.
In the Scheme backquote (dubbed quasiquote), the spec says that the read syntax ,X produces (unquote X). You can omit the comma, and then you just have X.
This is totally different from a comma which just punctuates syntax.
For example one can write a vector of three elements, where the second element is computed:
`#(1 ,(first *features*) b)
"Macros took a major step forward with Lisp-Machine Lisp, which consolidated the various macro-defining techniques into two standardized features that were adopted throughout the MacLisp community and eventually into Common Lisp. The macro defining operator DEFMACRO provided list-structure destructuring to arbitrary depth; the backquote feature provided a convenient and concise pseudo-quoting facility. [ ... ] Backquote and DEFMACRO made a big difference. This leap in expressive power, made available in a standard form, began a new surge of language extension [...]" [3.3]
In a compiled language you catch this because it's a syntax error. In JavaScript, it might be missed through every code review (because it's subtle) and and then break on release to you production system.
So it's not just style, it can help reduce bugs.
>The reason you were once told trailing commas are bad is because they are invalid in EcmaScript 3.
I can imagine plenty of reasons people would have for avoiding trailing commas even after they became valid syntax.
The whole "consistency" section also feels like unnecessary snark.
Could you list a few?
{ one = 1
, two = 2
, three = 3
}
It is marginally more difficult than leaving in trailing commas, but way better than adding missing unaligned commas at EOL.
I was initially surprised by this but now knowing that the creator comes from a Haskell background, it makes sense that he would prefer it.
Adding items to the end of a list, tuples to a dictionary, arguments to a function etc... is more common then adding them to the start.
empty
|> ("one" , 1)
|> ("two" , 2)
|> ("three", 3)
After a while I got used to them and I like the copy-paste-ability the enable... I'm also hoping they put an end to leading-comma style,
I happen to agree with the position that syntax that can be made implicit should be. CoffeeScript has done a good job of this. LiveScript has done an even better one. What are the arguments against using a syntactically cleaner language that compiles down to the exact same features?
I find Coffeescript hard to read. Especially when dealing with nested callbacks (e.x.: when you have to nest, such as with Jasmine `describe` and `it` blocks for testing).
Here's an interesting thread on the "cons" of using Coffeescript: https://news.ycombinator.com/item?id=6527316
I do like ES6!
I'm a big JS fan. I can't stand Coffeescript - it doesn't seem to add anything except changing the syntax to make it easier for Rubyists to understand. Which is fine, I guess, but feels like a personal preference. More like a text editor setting than something anyone should publish their code in.
Same for Typescript, to a certain extent, though I understand the heartfelt desire to have the compiler pick up some of the more common errors.
We run the risk of fragmenting the community by promoting CS and TS - better to evolve JS itself, which is what is happening and it's great.
TL;DR: kill Coffeescript and Typescript, evolve Javascript for the win!
And that language shouldn't be used by beginners in 2016 due to its uncertain fate in the long run as its creator kind of abandoned the project. Furhtermore ES2015 adds many CS features to the language.
Don't know about LiveScript, but frankly that whole transpilation thing is a mess. People don't use Transpilers for Python or Ruby. They work with the language quirks.
Unfortunately, many of the ES6 features inspired by CoffeeScript features are completely unoptimized and an order of magnitude slower in cutting-edge browsers than the CoffeeScript versions. Even more unfortunately, they don’t work at all in lots of browser versions people are still using today. Which means that they can’t really be adopted by most projects yet.
Finally, even if ES6 were implemented perfectly everywhere, it’s still much less pleasant (from a syntax clarity perspective) to read and write ES6 code than CoffeeScript code, at least for me.
At the point when the vast majority of browsers support ES6 features, it will perhaps be reasonable to change CoffeeScript to use them in its generated output. In the mean time, CS is fantastic as-is, and its generated code works efficiently in every browser.
But hey, use whatever language you like (ClojureScript, Elm, Dart, Haxe, ES6, whatever..). It’s your code, so the only people who should care are you and your close collaborators.