What's the state of the Javascript language? - javascript

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.)

Related

Who standardizes the JavaScript language

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.)

V8 and ECMAScript differences

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.

Why is JavaScript inconsistent across browsers?

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).

"Home" of Javascript similar to python.org?

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.

Why don't we just stop using the word JavaScript, in favor of ECMAScript?

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.

Categories