Develop Reference

what has replaced the document.domconfig in javascript

document.domconfig is obsolete and removed. Any heads up on what it was replaced with? Or how can I get the DOMConfiguration which is also obsolete?

Based on the javascript tag and lack of comments to the contrary, I'm assuming this question is about web browsers.
document.domConfig (and the related interface DOMConfiguration) was introduced in W3C DOM Level 3 Core in 2004.
The standard was not created only with web browsers in mind, as a matter of fact none of the implementations required to become a W3C Recommendation were part of a web browser.
So when the web browser renaissance began, a version of the DOM spec specifically for web browsers was created, now known as DOM Living Standard. Since there were no implementations of DOMConfiguration (indicating lack of interest from implementers and presumably web developers, particularly because many of the features are not relevant to the HTML DOM), the feature was simply pruned from the specification.
It was not replaced by anything in particular; there was nothing to replace.
If you asked "I could do X with domConfig, how do I do it in a web browser" you might get a better answer, but for a generic question about an interface with a dozen rather obscure options I guess this is what the answer should be.

Different browsers have separate implementation of JavaScript [closed]

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 9 years ago.
I am new to JavaScript. I am referring to a page on JavaScript framework: What is a JavaScript framework?
I know JavaScript is for the web client side. It is a object-oriented script language. The link above writes:
Using JavaScript, however, is not an easy task, primarily due to the complications that arise when trying to provide support for multiple Web browsers.
Like HTML and CSS, different browsers have separate implementations of JavaScript, and it can be a nightmare to ensure that your JavaScript code is cross-browser compatible.
The second part says different browsers has different implementations. Why?
Since JavaScript is just a language like Java, C etc. Why do different browsers need different implementations?
As long as the JavaScript language specification is released, each browser should follow the language requirement. So why they have different implementations?
What does the implementation here mean?
EDIT:
JavaScript is NOT a object-oriented language! It is a language based on objects!

"Implementation" here is the engine that was implemented by a browser vendor according to ECMAScript specification.
As long as the java script language specification is released, each browser should follow the language requirement
And they do
So why they have different implementations?
Because they follow the same specification but build their own engine.

That's just the way it is. Not every browser uses the same JavaScript engine, click the link if you want to read some interesting history.
They all try to be the fastest. And yes they should all follow the exact same specification, and I'm sure they have followed the exact same specification, but there are still people involved, and they might interpret the specification slightly differently.
These engines are being developed in parallel (at the same time), as none of their developers have time to wait for the others to develop something first, and then check to see if they can comply with the exact same interpretation of the specification as their competitors.

JavaScript is an ECMA standard programming language and does not need to run in a browser. The browser has a JavaScript enginge that runs the script for you but not all browsers run it the same way.
Notabley is the way IE and other browsers handle events and new features are sometimes not supported. IE implemented things like innerHTML wich was not ECMA standard but because of it's popularity other browsers adopted it. It might be part of the standard now but I'm not sure.
The reason for this is that when NetScape came with JavaScript support IE implemented it as well but with other (extra) features. Since they both try to compete to be the "better" browser they didn't work together on making a standard.
A good source for JavaScript usage in browsers is MDN It usually shows you browser support for JS methods and properties as well as some code to add some support for browsers that don't support certain features (like DOMParser parsing text/html)
In the last couple of years IE has made a move to be more ECMA complient so hopefully in the future we would have to rely on less and less feature detection in our JavaScript code.
You still have a problem that JavaScript is a still evolving language and more and more features are added. When they are new than browers will still implement it differently or not implement all featueres (like webcrt). You might also have to support browsers that are a couple of years old and a lot of things change in a couple of years.

Why is javascript backwards compatible to a fault?

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

why server side Javascript is not widely used? [closed]

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 12 years ago.
we know JavaScript is one of the most popular and widely used language in front end.i wonder it is not widely used in back end ?

