Is JavaScript translated from source code to machine code with a JIT compiler or an interpreter? Or does it depend on the browser and the JavaScript engine you are running?
Javascript is an interpreted language.It is directly interpreted by browsers for execution.
But,modern browsers support JIT compilation which converts it to bytecodes for high performance.
JavaScript is scripting language and browser is executing scripts which are in text format. So by definition that makes JavaScript interpreted language.
Compiled languages are those which are executed from binary files.
JIT compilation is just something that JavaScript engines can do as way of optimization, but you never truly generate binary JS files, so language is interpreted one.
Related
so my question is does the Bytecode interpreter of Ignition convert the bytecode that was created by the bytecode-generator to machine code and execute it line by line?
because from what I've seen I don't see any sign that the bytecode interpreter actually converting the code to machine code.
it seems more like the bytecode generator generates bytecodes
and the interpreter just execute it in C++(the interpreter doesn't turn the bytecode to machine code and then execute it)
(V8 developer here.)
Correct, the key concept of an interpreter is that it executes the bytecode directly. It does not generate machine code. We use the term "compiler" for things that (don't interpret but instead) generate machine code.
As far as I understood, JavaScript cannot be compiled ahead of time because of it's dynamic nature. So Interpretation and just in time compilation happens at run time, that affects JavaScript performance. So WebAssembly comes into picture. Languages can be compiled ahead of time into intermediate format (WASM). This gives good performance since there is less runtime overhead.
My question is why JVM cannot be used in place of WebAssembly VM. Java compiled into intermediate format (bytecode). This byte code can be given to browser and JVM can execute it. JVM also supports JIT which helps to achieve near native performance.
So what is the need for new WebAssembly. Why can't JVM be integrated into browser and achieve high performance by leveraging the existing most popular Java language.
There are a great many reasons why the JVM was not deemed a suitable runtime in place of WebAssembly ...
WebAssembly was designed with delivery-over-HTTP and browser-based in mind. For that reason, it supports streaming compilation - i.e. you can start compiling the code while downloading.
WebAssembly was designed to have rapid compilation times (resulting in web pages that load quickly), this is supported by having very simple validation rules compared to Java / JVM languages.
WebAssembly was designed with the concept of a 'host' environment, i.e. the browser.
WebAssembly was designed to be secure and simple, minimising the overall attack surface.
WebAssembly was designed to support a great many languages (C, C++, Rust, ...), whereas the JVM was initially design for a single language, Java.
As a general observation, WebAssembly was designed to support multiple languages on the web. The JVM was designed to support Java on the desktop. It doesn't make either one better than the other in a more general sense.
Finally, the JVM was integrated with the browser (Java Applets), but that didn't work out in the end!
A quote from the High-Level Goals of WebAssembly:
a Minimum Viable Product (MVP) for the standard with roughly the same functionality as asm.js, primarily aimed at C/C++;
So their original goal was running C/C++ program in a web browser, not running Java code.
JVM can run:
JavaScript
Python (Jython)
Ruby (JRuby)
Groovy
Scala
C++ (using JNI)
unfortunately the support for java was removed from the browser, because Sun (former maintainer of java), could not provide adequate support.
Just like the Flash ended up losing.
Is JavaScript running on top of web browser?
Like Java running on top of JVM?
Or Does it actually compiled to binary code and run on machine?
V8 (in Google Chrome) contains a JS interpreter and a JIT (Just-in-time) compiler. JS code is converted to V8-specific bytecode. The bytecode is initially interpreted by the interpreter, called "Ignition". When a function becomes "hot" (it is run a lot), the TurboFan JIT compiler produces optimized machine code from the bytecode.
Other modern JS engines use similar strategies. So JS can be interpreted or compiled to machine code (using a JIT compiler), similar to how JVMs work, yes.
Javascript isn't truly compiled - it's interpreted on the browser, so yes it effectively "runs on top of the browser" on the client side.
EDIT: I should've started by saying at it's base level. As is mentioned on a comment to this, there are more complex engines now.
It has to -- nothing can run on a computer without being the appropriate machine code for the processor.
V8 converts the JavaScript to its own byte code, then is heavily optimized and converted into machine code.
Even the JVM does something similar. The JVM converts the Java byte code into machine code.
Does the V8 engine that is used in Chrome and Node.js compile the entire code to machine language once or it compiles the next context to be executed every time for each context that is added to the call stack ?
V8 will likely compile some of your code to machine language and likely not compile all of it to machine language.
The exact representation for any piece of code depends on many factors, including the ever-changing optimization behaviors in the library. None of it is guaranteed and shouldn't be treated as such, even if it behaves a certain way right now.
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.
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:
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.
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?
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.
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.