Which organization is appointed for implementing new JS features? For example, adding a new reverse string capability, or anything else that would be introduced in ESNext?
"ES" stands for "ECMA Script". ECMA International is the organization that standardizes Ecma Script. To be more precise, there is Technical Committee 39 or TC39 responsible for this particular standard. Members of the committee are people from different organizations like Microsoft and PayPal. Also there is invited experts, who are not on committee, but also help to develop the language.
They have a process of proposing and introducing features. This process is public and uses GitHub where you can read about what was proposed and propose your own features.
As for implementation - it is responsibility of browser vendors. Most browsers now open sources (at least partially), so you can also contribute.
Related
As I understand it, ECMA International is responsible for defining the ECMAScript language specification (Reference number ECMA 262). This specification is implemented by certain languages, such as JavaScript or ActionScript. These languages are then transformed into a machine-readable form through an engine, such as V8 or SpiderMonkey.
What is still unclear for me is who is responsible for standardizing the JavaScript language itself? How is it possible that everybody writes the same JavaScript code if only the specification upon with the language is based seems to be standardized?
Javascript is being specified by a group of people called TC39. This group belongs to the ECMA international organization (Ecma International - European association for standardizing information and communication systems).
The specification is being developed publicly here.
Features find their way into the specification according to the TC39 process.
Discussions around proposals and the Javascript language also take place in a mailing group.
TC39 means Technical Committee number 39. It is part of ECMA, the institution which standardizes the JavaScript language under the “ECMAScript” specification. It works on the standardization of the general purpose, cross platform, vendor-neutral programming language that is ECMAScript. This includes the language syntax, semantics, libraries, and complementary technologies that support the language.
TC39 and the W3C collaborate wherever there is overlap between JavaScript and HTML5.
TC39 has bi-monthly face to face meetings, usually on the West Coast but one meeting per year takes place in Europe. In addition, at least one meeting is held in Redmond, WA (July meeting usually).
Attendance at meetings is controlled by Ecma International By-laws and Rules. Visitors on a one-time basis are usually approved by the Secretary General and requests should be directed to him for approval. Such visitors are kindly invited to fill in the Ecma International TC39 ECMAScript RFTG Contributor form.
TC 39 works on:
Maintaining and updating the standard for the ECMAScript programming language.
Identifying, developing and maintaining standards for libraries that extend the capabilities of ECMAScript.
Developing test suites that may be used to verify correct implementation of these standards.
Contributing with selected standards to the ISO/IEC JTC 1 committee.
Evaluating and considering proposals for complementary or additional technologies.
Reference Link
In the case of Actionscript - Adobe were much more proactive in adding features than the rest of the wwwc were at the time, this led to the creation of Actionscript 3.0, based on ECMA script version 4, which was never implemented for browser JS, which was a shame, though they were focusing on aligning ES5 with HTML5, and saving many of the ES4 proposed features for ES6 like the Class syntax, though this is still optional and legacy code is still compatible. While ES4/AS3 had mandatory class structure, and was gravitating to becoming a more like Java than Javascript, and consequentially, wasn't backwards compatible, which was a dealbreaker for the consortium.
So to answer your question - how can they be different? it's because the spec doesn't necessarily make it off the drawing board in all cases, and there's no mandate for a proprietary Language like Actionscript to stick to any standard, whilst JS should continue to adhere to them.
(Historically, Microsoft have tried to rock the boat, with jscript and it's proprietary features, and now Typescript with more of the same, but now JS is becoming a compile target, it allows companies like Microsoft to rock the boat as much as they want without getting in the way of the wwwc. Where we will still see disparity moving forward will be different languages compiling to JS, and JS compliant standards like webassembly that aren't built for human readability become more commonplace, but that's answering a whole other question.)
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.
Perl, Ruby, Python, Javascript / ecmascript, PHP are all similar in the sense of being open source, open documentation, multi-platform, etc.
Perl has http://www.perl.org
Ruby has http://www.ruby-lang.org
Python has http://www.python.org
PHP has http://php.net
Is there a "home" for javascript in the same sense as these other languages?
When I say "home" I mean the go-to place for official documentation, specifications, source code of the language, examples, etc.
There's “JavaScript” the Mozilla-specific scripting language, for which the nearest to a home would probably be MDC, in particular the Core reference — though this has not been kept up-to-date with newer language developments, sadly.
And then there's ECMAScript, the standardised language that grew out of early Netscape work on JavaScript, and which is the basis for Mozilla's modernised JavaScript, IE's JScript, and the implementations in Opera, V8 (Chrome) and Squirrelfish (Safari), not to mention Flash's ActionScript.
This is driven by ECMA TC39 which produces the ECMA-262 standard. As a pure standards group, their materials are dry, unfriendly, and not really a suitable ‘home’ site at all. But if you want official that's all there is.
There is a real gap here for a user-readable doc site that covers standard ECMAScript, rather each vendor's own extended quirky version of it. (The canonical ECMA-262-5 is quite unreadable, even by the standards of standards documents.)
A very good place is https://developer.mozilla.org/en/JavaScript - they have tons of documentation there.
I will get burnt at the stake for this link, but for the 60%+ internet users out there who are using Internet Explorer (still), the MSDN reference is actually well documented.
It's the home of Javascript in the same way Simon Cowell is an authority on music though.
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.)