5

So I am asking does each web browser have there own compiler example IE compiles Javascript from a website and generates sequence A of byte code .

On the other hand, google chrome compiles the same Javascript from the same website and generates sequence B .

I am wondering this because if that is the case would it be beneficial to run the compiler on the Javascript and upload the generated byte code to the website rather than the Javascript itself. And send different byte code based on each browser.

Or are there some other limitations.

Talha Awan
  • 4,573
  • 4
  • 25
  • 40
nader
  • 141
  • 2
  • 13
  • 3
    Browsers don't compile JavaScript; they interpret it. – ProgramFOX May 01 '15 at 17:24
  • 5
    @ProgramFOX in the old days this was true, nowadays they also compile to byte code – torox May 01 '15 at 17:25
  • There are different script engines, yes: http://en.wikipedia.org/wiki/List_of_ECMAScript_engines But I'm not sure what you're proposing as a solution would be an option. – David May 01 '15 at 17:28
  • @David thanks . I was wondering about that . I know it could be beneficial in some scenarios . So I am just trying to get more educated on web browser and website code interactions . Thanks torox too. – nader May 01 '15 at 17:30
  • 1
    the compilation step takes but a millisecond or two anyway (parsing takes longer) so you wouldn't be saving much, and you would potentially have a lot more code to ship to the client. stick with sharing source. – dandavis May 01 '15 at 18:36
  • That's true @dandavis, when the code gets large enough, the parsing may take some time. Mozilla is doing some efforts on that and is working on [a solution that involves compressing Asm.js code and shipping it with a small interpreter](https://blog.mozilla.org/research/2015/02/23/the-emterpreter-run-code-before-it-can-be-parsed/). However, I think that this solution only make sense if you also improve the code performance, and that's what Asm.js and some other proposals are trying to do, as I pointed out in my answer. – Danziger May 01 '15 at 19:21

4 Answers4

5

As others have pointed out, there are different ECMAScript engines and some of them use a JIT (Just-In-Time) compiler while some others use runtime interpreters, being the former the preferred option for most browsers nowadays as it gives some performance benefits over the latter option.

You can see another question about this on: https://softwareengineering.stackexchange.com/questions/138521/is-javascript-interpreted-by-design

For example, V8 is the JavaScript engine used in Google Chrome, node.js and can also be embedded into C++ applications.

About your idea of sending compiled or precompiled code to the client instead of the raw JS, there are some projects working on something similar:

Asm.js consists of a strict subset of JavaScript, into which code written in statically-typed languages with manual memory management (such as C) is translated by a source-to-source compiler such as Emscripten (based on LLVM). Performance is improved by limiting language features to those amenable to ahead-of-time optimization and other performance improvements.

The important fact about Asm.js is that existing JavaScript engines do work quite well with its style of code, so you can start using it right now! But the code it produces is still (a subset of) the JS we know but written in some way that helps JS engines to run it faster:

Asm.js Compilation and Execution Pipeline

Of course, there are also a lot of restrictions about what you can do with it, as it is mainly oriented to work with just numbers. See http://ejohn.org/blog/asmjs-javascript-compile-target/

Real support for Asm.js is still a limitation, so you can't use things like "use asm" and although you can run Asm.js code on today browsers and get some performance improvements, it won't be as good as it could be in browsers that could optimize Asm.js code. However, we may start having that and some other improvements in the (hope that near) future. See https://blog.mozilla.org/research/2015/02/23/the-emterpreter-run-code-before-it-can-be-parsed/

Meanwhile, and for a more general purpose JS that needs to work with more than just numbers, you can use Google Closure Compiler. I would recommend that you take a look at the FAQ first, and then you could start playing with it in the online tool.

Community
  • 1
  • 1
Danziger
  • 19,628
  • 4
  • 53
  • 83
1

There are several JavaScript (or rather ECMAScript) implementations in wide use, and while in theory there are standards, most widely used one being ES5 (ECMAScript 5) - yes, not everything in all browsers is properly, consistently implemented (I'm looking at you, old IE).

Here's nice compatibility table for ES5 (the one you're writing in today): http://kangax.github.io/compat-table/es5/

And here's same thing for shiny-new ES6: http://kangax.github.io/compat-table/es6/

Note the disclaimer at the top of these tables:

Please note that some of these tests represent existence, not functionality or full conformance.

