I wanted to ask a few questions about javascript:
1.Does each browser implement javascript by itself ? Or is their a common SDK\API or whatever ?
2.If each browser implement by itself, Is the javascript engine bounded to the browser version ?
I mean, can I have 2 different engines for the same browser version ?
3.Is there any standards all javascript engines must follow ? Does this standard define memory
allocation ? (Lets say, How I allocate a javascript string ?)
And last,
What are the names of implementation for each browser ? For example I understood FirFox uses an
implementation called "Rhino", Am I right ?
Thanks alot !
Michael
Yes, they implement JavaScript on they're own.
Yes, it is bound to the browser version. No, you can't have 2 different engines for the same browser version. You can though for different browser versions.
Yes, it is called EcmaScript. Most implementation follow it pretty good.
FireFox does not use Rhino. Mozilla developed it, but the implementation in FireFox is different. All browsers implement single-threaded JavaScript, while Rhino is not single-threaded.
Each browser does implement its own version of JS. Thus, why some browsers outperform others. They specification on what JS should do and how it should be done is based on the ECMAScript specification. The only case I've seen of having multiple engines (or versions of engines) is with IE's web dev toolbar, where you can "roll back" your IE version to test how previous versions react. I've found the JS engine to be pretty faithful when doing browser version tests.
Wiki has a nice write up on the different engines. http://en.wikipedia.org/wiki/JavaScript_engine#Mozilla
JavaScript is standardized through the ECMAScript specification which most browsers will adhere to.
However, not all features are implemented across all browsers and browser versions and some features have their own browser specific quirks.
You can find more details about ECMAScript and the versions browsers implement here:-
http://en.wikipedia.org/wiki/ECMAScript
You will not get two different JavaScript engines offered to you within the same browser (usually).
Related
I have a very big doubt and it is that if ActionScript and JScript are based on ECMAScript, it is possible that they can be executed in environments like Google Chrome and if not, why not?
Any code that 100% conforms to supported versions of ECMAScript can be run in Chrome. But, you can't actually do anything useful in a browser with pure ECMAScript code because you can't interact with anything in the browser itself - instead you have to use browser-specific APIs to do that which are not ECMAScript methods, but browser-specific methods that are documented in different standards. Similarly, an ActionScript script likely interacts with its environment through non-ECMAScript methods which are not support in a browser.
And a new language that conforms to 100% to the latest version of ECMAScript would not have problems with the interpreter of each browser? I say this because every browser has a dedicated JavaScript interpreter or that's what I understand so far.
It's hard to tell what you're asking. There is no such thing as a new language that conforms to 100% of ECMAScript. That would just be an implementation of ECMAScript (not a new and different language) - just like each browser has its own implementation of ECMAScript. If it is indeed a new language, then it must have things in it that are not in ECMAScript. But, my point is that, pure ECMAScript code should run in any "compatible" ECMAScript implementation that is targeting the same ECMAScript version.
There are details of implementation that are not always complete in each browser since ECMAScript is a moving target (new revisions regularly) and the development on the implementation is ongoing work in each version. So, there can be compatibility issues around the edges of newish features, but that is true of any Javascript code running across browsers that is leverage very new features. Developers who are interested in good cross browser compatibility either stay away from the very latest features, cross compile their code to a lower common denominator using something like Babel or TypeScript or they study and test exactly what they can and can't use across all their target browsers.
I want to check JavaScript Version in my web browser.
Is navigator Object return proper JavaScript version?
navigator.appVersion; /*Is it correct?*/
navigator.appCodeName;
navigator.appName;
Is there any way to detect exact JavaScript Version from Browser console or anything else?
Browsers don't give any real version, because they don't exactly support any one version. They support some (or most) features of some versions.
Any support declared for "JavaScript 1.x" is just a legacy hack for compatibility with Netscape.
Similarly, these navigator fields are useless on purpose. In the past they have been misused to block browsers so much, that the spec now recommends all browsers to lie and say they are Netscape 4.0.
On the web, in general, you should never check version of anything to decide whether it supports the features you need, because it's too easy to make an invalid assumption and break your code in some browser, including future ones you can't test now (e.g. a feature may not be related to the version you assume, or browsers may lie about versions they support in order to work around sites blocking them).
You should use feature detection instead.
You can detect presence of individual JavaScript features by running them and seeing if they work. If the new feature requires a new syntax, you can try running that syntax inside eval. See how it's done on: https://kangax.github.io/compat-table/es6/ (there's a (c) icon with detection code next to features when you expand the list).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
OK, so I'm trying to learn JavaScript properly so that I can write good, clean client-side code, but whenever I think I'm making progress, something stops me dead in my tracks!
I want to know:
What is the different between JavaScript, ECMAScript and JScript?
Which should I focus on learning?
If these are versioned, which version should I be supporting?
Are there any really good references (web / books etc) that are a must have/read?
How do I ensure that what I write will be compliant with all major browsers (IE, FF, Safari, Chrome, Opera etc.) ?
MOST IMPORTANTLY...Is there a reference of the core objects (Array, Number etc) so I know what is implemented already and what I need to do myself?
Thanks.
Javascript is the original name when the language was developed by Netscape.
JScript is Microsoft's name of their own implementation.
ECMAScript is the name of the language standard developed by ECMA, from the original Javascript implementation.
So, it's just one language, with different implementations.
The implementations of Javascript and JScript differ somewhat in what they support, but each version supports what's in the corresponding version of the ECMAScript standard. Generally you just use what's supported a few versions back, so that it works in all the browsers that are still in use.
One reference is the Mozilla Developer Network, as Mozilla is the current developer of Javascript. For each method and property you can find which version it is supported in.
JScript is documented at the Microsoft Developer Network, and has similar information about support. (Note that all Microsoft documentation is there, not only JScript, so for example you would need to search for "jscript array" rather than just "array".)
Using a library like jQuery is useful to avoid dealing with some of the compatibility problems between browsers.
ECMAScript is the scripting language standardized by Ecma International in the ECMA-262 specification and ISO/IEC 16262. The language is widely used for client-side scripting on the web, in the form of several well-known dialects such as JavaScript, JScript, and ActionScript.
Depends on you, but I think most commonly used for web dev is JavaScript
JavaScript was formalized in the ECMAScript language standard and is primarily used in the form of client-side JavaScript
I would recommend this book
By learning more and more about the language itself and writing tests
Look here
It is important to understand, that ECMAScript is a standard, defined in the last century. :D Whereas Javascript is derived from ECMAScript. Derived in a sense, that it implements the standard.
The big difference is, that Javascript actually only exists within the Browser, saying, it is by no means a standard in itself. Every browser can (and a lot do) implement it's own methods.
So, if you seriously want to learn it and write clean code, then IMHO you have to first get familiar with the ECMAScript standard.
To 3: Since Javascript is implemented by the browser, this really depends on what browsers you want to develop code for. Older browser may have to be dealt with trought some seperate handling in your code.
To 5: Again, javascript can check what browser (or what client software in general) requestet the page it is loaded in. Meaning: If bad comes to worse, you can deal with each browser seperately in your code. But most of the time they are pretty compliant (at least the later versions)
On 4 and 6 I'd have to check first for myself.
Hope I could help you out a bit.
Regards
ECMAScript is the language, JavaScript and JScript are dialects
I would, personally, look at and learn JavaScript.
It depends on what browsers you want to support, easily googled.
MDN is a pretty good web source. JavaScript: The Good Parts and JavaScript: The Definitive Guide are both very good books, the first short and concise the latter very detailed.
JavaScript libraries like jQuery is very good for this reason. It all comes down to learning all the quirks of the browsers. Google is your friend.
MDN.
Wikipedia please.
Javascript is a language, this is probably what you want to learn rather than a spec.
Welcome in hell, all. Modernizr and jQuery exists for a reason. Unless you are doing Javascript on the server side with Node.js for example, in this case you can focus on only one JS Engine (V8 for Node).
MDN
Test, Test, Test and re Test. Try never to use too recent features and use libraries.
MDN tells you which browser supports what.
They're one and the same - for an history on JavaScript watch the Douglas Crockford webcasts on YouTube.
http://youtu.be/_DKkVvOt6dk
http://youtu.be/hQVTIJBZook
2,3,4. Start with this http://eloquentjavascript.net/
Libraries like jQuery do a good job in normalising behaviour across browsers.
I think this is what you are looking for http://dochub.io/#javascript/
In Coders at work, Douglas Crockford discusses how bugs in browsers cause Javascript to be a complex, clunky language and fixing it is a catch-22. In Beginning JavaScript with DOM scripting and Ajax Christian Heilmann says something similar "[The] large variety of user agents, of different technical finesse [...] is a great danger to JavaScript."
Why doesn't JS have a breaking new version? Is there something inherent n the language design where backwards compatibility becomes a must?
Update
Why can't javascript run with multiple engines in parallel? Similar to how .NET runs versions 2, 3 and 4 on the same machine.
Lazy copypasta at OP's request:
JavaScript is just a programming language: syntax and semantics. It has no built-in support for browsers (read: the browser DOM). You could create a JS program that runs outside of a browser. You (should) know what an API is - the DOM is just a JavaScript API for manipulating an HTML page. There are other DOM APIs in other languages (C#, Java, etc.), though they are used more for things like XML. Does that make sense?
Perhaps this MDC article can clarify further.
Well a breaking change would break a lot of existing websites, which would make a lot of people very angry :)
Backwards compatibility is important because of the large number of browsers deployed and the wide variety of versions of those browsers.
If you serve a new, incompatible kind of Javascript to old browsers, they all break.
If you invent a new language that is not considered to be Javascript by existing browsers, then it doesn't work with the majority of browsers. Very few users will be willing to download a new browser just to work with your new language. So web developers have to keep writing compatible Javascript to support the majority of the users, no matter how great the new language is.
A lot of people would like to see something better than current Javascript be supported by browsers, but it just isn't going to happen any time soon. All the makers of browsers and development tools would have to support the new thing, and continue to support the old Javascript stuff too. Many interested parties just wouldn't consider the benefit to be worth the cost. Slow evolution of Javascript seems to be the only viable solution.
As a matter of fact, ECMAScript 5 is not fully backwards-compatible for the very reasons you mentioned.
Inertia.
Making a breaking change would break too many sites, no browser vendor would want to deal with all the bug reports.
And PHBs would be against targeting a new version, why should they have their developers write javascript for the broken and the fixed languages? Their developers will have to write it for the broken version anyway so why bother with 2 implementations (which from a developer perspective sucks too since now they have to update, support and debug 2 separate trees).
Ecmascript 5 has a "strict" mode. I think this strict mode is intended to combat the problem you mention. Eventually you'd mark scripts "strict" that you want to use the new engine, all others get run in an old crufty VM, or with un-optimized codepaths or whatever.
This is kind like IE and Mozilla browsers having multiple "modes" of rendering websites (IE even swaps out rendering engines).
See this question about it
Javascript has subtle differences across different browsers. This is because each browser manufacturer has different sets of responsibilities to their users to support backwards compatibility (if any). If I had to pick, I'd say the biggest barrier to the advancement of javascript is older versions of Internet Explorer. Due to service agreements with their users, Microsoft is contractually obliged to support older browsers. Even if other browsers cutoff backwards-compatibility, Microsoft will not. To be fair, Microsoft does realize how terrible their browsers are and will hopefully push IE 9.0 very hard. Despite the inconsistencies of javascript across different browsers, they are subtle enough to make cross-browser programming more than feasible. Abruptly cutting off backwards-compatibility would be a practice that would make web development a nightmare. Incrementally cutting of backwards-compatibility for specific aspects of javascript is feasible.
There is much more else wrong with JavaScript. You can't be fully backwards-compatible with things that were never fully compatible when they were fresh... Say, the length of the array [1,] is reported as 2 by at least older versions of internet explorer.
The biggest fault of JavaScript is that is comes with a tiny, incomplete and pretty much unusable standard library. That is why everyone retreats to using jQuery, Dojo, Mochikit etc. - these offer mostly functionality that should be part of some standard library included with the browsers instead of floating around in thousands of copies and versions. It's actually what makes .NET and Java so popular: the language comes with a reasonable standard library. With C and C++, you have to dig out the nice libraries (Boost e.g.) yourself.
But other than that, the ECMAScript standard occasionally is updated.
Google is also trying to do this bold step forwards and redo JavaScript in a slightly more sane way. The efforts are known as Dart: http://www.dartlang.org/
For all I can tell, Dart largely uses the syntax of JavaScript minus a couple of its quirks. Apart from that, it also is nicer for the virtual machine and will thus likely run faster (unless of course you compile Dart to Javascript and use a JavaScript VM; which is offered as a compatibility option). But of course any hardcore JavaScript nazi^W enthusiast will not like anything that claims to be better than JavaScript. Whereas for me, they don't go far enough. In particular, they still don't provide enough "classpath".
What browsers / engines already support ES5 [strict]?
All the major browser vendors more or less have had ES5 fully implemented for a few years now (though IE 9 doesn't support strict mode). kangax created this compatibility table representing the existence of ECMAScript 5 features in major browsers and other JS implementations. It will even list the availability of those features in the browser you visit the page with. It doesn't test conformance, however.
Kris Kowal created es5-shim.js, which provides as much of the functionality of ES5 as possible to ES3 compliant implementations. Of course, not everything is possible but the goal of the shim is to allow code to gracefully degrade.
AFAIK, the only implementation of ECMAScript 5 is BESEN. It's a bit disappointing, really. BESEN was created from scratch, by a single developer, in just a couple of weeks. Google, Microsoft, Apple, Mozilla and Opera on the other hand, with all their developers, all their money, haven't been able to provide an implementation after almost 11 months. And that is despite the fact that they have dozens of developers, have an already working implementation as a base to start from, were a part of the standardization process from day one (and thus had access to the specs long before the author of BESEN did), and most of the features in the ES5 specification were taken from already existing implementations in the browsers.
AFAIK, the only two features that in ECMAScript 5 that were not already part of JavaScript were the Properties API and Strict Mode.
This page of the ecmascript wiki has links to the bugs remaining in the major implementations in progress.