Why is javascript backwards compatible to a fault?

Question

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.

score 7 · Accepted Answer · edited Jun 20 '20 at 09:12

7

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.

edited Jun 20 '20 at 09:12

Community

1
1

answered Feb 08 '11 at 19:55

Matt Ball

354,903
100
647
710

2

Minor pedantic point: JavaScript is the Mozilla implementation of ECMAScript. Normally I use the two-interchangeably but in this context I think it's useful to point out the two. – Feb 08 '11 at 20:11
Also, I would still argue that the *language itself* (ECMAScript) is "backwards-compatible to a fault", but any language which is actually deployed lands into this category :-/ It takes a good bit of momentum to create a "breaking change" -- e.g. Python 3/Perl 6/Ruby 2 -- from the current "works well enough" specification/impl. Not that this means more features can't (and aren't) added (see JS diverging from ECMAScript in JS1.6+ or ECMAScript ed5 vs. ed3), but rather that *backwards-compatibility is a top requirement*. – Feb 08 '11 at 20:14
@pst: well, while we're being pedantic, JavaScript is technically [a dialect of ECMAScript](http://en.wikipedia.org/wiki/ECMAScript#Dialects) :) – Matt Ball Feb 08 '11 at 20:29

score 6 · Answer 2 · answered Feb 08 '11 at 19:13

6

Well a breaking change would break a lot of existing websites, which would make a lot of people very angry :)

answered Feb 08 '11 at 19:13

Adam Rackis

82,527
56
270
393

I don't understand how this would break websites. Why can't they just have 2 engines in parallel? Similar to how .NET runs versions 2, 3 and 4 on the same machine. – P.Brian.Mackey Feb 08 '11 at 19:14
2

.NET runs multiple versions because there is a single company behind it that only supports a single operating system. It would be very difficult to get every browser maker to support multiple scripting platforms. – Kristopher Johnson Feb 08 '11 at 19:19
True - which is why there's such a market for Flash and Silverlight, which *are* put out by a single company. – Adam Rackis Feb 08 '11 at 19:20
1

@P.Brian.Mackey: the .NET runtime was designed to have future versions, and Javascript implementations aren't. You'd be forcing people to update their browser to see a Javascript2 website, and that's something a lot of people seem not to be able to do. – Eric Mickelsen Feb 08 '11 at 19:20
2

@Eric Mickelsen Then this isn't really true -- .NET gets away with it by "knowing" which framework/CLR a particular assembly targets and separating the bytecode/CLR (quite stable, but *three incompatible versions* in a ~decade) from the languages (rather dynamic) which compile to the "stable" target. The ` – Feb 08 '11 at 20:17
1

@pst: the now-deprecated `language="..."` attribute of the script tag *did* once support that (or at least some browser vendors did) so you could say ` – Stephen P Feb 08 '11 at 20:29

score 4 · Answer 3 · answered Feb 08 '11 at 19:18

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.

score 3 · Answer 4 · edited May 23 '17 at 12:18

3

As a matter of fact, ECMAScript 5 is not fully backwards-compatible for the very reasons you mentioned.

edited May 23 '17 at 12:18

Community

1
1

answered Feb 08 '11 at 19:22

user123444555621

148,182
27
114
126

Nice. I didn't aware such differences slipped in. – Feb 08 '11 at 20:22

score 3 · Answer 5 · answered Feb 08 '11 at 19:28

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

score 2 · Answer 6 · edited May 23 '17 at 10:30

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

score 1 · Answer 7 · answered Feb 08 '11 at 20:02

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.

score 0 · Answer 8 · answered Mar 24 '12 at 20:06

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 is javascript backwards compatible to a fault?

8 Answers8

Lazy copypasta at OP's request: