So I have question I'm sure someone here is smart enough to answer- simply put, does ASI affect compilation speed?
In my head I would imagine that a compiler would expect to find semicolons as statement terminators but would have to reprocess a block if validation failed and try to figure out where the semicolons should be, and therefore ASI would slow down compilation (vs a file with all semicolons in place).
What implementations actually do in code is almost always very different from what the specification wording suggests. For example, in V8 the handling
of a line terminator used as a semicolon is practically the same had you used a semicolon as you can see here:
Furthermore, parsing source text initially into a representation that can be worked with is like 0.000001% of the total work to be done. And it is cached too.
Another example is in PHP where you can open and close <?php ?> tags as many times as you like and it will perform exactly the same compared to equal code
with single open and close tag. Especially if you use PHP opcode caching where the source text is not even used for subsequent requests.
Obviously it takes some extra cycles to perform ASI. Now, having said that I doubt any additional passes on the source are done to perform ASI. I suspect that if it is of any significance, they have folded it into another pass. And the code likely runs even if not all the semicolons are already in the right place, so it'd be a sunk cost in that regard.
Having said that, I'm, sure it's such a small amount of the compilation time to be pretty insignificant.
This is all however based on my professional experience writing parsers, and not on any specific knowledge of the workings of Javascript however.
Why would you expect that to be true in JavaScript any more than other semicolon-optional languages like Ruby and Python?
You just write your parser to accept both line endings (that meet certain conditions) and semicolons as statement terminators. Going through and literally inserting semicolons shouldn't be necessary.
Python is somewhat different, in that a newline is simply a statement separator. Semicolons aren't inserted, as far as I know, they're simply an alternate statement separator.
Python does make some exceptions, in that newlines within balanced paratheses and brackets are not treated as statement separators. But outside of that, this is what they mean.
As an example of the difference, consider the following JS:
if
(0)
statement()
This is legal JS. Now consider the roughly equivalent Python:
if
0:
statement()
This is not legal python, because the newline after the "if" terminated the statement, and a bare "if" is not a legal statement.
Another example. This is legal JS:
obj
.method()
As it is parsed as a single statement in JS. However, it is not legal Python, as the newline after "obj" definitively ends the statement, and ".method()" by itself is not a legal statement.
In short, Python can always say "this newline is the end of a statement", except for some very easy-to-detect cases. JavaScript, on the other hand, parses until it encounters an error, then goes back to insert the semicolon and tries again. This implies some additional overhead. I don't imagine it's a significant amount at all, but there is at least a good reason to think that this might apply to JS but not a language like Python.
My understanding (though I'm not an expert) is that the way the JavaScript spec is written, you first try to parse a line as is, and if you encounter a parsing error in trying to do that and the line doesn't have a semicolon, then you insert a semicolon and you try again. The end result is that it's a bit different then semicolons being optional; they are instead inserted automatically to try to recover from parse errors.
You mean "no, no one here is smart enough"? If it's "no" answer to semicolon insertion affecting compilation speed your post could use some explaining.
In my head I would imagine that a compiler would expect to find semicolons as statement terminators but would have to reprocess a block if validation failed and try to figure out where the semicolons should be, and therefore ASI would slow down compilation (vs a file with all semicolons in place).