It's becoming more widely used thanks to Google's V8 engine. Take a look at Node.js. I think poor performance limited it's effectiveness before.
Node.js lets you write multi-threaded custom web services in the blink of an eye and in a mostly OOP manner. I think you'll see that Javascript on the back-end is just beginning it's run.
I think the only thing holding it back is — as others have said — the lack of a neatly packaged and standardized (for Linux at least) drop-in solution. This solution would then need to be picked up by the major hosting companies and added as part of their product offerings for it to really take off IMHO. If that happens then I think you'll find that it will explode into the back-end server space.
Microsoft has offered the ability to program back-end systems with "Javascript" (AKA JScript) since 1998 with it's ASP offering. You still can develop ASP.NET applications with JScript. So it's nothing new. I think the reason it isn't widely used for ASP or ASP.NET applications is because VBScript is the "default" and C# seems to be the preferred language for more experienced professionals. But there is nothing stopping you except company policies which often restrict developers to a single language for corporate development. One reason JScript might not be used much by corporate entities is that it "appears no longer to be actively developed." In fact Microsoft never really "marketed" JScript to developers. Or at least not nearly as much as they did C# & VBScript. So I think that may have held it back.

JavaScript is popular and widely used on the front end because it has critical mass, not necessarily because it's an excellent language. Nobody makes the decision to write JavaScript for client-side code; they simply must, because every browser supports it. On the back end, other languages (Java, PHP, Python, Ruby, ...) offer advantages that JavaScript can't.
Edit: In 2022, I received reputation for this answer, which inspired me to revisit it. Twelve years later, of course, JavaScript is commonly used on the server side, although in many cases it's a compilation target rather than being used. The engine for this has been Node.js. Along with a language like TypeScript or PureScript, you can achieve good performance and reasonable developer ergonomics, as well.

I'm not an expert on this, but Douglas Crockford says in "Javascript: The Good Parts" that JS essentially became popular in the browser by accident, not because of merit.
"Javascript is a language with more
than its share of bad parts. It went
from non-existence to global adoption
in an alarmingly short period of time.
It never had an interval in the lab
when it could be tried out and
polished... when Java applets failed,
Javascript became the 'Language of the
Web' by default. JavasScript's
popularity is almost completely
independent of its qualities as a
programming language."
Different browsers implement it differently, and it's harder to say what's correct than it is for languages with a standard interpreter.
It does have good features, as Crockford's book explains, and node.js may prove that it's great for server-side development. But so far, where people have had choices, they've mostly chosen other languages.

Short answer: Because there are far better alternatives.
Long answer: Because it is wholly interpreted (and often not well - e.g. IE6), provides no standard I/O mechanisms other than what the environment gives, has a loose grammar that results in difficult to verify code, and many people find prototype-based OO a lot harder to deal with than class-based OO.

I'd say it's just an accident of history. Javascript was born at Netscape as a client-side language and never made the transition.
Comparing it to the prominent server-side web languages today, I think the most obvious difference is that the batteries aren't included with Javascript. There is no standard library.
Compare that to Python, PHP, ruby, etc which all have fantastic standard libraries that make web programming far more palatable.

On the server people are not obliged to use a specific language, and JavaScript is so free-form that code becomes very difficult to maintain.
That's why the largest percentage of people choose something else.

I think the answer might be that what's good for client-side isn't always good for server-side. For example, Javascript (ECMAScript in general.. also ActionScript) is a very lax and forgiving language, that allows you to get away with lots of stuff. In the client-side this is often not only acceptable but also preferable. You often want your UI to be as smooth and forgiving as possible, to improve user experience.
On the server side, however, it's usually a different story, and that's why, I believe, the languages that dominate that side are more strongly typed and rigid.
There's also the issue of scale. What works for the generally smaller code-base of a client-side UI application doesn't always work for the server side, which has to deal with a host of issues that aren't really a major concern in the client-side. e.g. performance, packaging, scalability - these are much more important to server code than to client code (usually) and so it's understandable why people would not choose JS for server side work.

Why is there no OFFICIAL JavaScript reference? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I tried to search for a JavaScript reference, but there's none available. The best two suggested sources are MDN (Mozilla Developer Network) and ECMA (https://262.ecma-international.org/12.0/)
Why?

