Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I'm preparing a presentation about JavaScript in different browsers.
I know that there are several issues with Mozilla. For example the constructor of the Date object will not accept the ISO date string. It will result in invalid date.
I've been looking for a errata which lists all known issues of this browser in one place. But I couldn't find such.
Q: Does anyone know some link or document that lists the issues of this browser. At least the most significant ones?
Thanks in advance.
What you seem to want is bug 445494 - a tracking bug for all known ECMAScript 5 compliance issues. Look at the open bugs that it depends on. There are apparently two strict mode issues left (disabling document.all in strict mode and throwing an exception if a variable is accessed too early), String.match and String.replace methods don't update RegExp.lastIndex property, some non-standard special treatment for the Array.length property and a few similarly small issues.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I am confused I thought that cancelBubble is IE-only Boolean property but found it in Chrome.
From early on, the Chrome folks took the approach of trying to be broadly compatible with existing code, which in some cases meant being compatible with code written using IE-only features. Another example of this is the global event variable, an IE-specific variable set to the current event during event callbacks (so callbacks use the global rather than an argument as they do with addEventListener). Chrome has supported that since the beginning for IE-specific code that relied on it; Firefox has only recently started supporting the global event variable. Supporting cancelBubble is in that same category.
They don't support every IE-specific thing (for instance, not attachEvent), so as to avoid messing with code trying to detect IE event handling and branch. But they support a lot of IE-isms.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Some things, like modern assembly languages, are meant to be easily read by the computer, and not by developers.
I'm wondering if the ECMAScript specification is similar in this sense, that is, it something meant to be read only by the compiler or by someone who wants to implement said compiler. Is that the case?
Or is it not the case, and much like the users of a tool (such as React JS) are expected to read its documentation, are developers who use JavaScript expected to read the ECMAScript specification?
I don't want this question to sound opinion-based, so perhaps a slight rewording: Is the ECMAScript specification meant to be developer-readable, in general?
Nobody is ever expected to read the specification. You'd probably need to at some point or another to try to understand certain methods and their behaviors, but no - the only thing most people use is documentation, especially MDN.
The specification is only really useful if you try to understand how JavaScript is interpreted (thanks Bergi), rather than just how to use it. Up to you if you want to read it or not, but no - you're most certainly not expected to read the specification, or anything for that matter - sometimes, self-learning is the most effective method.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
The page proposals:date_literal_syntax at ecmascipt wiki says:
Spec retracted 2006-08-28 following meeting on 2006-08-23; proposals for supporting a sensible date syntax have been folded into proposals:date_and_time.
However, that page does not even mention date literals at all.
As date literals would be very useful for some JSON vNext syntax (e.g. JSON5), I am interested on what's their current state, and why they were retracted.
As far as the proposal, I would say "Date/Time Literals are Dead". The article(s) referenced were last updated in 2008 (6+ years) while neither ES5 nor ES6-draft support such literals per the grammar rules.
Since there is no Date/Time literal in ES5, such cannot be represented in JSON5 as literals because it has a goal of being a "strict subset of JavaScript". JSON5 looks to expand JSON to encompass more JavaScript literal syntax1 constructs, but does not cover non-literal forms like new Date("ISO8601").
1 JSON is not JavaScript, despite sharing a word in the name; just a mostly-compatible serialization format. (Which is why JSON5 makes me go ugh! it complicates the format/processing while the biggest compatiblity target - JavaScript ed.5 - does not sanely rely on "eval" to handle JSON.)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Javascript : What are the different conditions when javascript work in IE but not in Firefox or some other browser?
one that i know of is that while using certain window events..
What other scenarios can cause javascript to not work properly?
The answer is too complex to fully list here. Use sites like http://caniuse.com that will tell you which JavaScript is available in which browser.
Generally speaking, all browsers implement JavaScript differently. Microsoft have long been stuck in their own world, implementing their own ways to do things, whereas everyone else seems to try and conform to the standards as much as possible. Microsoft are coming around to the "standards" way of doing things, and from what I hear, IE11 will be a massive step in this direction.
As already mentioned, you can use http://caniuse.com/ to find what you can and can't do in different browsers, but then you'll likely end up doing what many others have done...write your own API which works around these to achieve a task...which is a bit unnecessary, unless you can find a ground-breaking way to implement your API that will be beneficial to other developers.
APIs like jQuery already work around these differences. The aim with these libraries is to provide clean JavaScript, whilst being completely transparent from the underlying JavaScript implementation.
Also, look into "shim"/"polyfill" implementations. These are used when a core feature that is recognised as part of an ECMAScript version has not been implemented in the browser. These provide the implementation for you, if it is not natively supported.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I have heard that instanceof operator in java is a performance issue,
Is it true for Javascript too (IE6,IE7,IE8,FF,Chrome,safari,etc.)?
any links to authentic papers would be helpful.
In short: it seems to be browser dependent.
More detailed:
I have found this JSPerf test: http://jsperf.com/instanceof-performance/2 comparing a JavaScript instanceof check versus a boolean check for an existing/missing property in an object.
The overall result (beware of the small number of samples) is that in Chrome both methods are alike with benefits for instanceof. In FF, however, the property check is faster than the instanceof operator. Update Apr 2017: As #ngryman pointed out: In both, recent FF and Chrome versions, doing property checks seems significantly faster than instenaceof.
Would be interesting to extend that test with a case like checking if a string comparison like obj.type == 'MyClass' has a strong influence on the subject.
That's not true for Java anymore -- see here.
As for Javascript, I couldn't find any articles that discuss this, but I highly doubt that instanceof would be cause any performance issues. If you need to use it, I would say go for it, and then reconsider only if you're running into performance problems.
You could pretty easily make your own JavaScript benchmark similar to this one linked from Kaleb's link.
I wouldn't worry about performance of the instanceof operator myself, because JavaScript itself is rarely a reason of performance problems. DOM manipulations usually take much more time. However, if you need instanceof in a heavy used loop, I would suggest to profile it using FireBug profiler.