Comment by Marco Alka on "Why do you HAVE to use semicolons in JavaScript?"

You don't have to, but there are edge-cases, which might cause trouble if not properly separated by a semicolon (even with newlines!). You could instead set up linting, like eslint, to know about such instances, and linting is always good for consistent code and standards, however just putting semicolons is way easier and you don't have to put wild semicolons in places ;)

One problem case is:

const foo = 42

[1,2,3].forEach(i => console.log(i))

What output do you expect? 1 2 3? Well, nope. You will get the following:

Uncaught TypeError: Cannot read property 'forEach' of undefined

Because even with the newlines, the JS VM will think that you wanted to access the field called 3 (because comma can also be used as an operator for execution separation, and will yield the result of the last operand, which is 3 in this case) on the number object 42 and call the function forEach on it, which is impossible, since there is no field called 3 on 42.

Basically, your JS VM reads above code like this:

const foo = 42[3].forEach(i => console.log(i))

Edit:

Imagine you do have an element with field 3 and above code does not throw, however your logic does not do what you want and you just sit there and think everything looks fine? Even if you debug the code line-by-line, you might wonder how tf the value suddenly changed in that strange way from one line to the next. Semicolons might be seen as tedious, however I think, in JS, they are necessary. Also, other languages require them always, so if you make it a habit to put semicolons, you will have an easier life with other languages, should you decide to learn one with semicolons (Java, Rust, C, C++, C#,...)

The trick is to use void whenever a line starts with an opening bracket:

void [1,2,3].forEach(i => console.log(i))

No semicolons required 😉.

Peter Scheler that's even more work than putting a semicolon before the affected line, though o_O

And you have to always remember and follow that additional rule, so I cannot see how it is better than just putting semicolons everywhere... I guarantee you that you will forget the separator from time to time, which might result in hard to debug errors. Forgetting a semicolon in JS is usually no problem and modern editors and IDEs will auto-highlight it for you. However the problem of the missing separator in the above example usually is not highlighted, because it might be valid, wanted code.

Sorry, it wasn't addressed to you. It's simply a question of personal style and I only want to show that one can be consistent with a "no semicolons" rule.

This would have worked too:

const foo = 42
for (const i of [1,2,3]) {
  console.log(i)
}

fvsch your code would have introduced direct complexity (a loop vs "just" a function call in my code) and performed worse (my loop runs on hardware, yours runs in the VM). Also, the whole point was to make an example of a problem case ;)

Marco Alka I’m not sure I follow because I don’t know what “direct complexity” means and I’m not sure what you mean by running on hardware vs running in the VM (does this refer to JIT optimizations, e.g. the JS engine estimating that a given function is “hot” — aka is called a sufficient number of times — and then investing some CPU time to compile it for faster execution on the next executions?)

I looked at some benchmarks; sadly right now jsperf is down, and I ran a few tests on jsbench but I’m not sure they’re reliable (an empty code block had worse performance than the winning option ^^). This article refers to a jsperf test which shows most methods in the same ballpark, which looks like what I’ve seen with recent Chrome, while Firefox still shows different results. Overall I would not obsess about this, but perhaps be more concerned about transpiling (Babel’s transpilation of for...of is known to be slow).

fvsch

I don’t know what “direct complexity” means

It's the code complexity in your part of the code. A call to a function or method is cheaper ( O(1) ) than a loop ( O(n) ). While this is over-simplified, because that method might contain a loop, my second argument comes into play:

I’m not sure what you mean by running on hardware vs running in the VM

Running on hardware means just that the method I call on the array is hard-coded. It is most probably written in C++ and compiled to machine code, no need for any JS techniques at all. That makes it very performant, a lot more than JS, which is always run in the JS VM, can ever be. Hence, even if the method contains a loop itself, that loop is more performant than a loop in JS code.

With benchmarks, you always have the problem, that different vendors have different implementations in different browser versions. They might even implement the method in JS (as NodeJS does with most of its API), however I think that these new methods have a lot of potential, especially in the future, to be optimized by browser vendors (for example using SIMD), resulting in superior performance compared to whatever you can come up with inside the VM.

One indicator of the above is, that jsBench gives me a very clear result on Chrome 64 (Win10 x64). a for..of loop is ca. 50 ops/sec, and a reduce() is ca. 61 ops/sec. I wouldn't call that being in the same ballpark.

Search Hashnode