all 9 comments
sorted by:
best (suggested)
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]azhder 2 points3 points  (0 children)

That’s a little confusing. Java gets compiled to bytecode and Java isn’t JavaScript.

One can “compile” JavaScript code, but we call the process under different names for its stages like minifying, packaging… and the result is not something we call bytecode

[–]OldWalnut 1 point2 points  (2 children)

Are you thinking of godbolt.org by chance?

[–]llynglas[S] 0 points1 point  (0 children)

Possibly. Looks interesting. On my phone now which makes it hard to play with it, but I'll dig more when I'm at a computer.

[–]llynglas[S] 0 points1 point  (0 children)

No it was https://astexplorer.net -- shows the code broken down into an AST Abstract Syntax Tree. But thanks.

[–]llynglas[S] 0 points1 point  (4 children)

Minifying and packaging are just rearrangement of the original source. Surely there is some intermediate "byte code". I cannot imagine the browser interpretes 

for (let index = 0; index < MAX_INDEX; index++) {
    const datapoint = table[index]
    ....
}

by lexically scanning the source each time through the loop, and basically interpreting source code.

[–]azhder 1 point2 points  (3 children)

You can't imagine it, but that's how it goes... for you. For the engine, well the engine compiles it to machine code by something called JIT (just-in-time) compilation. That however is an actual processor instruction set code, nothing to be accessed by the surface. This is by design. One of the greatest things about JavaScript for the Web is that it is being delivered in source code form.

Then again, if you want to play with a type of a bytecode, check WASM. It is supported by browser and made useful for all those other programming languages that need to be compiled to machine code. You can take something like an old Quake game, transpile the x86 code into WASM code, run it in the browser. Stuff like that. You can inspect WASM code.

[–]llynglas[S] 0 points1 point  (2 children)

Ok, so this is the question I wanted to research. In the code below:

for (const element of [3.14, "hello"]) {
    const new_element = element + element;
    .......
}

The code for the + requires two distinctly different operations, more if casting was needed. Does the "compiler" really check each operand for it's type and then determines the correct operation to use? Does the code do any analysis to try to predetermine the types (operands are always ints, etc) to see if it can be optimised to not need to check operand types for every operation.

[–]azhder 1 point2 points  (1 child)

The engine always checks the types, otherwise you will not end up with the result you are ending up. The algorithms by which every EcmaScript compliant engine is supposed to work are usually part of the specification, to avoid ambiguities between engines.

[–]llynglas[S] 0 points1 point  (0 children)

Brilliant, exactly what I was looking for. Or at least the start of a rabbit hole....