How can I understand what engine is being used while JavaScript is executing?
e.g., v8 or spidermonkey or nashhorn
JavaScript engines (and their versions) are closely linked to browser (versions).
So simply use browser detection, and map it to the JS engine with a table. Many browsers even hold the engine build in their UA string.
Or better: Don't do it, for the very same reason. There's hardly a use case where you need to know the JS engine, apart from browser test suites (in which you just can ask the user). For anything else, you should use feature detection. Different engines differ in different ways from the ES spec, and you can test on these subtleties.
Related
It is possible to change the JavaScript engine being used inside a Web Browser?
Some additional information:
For testing mobile applications, I would like to be able to emulate the exact JavaScript engine being used by a web browser to find bugs.
If there anyway to change the javascript engine being used in a Browser such as Chrome or would I need to build my own browser?
This is an interesting feature. I'd like to test Safari Javascriptcore engine in Chrome browser instead of V8. Because I noticed that some of my angular code is not rendered correcty on JavascriptCore engine and rendered correctly on other browsers. It'll be in handy when you found some bugs on ios devices and you have no mac device nearby.
UPD
I found browsers where you can change browser engine lunascape and avant. these browsers are triple engine browsers and you can switch between engines.
There are a number of open source browsers. It is theoretically possible to replace the JavaScript engines they use and compile your own executable. Indeed a number of browsers have changed engines during their history.
You'll probably need to make changes to the API to make them compatible though.
There's no way to do this from JavaScript, of course.
Generally, a given browser ships with a single JavaScript engine. There is no need to ship with multiple engines, because if additional features are required of the engine, they'll simply be added to the engine which the browser ships with.
I could potentially see the existence of a modular web browser which requires plugging in a JS engine separate from the main program (which could then result in the user having multiple JS engines on their machine), but I know of no such browser, and thus know of no means by which JS could be used to swap the engine.
I suppose you could implement EMCAScript in JavaScript, but that seems like a tremendous hassle.
In response to the edits to your question: I believe Chrome Dev Tools' mobile emulation will get you what you want instead of what you've asked for.
I wanted to ask a few questions about javascript:
1.Does each browser implement javascript by itself ? Or is their a common SDK\API or whatever ?
2.If each browser implement by itself, Is the javascript engine bounded to the browser version ?
I mean, can I have 2 different engines for the same browser version ?
3.Is there any standards all javascript engines must follow ? Does this standard define memory
allocation ? (Lets say, How I allocate a javascript string ?)
And last,
What are the names of implementation for each browser ? For example I understood FirFox uses an
implementation called "Rhino", Am I right ?
Thanks alot !
Michael
Yes, they implement JavaScript on they're own.
Yes, it is bound to the browser version. No, you can't have 2 different engines for the same browser version. You can though for different browser versions.
Yes, it is called EcmaScript. Most implementation follow it pretty good.
FireFox does not use Rhino. Mozilla developed it, but the implementation in FireFox is different. All browsers implement single-threaded JavaScript, while Rhino is not single-threaded.
Each browser does implement its own version of JS. Thus, why some browsers outperform others. They specification on what JS should do and how it should be done is based on the ECMAScript specification. The only case I've seen of having multiple engines (or versions of engines) is with IE's web dev toolbar, where you can "roll back" your IE version to test how previous versions react. I've found the JS engine to be pretty faithful when doing browser version tests.
Wiki has a nice write up on the different engines. http://en.wikipedia.org/wiki/JavaScript_engine#Mozilla
JavaScript is standardized through the ECMAScript specification which most browsers will adhere to.
However, not all features are implemented across all browsers and browser versions and some features have their own browser specific quirks.
You can find more details about ECMAScript and the versions browsers implement here:-
http://en.wikipedia.org/wiki/ECMAScript
You will not get two different JavaScript engines offered to you within the same browser (usually).
The first part of this question is actually a request for confirmation based on JavaScript-centric research I've been doing all afternoon. If I am incorrect about any of these items, please correct me!
The ECMA is the official standards body that "maintains" JavaScript
Any browser that wishes to support JavaScript (which all/most of them do), must include some sort of interpreter (what is it???) engine deep inside the browser code
When someone points a JavaScript-enabled browser to a URI that contains JavaScript code, that browser downloads the JS file(s) along with the HTML, CSS, etc., runs the JS through this interpreter, and the resultant output affects how the page is ultimately rendered
In addition to these items I've also heard terms like JavaScript "plug-ins" or modules that browsers can have. What are these plugins/modules and why would a browser need them if they are ECMA-compliant and already contain a JS interpreter?
Thanks in advance!
ECMA is the standards body that enforces the "standards" of JS. They keep the language consistent and documented (although knowing it's history, they didn't do good with that job as a "standards body")
A JavaScript engine is a piece of software embedded into the browser to parse JavaScript source code. It's what turns your JavaScript into actions on screen (and off screen). An example of these are V8 (Chrome), TraceMonkey (Firefox), Chakra (IE), Carakan (Opera) and Nitro/SquirrelFish (safari)
Before the above happens, one must introduce the JavaScript code into the browser to be parsed (usually using <script> tags)
JavaScript Plugins/Toolkits are just code developed by programmers to do stuff easily. they just do things that normally you would code 1000 lines for. these code also "improve" programming by giving consistency cross-browser. Examples of plugins/toolkits are jQuery (and it's UI plug jQueryUI), YUI, Dojo and so on.
Browser extensions/plugins on the otherhand "extends" the functionality of the browser. Examples are ADBlock (whick blocks page ads), FlashGet (Downloads flash files on the page). These guys are programmed into the browser rather than into the page. However, lately, these extensions are powered by JavaScript for the reason that it's easy to program
The ECMA is the official standards body that sets the standard for ECMAScript which JavaScript implements. So does ActionScript. ECMAScript covers all the programming essentials and basic structure of the language.
The ECMA spec does NOT cover browser-oriented APIs like the DOM. This is covered by the W3C DOM standard which is meant to define a language neutral API. IE has supported the ECMA spec fairly religously since IE 6 while almost completely ignoring the DOM stuff in favor of its own proprietary BS all the way up until IE9.
The spec itself is just a bunch of rules for how the language is supposed to work. As long as you write the same stuff and a given browser's interpreter gives the expected result as defined by the spec, it is ECMA compliant to whatever version being considered.
An interpreter parses and tokenizes the actual text you've written and turns it into instructions to be read by the browser's run-time environment. Modern browsers sport actual JIT compilers which actually convert your JS into bytecode as it's executed so that the browsers run-time environment itself doesn't have to translate.
Most browsers cache the actual binary of a js file. So pages on the same domain that link to the same server location won't have to download the same file twice when a new page links to it. This is the same as with any resource (images, css files, etc.) I don't believe they cache the results of any of the interpretation that goes down but I think in the case of the JITs the results of certain pre-execution routines (JIT prepwork basically) might be kept in memory (pure speculation on my part - but it seems kind of duh).
We've been a bit fast and loose with language in regards to usage of words like plugins, frameworks, tools, libraries etc... It's all just JavaScript, usually. You "plug them in" by linking a file or cutting and pasting into an existing one like any other JS. By plugin, however, people usually mean it works with some existing pre-fab JS, like JQuery, which tends to be expanded on by adding methods to the object that it returns (JQuery is just a big fancy function that builds and returns the same object every time you fire it basically). A library tends to be a large collection of pre-defined methods for doing all sorts of things. Like a warehouse 'o stuff you can use. I think of JQuery as more of a tool than a library because its focus is more on reducing cruft and normalizing browser differences. JQ by itself doesn't really do anything all that far removed from core JS methods. It just makes it much easier/faster to do them. It has a UI library, which is basically a large set of plug-ins that actually spit out pre-fab UI elements, HTML, CSS and all. A framework tends to be more of a system for building large-scale app-type structures on the front end. It's not just a bunch of methods to call, it's a way of building things aimed at making it easy to barn-raise entire app structures while skipping a lot of the more granular work one typically needs to do to keep things flexible (as a result, frameworks usually aren't particularly flexible but that doesn't mean they can't be).
I can't find information on the web how W3C languages compile to machine code. I know that the gap between the web and the processor must be somehow the browser, but how does it work and what are the steps till Javascript is executed in the processor?
Links to scientific documents would be also greatly appreciated.
It's up to the implementation; the specification is the full description of the language and how it's supposed to work, implementations are free to satisfy that implementation in any way they like. Some implementations seem (from the outside) to run it purely as an interpreter in the old sense; others may or may not compile to bytecode; V8 (the JavaScript engine in Chrome, Chromium, Brave, Node.js, and others) used to compile to machine code (twice, for hotspots in the app), but now starts out parsing to bytecode and running it in an interpreter and only compiling hotspots as necessary (details). (There's also a V8 mode where it only interprets, which they're experimenting with for environments where compiling at runtime isn't an option, such as iOS where non-Apple apps aren't allowed to allocate executable memory.)
The V8 team (V8 being the JavaScript engine in Chromium and Chrome) periodically publish descriptions of how they get the fantastic speed out of V8 that they do. You may find some of that on the V8 blog.
Naturally, you can also kick around the code of any of the open-source implementations. V8 and SpiderMonkey (Mozilla's engine) are the two major open-source ones I know.
This may help : http://www.ecma-international.org/publications/standards/Ecma-262.htm
There is no spec for how to translate into bytecode (That is up to the browser developers) but there are specs about how the language should behave
For Firefox there's some specifications on its bytecodes:
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Bytecodes
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals/Bytecode
For V8 it's compiled to native code directly:
http://jayconrod.com/posts/51/a-tour-of-v8-full-compiler
Javascript (as it's name suggests) is a dynamic scripting language. Meaning that it's code is analysed and executed at runtime by the web-browser's Javascript engine.
It is up to the Web-browser, how it wants to deal with Javascript. Some may generate an intermediate language, or bytecode. Some may directly analyse and execute it.
Here are the steps to the simplest way to execute Javascript (parsing and executing at runtime):
Parsing and Preprocessing (recursive descent or otherwise)
Analysis
Execution
Chrome's Javascript Engine compiles Javascript to native platform-specific machine code (for optimum performance) It also has a Garbage Collection Mechanism.
In addition to the useful, specific answers already given, the phrase 'adaptive optimisation' is probably worth looking up if performance is your main interest. JavaScript and its interpreters are just the latest instance of systems that need to convert something else to machine code at runtime, so there's plenty of wider reading. The bytecode forms of Pascal, Smalltalk, Java, etc can easily enough be viewed as an intermediate form in the process of running a defined language on arbitrary hardware — Apple's SquirrelFish explicitly creates a bytecode and uses a JIT compiler on that, for example.
I don't think I need to provide examples because every web developer knows that you need to test your Javascript to make sure it's compatible across different browsers. What I don't get is why. Isn't Javascript Javascript? It'd be like the .NET framework behaving differently on one computer than it does on another. Can anyone shed some light on this, possibly with some source links to go along with their answer?
The short answer is every browser writes it's own interpreter for JS
The long answer
To understand why a programming language functions differently you have to understand what happens to a programming language at execution. First there are two types of languages interpreted and compiled. Compiled languages are turned from people readable "code" to machine code before execution and distributed as a binary.
Interpreted languages are compiled on the fly, JS is one of those languages. What does it mean to compile a language on the fly? Well, a computer can understand nothing but 1's and 0's and because of this all higher level languages must be broken down to instructions and then binary. When something is compiled on the fly it compiles a line, then runs it, then compiles the next. (of course there are intricacies but that really is the short of it)
Because JS really has never had a stand alone interpreter until recently, and the browser is JS's main purpose every company had to write their own interpreter that would go into their browser. Microsoft, Mozilla, Netscape... Everyone needed to think of how certain things could be handled and then execute them.
Because of this two things happen first, you are never gonna get the same thing if two people are working on it. Think about when you take an intro to Comp Sci course everyone has to make a calculator app but everyone takes a different approach. That happens all the time with js, and causes some browsers to crawl while others fly.
The second is that companies get set in their ways, they have too much time and energy invested in their interpreter and don't want to start over when modifying works and is cheaper. This means that differences that arose in the past when JS was less used and no where near as critical to web development will remain just because it's really difficult to roll out a whole new version of IE with webkit when it has been centered around it's own interpreter for years.
Read this -> http://www.quirksmode.org/js/intro.html there are lots of version of the JavaScript implementation - all of them have differences.
Each browser has a different version of Javascript, and some implement only certain features of each version. Here are the releases notes for IE9, that state javascript performs differently on IE8 and IE9.
Here is a list of versions.
usually, there is not different of javascript language between different browser, the problem is that DOM, HTML and event are different in different browsers.
some javascript library can help reduce gap, ie: jQuery (only reduce gap)
Well, javascript is in fact a subset of EcmaScript which is a standard recommendation. The implementation of this recommandation among the browsers depends only of the willingness of the editors. This leads to several implementation (javascript, jscript, v8, etc...) all behaving differently in certain cases. Add to this that the layout engine differs from browser to browser (gecko, trident, webkit, etc...) and you'll see that it's not that simple to use javascript ;) .
Well, as a matter of fact, .NET does behave differently, depending on which implementation (Microsoft's or Mono) you use.
That said, it is the same with Javascript, with the small exception, that the standard is a moving target. It was introduced back in the days by Netscape, copied partly by Microsoft as JScript, standardized partly by ECMA and extended independently by the browser vendors, each one with their own idea of what would be a good idea to have in Javascript.
It's hard to define the Javascript. What is usually implemented as a baseline in all nowadays browsers is the feature set known as Javascript 1.5 aka ECMA-262 3rd edition. The browser vendors (and others) work on something called ECMAScript 5, but it will last years, until all browsers support this fully.
And then of course, every browser has its own bugs in its implementation. One of the most (in-)famous examples is the trailing comma thing in IE:
// works in all browsers:
var a = [1, 2, 3]
// works in all browsers but IE
var b = [1, 2, 3,]
Internet Explorer has JScript, this is Microsoft own JavaScript implementation. They have a long story of not following any specifications.
As for the others - they make their own implementations of the functions and objects in JavaScript. For example you have a theoretical function foo, and it is the same name on every browser. But the way it is written is different. Which may cause difference in the time for the execution or something else.
One other thing - every browser has its own specific functions. Nobody can force them not to have such.