Instead of having V8 pile JavaScript on the fly and then execute it, isn't it possible to just pile the JavaScript beforehand and then embed the machine code in the page instead of embedding JavaScript in the page?

Instead of having V8 pile JavaScript on the fly and then execute it, isn't it possible to just pile the JavaScript beforehand and then embed the machine code in the page instead of embedding JavaScript in the page?

• javascript
• google-chrome
• v8
• javascript-engine

• 2 en.wikipedia/wiki/Asm.js – epascarello Commented Apr 22, 2015 at 18:45
• asm will still mean multiple pilations though right? – Hello Commented Apr 22, 2015 at 18:51
• 1 Won't any such machine code be architecture-dependent? It seems like a feature with minimal benefit if I need to include a piled version for each architecture I wish to support (and then including a plain JavaScript version for other browsers that may not support machine code at all). – apsillers Commented Apr 22, 2015 at 19:12
• Not all of javascript can be piled to machine code. Some things, like eval for example, means that you also need to pile a javascript piler into either the browser or the piled code. If you need a javascript piler anyway, why not just use it. – slebetman Commented Apr 22, 2015 at 19:13
• The way I understand it, the V8 JavaScript engine piles to machine code anyway so why not just do it beforehand? – Hello Commented Apr 22, 2015 at 19:22

2 Answers 2

There are two main problems with shipping machine code on the web:

1. Portability. No server can afford providing appropriate machine code for all possible system architectures out there (present and future). E.g., V8 already supports 10 different CPU architectures.
2. Security. No client can afford to run random machine code on their machine without knowing if it can be trusted.

To address (1) you'd generally need to cross-pile machine code, which is more difficult and costly than piling down from a high-level language. To address (2), you'd need to validate the machine code you receive, which is more difficult and costly than piling a high-level language.

Machine code also tends to be much larger than high-level code, so there is a bandwidth issue as well.

Now, JavaScript may not be a particularly great choice of high-level language. But it is what we are stuck with as the language of the web.

The way I understand it, the V8 JavaScript engine piles to machine code anyway so why not just do it beforehand?

According to the W3C HTML5 Scripting specification, there's no standards-based reason why a browser couldn't support machine code with special type attributes (as Chrome does with the Dart language):

The following lists the MIME type strings that user agents must recognize, and the languages to which they refer:

"application/ecmascript"
"application/javascript"
...

User agents may support other MIME types for other languages...

Currently, no browser has implemented such a feature.

I suspect the primary shorting of such an approach is that each chip architecture would require a machine-code version of the script piled for it specifically. This means that in order to support three architectures, a page would need to include a piled script three times. (And it should be included a fourth time, as plain JavaScript, as a fallback for architectures that you didn't include, or for browsers that can't/don't support piled code.) This could significantly bloat the size of the page with data that is mostly useless. The increase in load time would seem to significantly offset or pletely outweigh whatever time you save on pilation.

An architecture-independent promise solution like bytecode seems pretty poor: you still need to include the script twice (once for the bytecode, once normally for scripts that don't support it) and you need to do some kind of run-time processing on the bytecode to turn it into machine code.

The multiple-includes-with-fallback problem is exactly why other scripting languages have not made it into the Web environment: they would need coordinated cross-vendor support to be useful. Google is trying with Dart, but it remain to be seen what degree of success they see.

Note that Chrome does cache piled versions of scripts so a script only needs to be piled once and then the piled code is cached for reuse when the user re-visits the page.