Where can I find a list of all the differences between V8 and ECMAScript? For example V8 supports const, which isn't part of the ECMAScript standard.
Edit: Direct answer: Track status of ES5 implementations in progress which indicates the V8 googlecode issues tagged es5
or https://github.com/joyent/node/wiki/ECMA-5-Mozilla-Features-Implemented-in-V8
V8 implements all of ES5 currently aside from a handful of edge cases, and only then in order to be compliant with the majority of how other current browsers handle the given situation.
Because it won't be living on its own nearly all of the differences you'll be dealing with will be in the host environment implementation wrapped around it. For most uses this is the various APIs web browsers provide. As a non-browser example, Node.js provides custom APIs for file system and network interaction. In terms of core language there's just not that much wiggle room. Minus the DOM, JavaScript is a pretty damn simple language to use (part of why it's so awesome) and has a really specific Specification document.
ES5 is an iteration up from ES3 and nearly 100% backwards compatible if not using 'use strict'. After nearly a decade of stagnation along with inability to gain a consensus among major JavaScript engine implementers ES5 was born and limited primarily to cut out and address the worst issues with the language. The extent of mainstream use ES5 is Array extras, Object extras (mainly Object.create), Function.bind, and strict mode (which is entirely about stripping features out), and a handful of natives helpers like built in JSON and base64.
Most of this 240 page specification is spent in laboriously defining every detail about behavior that has existed in JavaScript for almost 15 years, as well as the list of features which will be deprecated and eventually removed (with, various uses of eval, etc.).
Harmony (ES6) is the first real big change we're going to see. ES5 accomplished the goal of getting engine implementations on the same page and gutting most of the problematic parts of JS. Looking forward to ES6, it's time to address some fundamental language issues that require syntax changes to fix. ES6 is scheduled for finalization in late 2013 but large chunks are already implemented in JS engines in order to test them and see how they work in practical usage. The web is a living thing and implementing new standards isn't a matter of creating a new spec and then unleashing it on the world like it is most other industries. Ideas are floated and must past muster at both the implementer level (the guys who write V8, Spidermonkey, JSC, Chakra, etc.) and then the actual user level (user in this case being web developers writing code to run in those engines). Ivory tower dictation just results in lack of use.
Specifically in the case of const: this is currently not exactly defined entirely. It's a keyword with similar but not exactly the same functionality in V8 and Spidermonkey, and has a similar but not exactly the same meaning for ES6. You're probably safe to use it if you expect your target audience's engine to support it currently, but as implemented it wasn't technically part of any official spec. migrating let' andconst'
Beyond that there's "Host Objects" which are exposed by the given engine a JS script is running in. JavaScript existed first as an implementation and second as a specification, so until recently it wasn't obvious to non-experts to know where the diving line is. When it's running in a browser (as is usually the case) the Document Object Model is exposed as a host object for automatic usage. The functionality of the DOM is largely described using IDL and is under the purview of the W3C. The multitude of specification implementations encompass 6 top level sections, almost 50 separate working groups, and around 1000 separate specifications. These are interfaces exposed to JavaScript but completely ungoverned by the requirements of any JavaScript specification. The DOM encompasses a huge space of described functionality and continuously changing implementations thereof.
Related
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.
I was seeing the W3C Document Object Model and excited that different programming languages have to implement their interfaces accordingly. Like other languages, JavaScript also maintains the DOM.
So I'm curious to know about the following questions:
Which versions of javascript implements dom level 1, 2,3 and so
forth.
Are they all implemented in javascript?
Are they implemented by javascript or implemented by ECMAScript and
followed by JavaScript?
And what are the IDL definitions described in W3C DOM: Are they
needed to understand for javascript developers or is that the symbol
of implementation by HTML?
The pedantic answer is "none".
There is no formal mapping of JS iteration to DOM-specification.
In general, JS-versioning has all but been abandoned (save major overhauls), though can be seen as signposts of when you might start to consider feature-checking.
This is because...
Not really, no.
That is to say, yes, the APIs which you will use to interface with the HTML DOM are all implemented in JavaScript...
However, no browser has a stable, feature-complete implementation of either
JS or HTML DOM[1-4].
Because both specs are so large, and ever-changing, different vendors have prioritized different features at different times, leading to patches of incompatibility.
To further this actual answer, the JS spec says nothing of DOM or BOM ("Browser ...") APIs.
This is the reason #1 must be a "No", as different DOM/BOM combinations on different JS implementations leads to the fundamental inability to say "All JS1.7-compliant browsers are DOM3 compliant."
The truth is that no browser is wholly compliant with either spec, and neither spec is the latest, anyway. As for technical-implementation (the code behind the API), there are no rules, so long as the behaviour is well-defined. Some browsers defer to C/C++ for core JS/DOM/BOM functionality, while older IE browsers had an ActiveX layer between the browser and JS DOM access (making touching elements for any reason arbitrarily expensive).
Here's the rub.
Most people would consider them to be different things.
Most people would think "JS is the thing that you use in the browser, to do your scripting.".
Really, ECMAScript and JavaScript are the same thing, and "JavaScript" is a Sun (now Oracle) trademark... how none of us are getting sued is a mystery.
JS/ECMAS knows nothing of DOM or BOM, and it's up to the vendors to include DOM-access in their browser (on a per-feature, rather than per-version basis). It should also be noted that while VendorA might implement a feature from the spec, and VendorB might omit it, VendorC might have an off-standard implementation of it, and also implement a similar but completely out-of-spec feature, as well.
Don't worry about the DOM implementation specifics.
As a JS-dev, you won't need to know or care what a Java implementation of an HTML node might look like.
Even with WebIDL, and moving away from the old-world Java-centric view, as far as day-to-day usage of JS as a language, the DOM-node interfaces are as dry as toast, unbuttered, face-down in a sand dune, unless it's really what you're into.
Even then, it's more for people who make the browsers, and not the people who make things which run in them.
These aren't all of the answers. And while I've tried to remain subjective, I'm sure there's a little objectivism in there, as they aren't wholly cut and dry. I've tried to be, at least, factual.
From an engineering perspective, being careful about how and when you use the DOM in client-side JS is important -- both for making code portable and for allowing each language in the client-side stack to have access to the HTML in question, without doing somersaults in JS, to accommodate, because you built your whole site using DOM construction in JS.
From a pragmatic standpoint, rather than trying to match features to versions, use sites like http://caniuse.com to match features to browser versions. It's much more productive.
And have fun.
Here's something I've been pondering after countless hours fixing JS to be cross-browser compatible (mostly IE): Why isn't Javascript consistent accross browsers?
I mean, why can't JS be nice like Java and Flash? Instead, we have to resort to frameworks like jQuery. Don't get me wrong, they make my life easier - but why do they even exist in the first place?
Is there a historical reason for this? Do companies rolling out browsers just ship their own JS engine? What are the politics that make standardization so difficult?
(Note: I understand that a good part of the problem is DOM related, but the question remains).
The Javascript core language for the most part is consistent ( Referring to ECMAScript version 3 released in 1999. )
It's the DOM implementations that cause headaches. Partly because at one point there was no DOM specification so browsers could do whatever the hell they wanted in terms of making up the rules for which to access and manipulate html elements in a web page.
For example:
window.addEventListener for DOM supporting browsers, while window.attachEvent for IE.
textContent for DOM supporting browsers, innerText for IE.
Memory leakage for attached event handlers in IE so you have to unload them manually
getElementById is buggy in IE and Opera because it returns elements by name
getAttribute('href') returns inconsistent values
There are also issues relating to the browser's CSS support.
IE6 doesn't support native PNGs so you are forced to use the filter library
Buggy animation in IE dealing with filter opacity
Language core inconsistencies would be things like
Inconsistencies between regex engines
But yeah, in short the point is that before, there was no standard. Since then, the w3 came up with standards, but every browser vendor has its own way of dealing with implementing it. There's no governing body that forces the vendors to fully apply the spec.
Do companies rolling out browsers just ship their own JS engine?
Yup, that's probably the main reason. There is no unified JS engine; there are various implementations of ECMAScript.
Browsers roll their own implementation, plain and simple. It's the same reason why rendering and CSS and all that are different across browsers. Java/Flash/etc. are more universal because they're abstracted out of the browser and accessed via a plugin of some sort. But their actual core implementations are separate from the browser and controlled by a single vendor.
To add to the other answers: there is a historical reason for this. I can write this myself, but quoting Wikipedia is easier on the fingers:
JavaScript was originally developed by
Brendan Eich of Netscape under the
name Mocha, which was later renamed to
LiveScript, and finally to JavaScript.
LiveScript was the official name for
the language when it first shipped in
beta releases of Netscape Navigator
2.0 in September 1995, but it was renamed JavaScript in a joint
announcement with Sun Microsystems on
December 4, 1995 when it was deployed
in the Netscape browser version 2.0B3.
[…]
JavaScript very quickly gained
widespread success as a client-side
scripting language for web pages. As a
consequence, Microsoft developed a
compatible dialect of the language,
naming it JScript to avoid trademark
issues. JScript added new date methods
to fix the non-Y2K-friendly methods in
JavaScript, which were based on
java.util.Date. JScript was included
in Internet Explorer 3.0, released in
August 1996. The dialects are
perceived to be so similar that the
terms "JavaScript" and "JScript" are
often used interchangeably. Microsoft,
however, notes dozens of ways in which
JScript is not ECMA-compliant.
In November, 1996 Netscape announced
that it had submitted JavaScript to
Ecma International for consideration
as an industry standard, and
subsequent work resulted in the
standardized version named ECMAScript.
As you can see, the standard, ECMAScript, was developed later than the original language. It's just a matter of adapting this standard in the current implementations of web browsers, that's still going on, as is the development of ECMAScript itself (e.g., see the specification of ECMAScript 5, published December 2009).
The question says it all.
There is a difference between ECMAScript and JavaScript, isn't there?
ECMAScript is a well-defined language (spec here).
JavaScript is a dialect of it, not a full implementation as far as I understand, plus it contains what five generations of browsers did to it.
As Christoph points out in his comment, Microsoft's implementation of ECMAScript is actually called JScript, and the word "Javascript" is licensed to the Mozilla foundation.
The general perception, I think, is that of JavaScript as the sum of every browser's implementation of ECMAScript. It would be horrendously confusing to change that, and factually incorrect.
Say your question out loud and you will find it is its own answer.
If you spell it out then the five syllables of EEE-SEE-emm-EH script are quite a mouthful. And if you attempt to pronounce it as a word it will come out sounding like EczemaScript, which will lead to a rash of jokes.
Besides, "JavaScript" is the more than just widely used, it is embedded. No way are you going to be able to stop people saying "JavaScript".
edit
By a spooky coincidence I have just watched the Steve Yegge keynote from the OSCON 2007, in which he talks about branding and software. He touches on the issue of JavaScript vs ECMAScript. Without reaching a conclusion, it's true, but Steve is always good value. Watch it now.
The history of why it is called JavaScript is a convoluted one, and has a lot to do with making developers comfortable with the new language.
It was originally Mocha, then LiveScript, and finally JavaScript. Calling it JavaScript probably has a lot to do with why it was so widely adopted, as people assume it is similar to Java, and other C family languages that most programmers use every day. It actually has much more in common with Scheme and some of the more esoteric prototypal languages.
JavaScript is a well specified language, and is surprisingly well implemented accross all browsers. There are elements of the spec that cause major headaches, such as semicolon inference, but these are pretty consistent with the spec across all implementations.
It is the DOM library that causes 99% of the headaches with cross browser implementations in the real world.
As an addendum to the other answers:
HTML specs suggest using the text/javascript MIME type:
<script type="text/javascript">
Usually ECMAscript files are saved with file extension .js
Because ECMAscript is the standard and Javascript is an implementation (albeit a massively fragmented implementation). Which does not wholly support ECMAscript.
Because JavaScript Was its name (granted by Netscape) many years before Microsoft pushed through standardization by ECMA in an attempt to legitimize their independently developed JScript.
Historical reasons. Even if JavaScript™ is actually only the name of the ECMAScript dialect maintained by the Mozilla Foundation, I use the term Javascript (no capital 's') to encompass all common ECMAScript dialects.
Because ECMAScript is a name which refers to the language standardized by ECMA. JavaScript/JScript is one dialect of the language, but it's not the only one. There are other dialects like ActionScript. So the term "ECMAScript" doesn't only refer to JavaScript/JScript but also other dialects like ActionScript which are NOT what is embedded into browsers.
Lots of useful libraries have been built on top of Javascript but I never hear of any changes to the Javascript language itself.
Is Javascript evolving or is it essentially frozen?
JavaScript 1.8 definitely contains lots of new features. It's currently only supported by Firefox 3.x (and other Mozilla-derived JavaScript execution environments).
Standards-wise, ECMAScript 4 has had a bumpy road and is now officially abandoned, so there hasn't been a new JavaScript standard since ECMAScript edition 3 in 1999. Wikipedia's page on the future of ECMAScript adds some detail you might be interested in.
Brendan Eich (the creator of JavaScript) and Douglas Crockford recently gave a couple of talks at the YUICONF 2009, about the current state of the language, ECMAScript 5, the development process and efforts to improve the language in the future:
The State and Future of JavaScript (video, and slides)
ECMA Harmony and the Future of JavaScript
Ecmascript 5 is up for a vote in december. It will probably be ratified.
Ecmascript 5 is a batch of improvements that Douglas Crockford has suggested over the years, combined with some things from the prototype library, and some good metaprogramming foundations for the next version after ecmascript 5 (current effort is code-named ecmascript harmony)
In addition, there's a mode called "use strict" which can be set either at a script level, or for individual functions that removes old features that they want to get rid of to make the language more secure. The mandate is that all future scripts should be written using "strict" mode. Future versions of ecmascript will be built on top of the strict mode, and remove the older features of the language entirely.
Oh, also it has a JSON encoder/decoder built in based on crockford's json2.js. That native JSON encoder/decoder is already available in safari 4, firefox 3.5, and ie8
The language itself is relatively stable. It will continue to receive new features, but on the whole, the need to introduce such changes with a broad [enough] support, and also various requirements implicit to the usage/platform (for example security and privacy requirements), will continue to make the language itself evolve rather than revolve and slowly rather than fast.
The implementations of the language should however continue to improve a lot, in terms of performance mostly; see the healthy competition between the major commercial or open source players if you disagree.
Beyond the language proper and its implementations, I think that a more significant trend is with usage of the language. A concept that's been floated around is that of "Javascript as the new assembly code". This means that just like the majority of programmers do not look at assembly code on a regular basis, but instead rely on compilers to convert from languages of a higher level of abstraction, several "javascript frameworks" and libraries, such as GWT, dojo, Ext JS or JQuery etc. will serve the role of compilers letting the programmer focus on the higher level of details.
Even if one hand-writes javascript programs, these are typically, compressed, obfuscated and generally optimized in a form which doesn't offer a friendly read (when one unlucky soul needs to debug things at that level.)