Also, on the issue of whether JavaScript is compiled or interpreted language: it is definitely interpreted language - at least originally. But most common JavaScript engines in use today implement JIT (Just-In-Time compiler), translating much of JavaScript to byte or machine code before executing it (ergo - compiling).

Most widely used (and most performant as well) of these engines is V8, used by WebKit (and therefore present in Chrome, Safari, Opera, ... - Node.JS is using it as well). Read more about V8 and its JIT implementation: How the V8 engine works?

bardzusny
  • 3,788
  • 7
  • 30
  • 30
  • @dandavis, kudos for pointing that out. From the article I linked to ("How the V8 engine works?"): "The main difference with V8 is that it doesn’t produce bytecode or any intermediate code.". But there are other engines as well. I edited my answer to account for that. – bardzusny May 01 '15 at 20:22
1

Yes, each browser has its own implementation of an ECMAScript engine, most commonly implementing/supporting ECMA-262, commonly known as JavaScript. While there are several large related families of browser engines such as Webkit, each engine further can have its own JavaScript engine. For example, as many have pointed out, Google use the V8 engine. Because these engines each do things a little differently, there is no one set of code that is promised to be deterministic across them, the way say Java code will run the same on any machine that supports the JVM.

Inherently, JavaScript is not compiled like a traditional language such a Java or C/C++. This is why, without the help of a 3rd party program, you cannot find non-syntax errors in your JavaScript code until that code runs. ECMAScript is an interpreted language.

Now, this is the tricky part. Most modern JavaScript engines do in fact compile JavaScript, often to another language (also known as Source-to-Source compiling or transpiling) such as C, to perform performance optimizations on it. Of course, at some point, all code gets compiled into byte code.

Your best bet for writing JavaScript that will work on all major browsers is to use core/standard features. For example, this means passing timestamp string in the form of "yyyy/mm/dd" instead of "yyy-mm-dd" when using new Date() since Firefox does not support the latter format - the Chrome developers simply added it to be nice to you. IE is notorious for handling certain non-standard features differently. I'm a big fan of http://caniuse.com/ to help with this.

Matthew Herbst
  • 29,477
  • 23
  • 85
  • 128
  • no. js is compiled. we're not using IE6 anymore. get a dump from V8 if you don't believe me. – dandavis May 01 '15 at 18:34
  • 1
    @dandavis That is simply Google's implementation and way of doing things to make things better. JS is not compiled. If it was compiled, you would be able to detect most of the most common errors before even running your code. If it was compiled, I would, as the OP thinks about, be able to upload my compiled JS to my webpage. Now, of course, every language gets compiled into byte code eventually. JS is most certainly an interpreted language. That is why errors don't occur until run-time. – Matthew Herbst May 01 '15 at 18:58
  • 2
    I'm tempted to say you're both right. JavaScript is interpreted at runtime, but so are Java, C#, and anything that's not native code. With those latter two, it creates a bytecode that's still not native, but is easy to do a full compile on. Minified JavaScript files are not the same thing, but serve the same purpose. Yet, that doesn't really mean those languages are not compiled just before execution; all browsers compile JavaScript nowadays before they run it. – Katana314 May 01 '15 at 19:24
  • I agree, maybe @MatthewHerbst's answer needs clarification but they are both righ in some way. However, you could use some IDEs like [JetBranins WebStorm](https://www.jetbrains.com/webstorm/features/) to help you detect errors before runtime – Danziger May 01 '15 at 19:58
  • @MatthewHerbst: it's not just V8 that compiles JS. consider chakra: "A distinctive feature of the engine is that it JIT compiles scripts on a separate CPU core". many errors are found at compile time, they are called syntax errors, and they prevent parsing. the main diff with java is that all inputs/paths are not known at compile time, so you can't detect as many early errors as you would in a sealed system, but that doesn't mean it's not compiled. http://en.wikipedia.org/wiki/Just-in-time_compilation has good info. it's different that pre-compilation, but it's still compilation... – dandavis May 01 '15 at 20:16
  • 1
    to be fair, chakra interprets during load, while the code is compiling, then seamlessly switches to the compiled code as soon as it's ready. also, some things are still interpreted, like eval code on an un-optimized branch of code. but most js is run in a compiled state. confusing? you betcha... – dandavis May 01 '15 at 20:24
0

Nowadays most javascript engines are JIT compilers. More here: What does a just-in-time (JIT) compiler do?

So yes, javascript is compiled (not interpreted), and most major browsers do it differently.

Community
  • 1
  • 1
Wes Pearce
  • 259
  • 1
  • 4