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.
Where can I find a list of all the differences between V8 and ECMAScript?
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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 ofeval, 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. migratinglet' 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.