It's not like there is an official JavaScript release. All the browsers have made their own JavaScript engine - some are using the same though. But especially Internet Explorer has its own version that doesn't support a lot of what the other browsers support, making it very difficult to make a general JavaScript reference.
Edit:
While I know there is an official ECMA standard and development team, my point is that it doesn't really matter as long as browsers (Internet Explorer) doesn't live up to it. At the end of the day, clients want JavaScript to work for Internet Explorer too. They won't care about the ECMA standards, they just want it to work. This is where JavaScript libraries come into the picture, but that's another story.
It's the same issues with HTML and CSS, we can't use these tools for active development until:
All browsers support them.
We supply the browsers with code to make them support it.
It's okay it doesn't work in all browsers.
Edit2:
Internet Explorer is getting close to the grave with the new browser project from Microsoft: Edge. This, however, doesn't really change the overall picture. We still have a lot if different browsers we need to support. Developers are constantly trying to push the boundaries of what's possible. This means that we often have this issue, some browser version we want to support doesn't support some feature of the standard (which usually is a bit fluid), which means we need to make some workaround or use frameworks that implement the missing built in features.

You can try with the official ECMAscript site,
http://www.ecmascript.org/
but the useful thing is actually the implementation of each browser.
I like this cheatsheet from Danny Goodman's JavaScript Bible a lot:
http://media.wiley.com/product_ancillary/12/04705269/DOWNLOAD/9780470526910_Appendix_A.pdf

I would say this one is the "official": https://developer.mozilla.org/en/JavaScript
You also have the ECMAScript Language Specification, 5.1 Edition (or as a PDF, the definitive specification).
And from Microsoft: JavaScript Language Reference: "This documentation explains the Microsoft implementation of JavaScript, which is compliant with the ECMAScript 5th Edition language specification. It also provides additional features that are not included in the Ecma Standards."

If you're using ECMAScript for the web (which 99.9% of people are), then beyond the basics syntactics of the language (covered in the ECMA-262 spec mentioned above), what you're probably looking for is a DOM reference - which is the ECMAScript API that's used to interact with web documents.
I'm very surprised noone has mentioned the DOM api sofar. Current W3C DOM standard is here: http://www.w3.org/TR/DOM-Level-2-Core/
(btw, as for the naming confusion - ECMAScript is the name of the official standard, and "Javascript" and "JScript" are Netscape and Microsoft's proprietary "forks")

Wikipedia's quotation:
Beginnings at Netscape
In November 1996, Netscape submitted JavaScript to Ecma
International ...
JavaScript is officially managed by Mozilla Foundation ...
So, in my opinion, the ECMA is the standard and Mozilla is the official one.

It is very difficult to have an "official" reference as long as there are implementations (in all browsers) and there is a specification (ECMAScript) but no conformance tests of implementations against the specifications.
Now though, we have the EMCAScript 5 conformance suite at http://es5conform.codeplex.com/ - and there seems some consensus that ECMAScript implementations will come closer together, making ECMAScript more likely to be the official reference for the language.

There is an official reference, it just isn't in a very convenient format. It is the ECMA-262 specification. It is a single, very large PDF document, instead of a searchable set of HTML pages.

Any revisions of JavaScript pages on MDC by a member of the Mozilla Documentation team (like Eric Shepherd) is official. JavaScript is officially maintained by Mozilla so only documentation by Mozilla is official. The only engines that support JavaScript are currently made by Mozilla and every other engine implements ECMAScript. JavaScript and ECMAScript have quite a few differences (for example, the awesome let statement).

I find the old-school Netscape 4 JavaScript docs very useful for this purpose. Although they're obviously totally outdated, and some of the DOM features in them like Layers are long gone, for the language basics they're really solid.
That's because before the days of IE supremacy and ECMA standardisation, Netscape's JavaScript was the definitive JavaScript. Other browsers pretty much had to implement exactly what you see in those old docs.
They're also much easier to read than the ECMA-262 document, which even by the standards of standards documents is an absolute horror.

By “official”, I think you mean “written by the people responsible for JavaScript”.
Just speculating here really, but the people responsible for JavaScript (the ECMA) don’t directly make any money out of it, and probably don’t have any particular skills in writing reference documentation. So they have neither the incentive nor the ability to write a good reference.
Personally, I like JavaScript: the Definitive Guide from O’Reilly. There’s a sixth edition coming out in November.

I really like Daniel Krook's apidoc, even though it could use some explanations and examples. I would really like to see a krook w3school mashup.