I'm sure this is opening a can of worms but the [style guide] seems a little dated and I'd like to suggest 2 changes
prefer const and let to var?
I don't know why var is preferred (was told to change to var in a recent PR). My guess is because that's where it started and because const and let are new. But now that code base is using ES5 modules it seems like any reason for keeping var is long gone. Because of the import lines, for code to work on browsers that only support var the code has to be run through a transpiler. That same transpiler is/will already convert const and let to var.
Further, there are concrete objective positives to using const and let over var. Both are scoped to braces instead of function scope. Neither create global variables unlike var. Sure, much of the code uses var now (although IIRC eslint can auto fix that). Changing the linter to require const and let and slowly changing legacy code over will prevent more errors and leaks. Also with const and let used everywhere it's possible the enable eslint checking for more undefined variables which at least for me as been a huge help.
There was a time when var was faster but that time is long gone.
Is it time to stop using var?
allow trailing commas in multiline arrays and objects
This might be a personal preference by Mr. Doob but my guess is more that it's left over from IE days. IE didn't support a trailing comma but now that transpiling is happening the trailing commas get removed by the transpiler for IE compatibility. For devs trailing commas are a win as they lead to less errors. Errors that are usually caught but errors that often require at least one iteration to catch, running in the browser and seeing the syntax error then going back and editing commas. At least in my experience trailing commas avoid that issue.
By trailing commas in multiline arrays and objects I mean for example
const sizes = [
100,
200,
300,
];
and
const options = {
width: 100,
height: 200,
depth: 300,
};
With trailing commas adding or removing lines requires only dealing with a single line. With trailing commas it means always having to be aware the last comma is and removing it or adding it.
Of course whatever is decided is fine, I'll follow the guide for PRs. I just thought I'd ask as the code switched to ES5 modules if it was time to revisit some of the style guide (note the var part is not actually in the style guide.)
greggman
All 16 comments
There was a time when var was faster but that time is long gone.
What are you basing this on? IIRC the last time we tested this, there was no difference for const but let was somewhat slower. It would be good to see some updated tests on this.
allow trailing commas in multiline arrays and objects
Definitely agree with this change, if there are no issues with IE (we still do want to support at least IE 10 and 11 right?).
looeee
on 19 Jul 2018
There was a time when var was faster but that time is long gone.
What are you basing this on? IIRC the last time we tested this, there was no difference for
constbutletwas somewhat slower. It would be good to see some updated tests on this.
Yeah, some numbers would help on this decision.
allow trailing commas in multiline arrays and objects
By trailing commas in multiline arrays and objects I mean for example
const sizes = [ 100, 200, 300, ];
My brain reads that like this:
const sizes = [
100,
200,
300, undefined
];
JS interpreters remove that comma these days?
mrdoob
on 19 Jul 2018
I personally do not vote to allow trailing commas in multiline arrays since I find it unusual to read, too.
Mugen87
on 19 Jul 2018
For me the purpose of trailing commas is that it makes it quicker to add and remove things, as well as reorder them by cut / paste. No need to worry if you just cut the last item or not, every line is the same. As for seeing undefined, it's easy to avoid that if you know there's just one item per line - and in cases where the array is on one line like [1, 2, 3, 4, 5] you would not add a trailing comma.
On the other hand, I don't think it matters either way. The switch to const / let is the important issue here.
looeee
on 19 Jul 2018
... but now that transpiling is happening ...
We're not transpiling, are we? Rollup just replaces ES6 import/export syntax while leaving everything else alone, unless you add plugins like rollup-plugin-buble. But let/const are supported in IE11 anyway.
donmccurdy
on 19 Jul 2018
The trailing commas also serve a much larger purpose than just "ease of use". In larger projects where lots of people contribute to, it's useful to use things like git blame to find out who's responsible for what piece of code.
So, stating the obvious here: If there are things listed on multiple lines that were added by @mrdoob, and I would later add a line there, my name would be shown on the last line of code that I didn't write.
I'm personally against the use of trailing commas for the exact same reason as the people stated before me, but I do see the benefits and I am getting used to it now that we also enforce this in the office since this year.
JS interpreters remove that comma these days?
Yep.
Regarding the use of let vs var:
The difference between let and var doesn't matter anymore these days if it comes down to performance. V8 and Spidermonkey (Firefox) have great optimizations these days that work really well.
See this post for an elaboration (make sure to run the actual snippets to see that the difference is pretty much neglectable now): https://stackoverflow.com/questions/37792934/why-is-let-slower-than-var-in-a-for-loop-in-nodejs
The accepted answer of that SO-question also points out the differences between var and let from a functional perspective, since they both have _very_ different meanings and use-cases in case that isn't clear to anyone.
The use of const for variables that never change is a no-brainer. If the javascript engine can see that a variable is declared with const, it knows that its value will never change again, so it can be heavily optimized.
Just my 2 cents.
For reference:
haroldiedema
on 19 Jul 2018
The trailing commas is one of the best js patterns i've seen and makes diffs much more legible.
pailhead
on 19 Jul 2018
JS interpreters remove that comma these days?
All browsers have been fine with that comma in arrays and objects for > 10yrs except IE
Let me add rather than looking at it as strange thing another POV is that the syntax is actually the comma is required it's just browser gives you a break and doesn't require the last one. One person's strange is another person's beautify. I find the consistency of every line being the same more personally pleasing than the last line being different. Of course those are personal preferences I'm just bringing them up another way to look at things.
as for diffs I found these comparisons online
no trailing comma diff adding a line
trailing comma diff adding a line
greggman
on 26 Jul 2018
Lets start with the let and const first. One step at a time.
mrdoob
on 31 Jul 2018
I think those timings to too close to call. I get different results
greggman
on 31 Jul 2018
Although in Chrome 70 they aren't remotely close
greggman
on 31 Jul 2018
while we're at it
greggman
on 31 Jul 2018
Let me add one more POV for trailing commas 😜 You can see trailing commas as similar to semi-colon
This is perfectly legal code
{
doThis();
doThat();
doOther()
}
The last line missing the semi-colon. One POV is to see comma as the same thing. Maybe it's like the people/lamp illusion.
Whether you see 2 people or a lamp stick both are valid. But in that case, with comma since both POVs fit ("comma on end looks like , undefined" vs "comma missing looks inconsistent") one has objective benefits and the other doesn't so ...?
greggman
on 31 Jul 2018
I tried adding a const somewhere in the code and it doesn't compile anymore...
mrdoob
on 31 Jul 2018
@mrdoob The output format should be set to ES6 instead of ES or ES5.
haroldiedema
on 31 Jul 2018
Closing in favor of #6419.
Mugen87
on 10 Mar 2020
Related issues
yqrashawn
·
3Comments
makc
·
3Comments
Horray
·
3Comments
akshaysrin
·
3Comments
donmccurdy
·
3Comments
Most helpful comment
All browsers have been fine with that comma in arrays and objects for > 10yrs except IE
Let me add rather than looking at it as strange thing another POV is that the syntax is actually the comma is required it's just browser gives you a break and doesn't require the last one. One person's strange is another person's beautify. I find the consistency of every line being the same more personally pleasing than the last line being different. Of course those are personal preferences I'm just bringing them up another way to look at things.
as for diffs I found these comparisons online
no trailing comma diff adding a line
trailing comma diff adding a line