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).
Related
I am recently reading about Node.js and got an interesting statement about JavaScript and Internet Explorer:
Internet Explorer doesn’t actually support JavaScript or ECMAScript; it supports a language variety called JScript. In recent years, JScript has fully supported the ECMAScript 3 standard and has some ECMAScript 5 support. However, JScript also implements proprietary extensions in the same way that Mozilla JavaScript does and has features that ECMAScript does not.
Source: http://chimera.labs.oreilly.com/books/1234000001808/ch01.html#chap2_id35941400
Frankly speaking I am totally unable to understand the above statement. I know Microsoft has its own VBScript and it allowed JavaScript in IE that is why JS is more popular than any other scripting language. Is this statement true? If yes then the scripting engine of IE does the translations of native JavaScript to JScript or what is the other case?
ECMAScript is the official standard, JavaScript and JScript are implementations of that standard. Just like CPython and Jython are implementations of Python.
As so often if it's about browsers, they both don't necessarily fully support the standard or provide additional, non-standard features, partly because they started evolving when an official standard didn't exist yet.
From Wikipedia about JScript:
[Microsoft] did not want to deal with Sun about the trademark issue, and so they called their implementation JScript. A lot of people think that JScript and JavaScript are different but similar languages. That's not the case. They are just different names for the same language, and the reason the names are different was to get around trademark issues
From the Microsoft documentation about JScript:
JScript is the Microsoft implementation of the ECMA 262 language specification (ECMAScript Edition 3). With only a few minor exceptions (to maintain backwards compatibility), JScript is a full implementation of the ECMA standard.
well, this mainly depends on the version of IE you are using, as you havent mentioned that no one can say that for sure
I think it is not like that instead Microsoft gives you an option to enable Javascript on your IE like this:
Pull down your TOOLS menu
Select Internet Options...
Click the Security tab on the top of the resulting window
Click the Custom Level button
Scroll the list down to the entry for Active Scripting
Check the Enable radio button.
Click OK in all dialogs.
Also Jscript is same as Javascript
JScript is Microsoft's dialect of the ECMAScript standard[2] that is
used in Microsoft's Internet Explorer.
JScript is implemented as a
Active Scripting engine. This means that it can be "plugged in" to OLE
Automation applications that support Active Scripting, such as
Internet Explorer, Active Server Pages, and Windows Script Host.[3] It
also means such applications can use multiple Active Scripting
languages (e.g., JScript, VBScript, PerlScript, etc.).
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.
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.)
The Mozilla Foundation continues to add new language features to JavaScript. They're up to version 1.8 now where 1.5 was more or less the ECMA baseline.
However, Firefox is the only browser that supports the latest version and IE is firmly stuck at a 1.5-equivalent JScript.
What purpose do the Firefox-only extensions serve? Or are they just lying dormant until (and if) the rest of the browsers catch up?
Firefox, Thunderbird, and other XUL apps also have large portions of themselves written in JavaScript. A more featureful JavaScript means a better development environment for Firefox and other Mozilla apps.
Extending the language is a good idea, even if only one browser is doing it - eventually it will prove itself and be made into the standard at which time other browsers will have to catch up.
Otherwise, how can progress be made - Microsoft does this all the time: would XMLHttpRequest have ever made it into the standards if Internet Explorer wouldn't have implemented it first?
From the Mozilla perspective the purpose of these changes, except for adding more capabilities for use by web developers, is to lead up to JavaScript 2.0, that is being developed as the next revision of ECMA 262 (revision 4) TC39 workgroup.
Future browsers will support JavaScript 2.0. In the mean time, developers are invited to take advantage of these extra features - natively in Firefox and using JavaScript libraries that provide backward compatibility with Internet Explorer. I find this very useful.
Also, it may be interesting to note that Webkit (the engine developed by KDE and used by Safari, Chrome and several free software browsers) supports JavaScript 1.7.
The biggest reason at the moment for improved JavaScript is for extension writers, who need not worry about cross-browser compatiblity.
JavaScript is a trademark by Sun which was licensed to Netscape and is now held by the Mozilla Foundation. Microsoft has their own implementation of the language called JScript, but there are others (eg. DMDScript).
ECMAScript was an afterthought to add a common baseline to the various implementations. So it's only natural that language development continues outside the standards committee, which is free to add the changes pioneered by the implementors in future revisions of the standard (eg the array extras introduces in JS1.6 will be in ES3.1).