I see that many people have problems with cross-browser compatibility issues.
My question is why do browsers render the html, css or js differently?
Is it due to the DOM? The box model?
Why are there cross-browser compatibility issues when there are standards from W3C etc?
Are there any differences in the way the major Internet browsers display HTML content? Why is it that Internet Explorer, Firefox (Mozilla), Opera may display the same content differently?
What should I keep in mind when building a cross-browser compatible web site?
There are a lot fof reasons or incompatibility:
Specs are often written in response to the development of propriety features by specific vendors,
Specs can sometimes be poorly written, have ambiguity or were not written in anticipation of specific end-use cases.,
Browser vendors occasionally ignore the specification for their own reasons.
Additional factors:
A lot of this stuff is hard to implement, let along implement correctly,
It also has to be implemented to handle poorly formed HTML, backwards compatibility etc. Browser vendors sometimes sacrifice 'correctness' for 'interoperability',
History, politics & personalities.
I'm sure someone will answer this much better, but here's a start:
Yes, there are standards that are supposed to be adhered with respect to CSS rendering. The problem is, some browser editors (cough Microsoft cough) don't consider it a priority to implement the specifications correctly (or even fully, for that matter). Even, when the layout engine is being worked on to attempt to ensure compatibility, it can get quite nasty figuring out how things should be rendered correctly when mixing various CSS properties and units (see for example, the ACID test http://en.wikipedia.org/wiki/Acid3)
To have a cross-browser website, you'll basically have to check all of your website's pages render correctly in the browsers your visitors use (or that you support). Various tools such as Selenium (seleniumhq.org) can help with this.
You basically have to decide what you're going to do
design for the lowest common denominator (if it's IE6, there isn't much you'll be able to do)
design using validating CSS and using hacks (e.g. clearfix) to correct erroneous behavior in certain browsers
decide not to support certain browsers (IE6 being a prime candidate)
sniff browser and adapt display accordingly (NOT the preferred way to do it)
With respect to differences in manipulating the DOM, libraries such as jQuery help a lot as they hide the implementation differences from you.
For reference, it's a good idea to test your website in at least the following:
WebKit-based browser (Chrome, Safari)
Gecko-based browser (Firefox)
IE
Opera
It is an aftermath of the Great Browser War. Now Netscape Communications lies in ruins, but quirks opponents made to outperform each other is still remains in browsers' codebase, and people are still in development team. Consider watching Crockford's lecture, he gives some highlight on subject. (you will want to save the file instead of streaming it)
Everything that Hamish said, plus another major problem that he alluded to is how browsers handle incorrect HTML. For example, back in the days of IE4/NS4, the element was very problematic. If you didn't close a tag, IE4 would close it for you. Netscape 4 would silently disregard the table completely.
This is still true today where one browser will fix incorrect markup differently than another. Yes, the markup should be corrected, but browsers will try their best to render something.
The standard specifies how HTML/CSS markup should be rendered into displayed as visual elements. It does not specify how the rendering should work specifically. Many different people and companies have created different ways of rendering markup visually. Since HTML rendering is an extremely complex task, of course they didn't all converge on the exact same solution. All rendering engines are aiming for the same goal, but often the spec is vague enough to allow for small differences (be it just pixel level), and bugs are inevitable as well.
Add to that that back in the days browser vendors cared less about standards and more about gaining market share quickly and that certain companies have been very slow in turning around to embrace standards (you know who you are).
In the end, specs, which are quite complex, and browsers, which are even more complex, are written by many different people; you can't expect absolute perfection to arise from this process. And perfection is not the goal of HTML either; it's meant to be a simple, vendor and platform independent markup language to present information on a variety of devices, something it does remarkably well. If you need pixel perfect results, you need to go with a technology that was meant to provide this, like Adobe Flash (which is neither platform nor vendor independent nor simple).
Try to look at it from the glass-half-full perspective: Thousands of different people have written millions of lines of code doing vastly different things on many different platforms with many different goals and focuses, and yet in the end all render HTML markup almost identical with often only tiny, virtually irrelevant differences. There are of course weak spots in every engine and if you happen to hit them all at once, your site will break in every browser in different ways. But this is possible to avoid with a bit of experience.
Related
Let's say I outsource the development of an HTML/JS/CSS/AJAX web app targeting ONLY modern browsers. If it matters, assume there are 20 unique templates used in creating the application (to give an idea of the size of this application). My understanding is that much time/money is spent hand tweaking the code to make it consistent among browsers. I'm interested in ways to minimize this expense.
As of June 2011, Google Chrome Frame is advertised to not require administrator privileges for the user to download and install for IE 6-9, which essentially runs Chrome as a plug-in inside IE to avoid browser incompatibility issues with IE (substituting potential compatibility problems with Chrome, which should be much less than IE).
If I were to direct the developers to target only modern browsers minus IE, requiring all IE users to download Chrome Frame instead, would this path translate into any significant development cost/time savings? (My users are engineers and may be willing to accept this tradeoff since this application is not offered elsewhere.) I just don't have a feel for how much effort is made for IE versus other (modern) browsers, and wondered if anyone with experience could comment whether this makes cents (pun intended) or is simply crazy.
Also, any downside to doing this?
You will save time and money. I have done something similar for our in-house application. The site runs only on webkit browsers (chrome and safary).
We save a log of time, because the css and JavaScript can be more efficient, and most importantly, we do not have to test every change on 6 different browsers. This is very liberating.
If your users allow you to exclude IE, i recommend it.
It all depends on your application and developers. With enough knowledge it's possible to write code without even checking in IE until the end but only keeping it in mind and have 99% of things as expected in ie8-9, 80% in ie6-7.
If your users are engineers I can hardly imagine them using ie in the first place and even if so definitely not ie6/7.
Even if you don't go with Chrome-frame, given above points, if you're willing to go with slight to mild visual design degradation you can get away without specifically targeting ie...
Here's a little ie9 promo for ya :)
http://varonasf.com/ie69/
(only works in decent browsers)
This is the design decision behind Google Frame. You always have the choice of either designing for the lowest common denominator, i.e. IE6, and having a limited function site, or designing for a reasonable HTML 5 standard and forcing users to upgrade.
...allowing users to access modern web technologies like HTML5 on
legacy browsers.
http://blog.chromium.org/2010/09/google-chrome-frame-stable-and-speedy.html
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".
I'm not a JavaScript wiz, but is it possible to create a single embeddable JavaScript file that makes all browsers standards compliant? Like a collection of all known JavaScript hacks that force each browser to interpret the code properly?
For example, IE6 does not recognize the :hover pseudo-class in CSS for anything except links, but there exists a JavaScript file that finds all references to :hover and applies a hack that forces IE6 to do it right, allowing me to use the hover command as I should.
There is an unbelievable amount of time (and thus money) that every webmaster has to spend on learning all these hacks. Imagine if there was an open source project where all one has to do is add one line to the header embedding the code and then they'd be free to code their site per accepted web standards (XHTML Strict, CSS3).
Plus, this would give an incentive for web browsers to follow the standards or be stuck with a slower browser due to all the JavaScript code being executed.
So, is this possible?
Plus, this would give an incentive for web browsers to follow the standards or be stuck with a slower browser due to all the JavaScript code being executed.
Well... That's kind of the issue. Not every incompatibility can be smoothed out using JS tricks, and others will become too slow to be usable, or retain subtle incompatibilities. A classic example are the many scripts to fake support for translucency in PNG files on IE6: they worked for simple situations, but fell apart or became prohibitively slow for pages that used such images creatively and extensively.
There's no free lunch.
Others have pointed out specific situations where you can use a script to fake features that aren't supported, or a library to abstract away differences. My advice is to approach this problem piecemeal: write your code for a decent browser, restricting yourself as much as possible to the common set of supported functionality for critical features. Then bring in the hacks to patch up the browsers that fail, allowing yourself to drop functionality or degrade gracefully when possible on older / lesser browsers.
Don't expect it to be too easy. If it was that simple, you wouldn't be getting paid for it... ;-)
Check out jQuery it does a good job of standardizing browser javascript
Along those same lines explorercanvas brings support for the HTML5 canvas tag to IE browsers.
You can't get full standards compliance, but you can use a framework that smooths over some of the worst breaches. You can also use something called a reset style sheet.
There's a library for IE to make it act more like a standards-compliant browser: Dean Edwards' IE7.
Like a collection of all known
javascript hacks that force each
browser to interpret the code properly
You have two choices: read browser compatibility tables and learn each exception a browser has and create one yourself, or use avaiable libraries.
If you want a javascript correction abstraction, you can use jQuery.
If you want a css correction abstraction, you can check /IE7/.
I usually don't like to use css corrections made by javascript. It's another complexity to my code, another library that can insert bugs to already bugged browsers. I prefer creating conditional statements to ie6, ie7 and such and create separate stylesheets for each of them. This approach works and doesn't generate a lot of overhead.
EDIT: (I know that we have problems in other browsers, but since IE is the major browser out there and usually we need really strange hacks to make it work, css conditional statements is a good approach IMO).
Actually you can,there are lots of libraries to handle this issue. From the start of the time, javascript compliance issue always was a problem for developers and thanks to innovative ones who developed libraries to get over this problem...
One of them and my favorite is JQuery.
Before JavaScript 1.4 there was no global arguments Array, and it is impossible to implement the arguments array yourself without a highly advanced source filter. This means it is going to be impossible for the language to maintain backwards-compatibility with Netscape 4.0 and Internet Explorer 4.0. So right out I can say that no, you cannot make all browser standards compliant.
Post-netscape, you can implement nearly all of the features in the core of the language in JavaScript itself. For example, I coded all methods of the Array object in 100% JavaScript code.
http://openjsan.org/doc/j/jh/jhuni/StandardLibrary/1.81/index.html
You can see my implementation of Array here if you go to the link and then go down to Array and then "source."
What most of you are probably referring to is implementing the DOM objects yourself, which is much more problematic. Using VML you can implement the Canvas tag across all the modern browsers, however, you will get a buggy/barely-working performance in Internet Explorer because VML is markup which is not a good format for implementing the Canvas tag...
http://code.google.com/p/explorercanvas/
Flash/Silverlight: Using either of these you can implement the Canvas tag and it will work quite well, you can also implement sound. However, if the user doesn't have any browser plugins there is nothing you can do.
http://www.schillmania.com/projects/soundmanager2/
DOM Abstractions: On the issue of the DOM, you can abstract away from the DOM by implementing your own Event object such as in the case of QEvent, or even implementing your own Node object like in the case of YAHOO.util.Element, however, these usually have some subtle changes to the standard API, so people are usually just abstracting away from the standard, and there is hundreds of cases of libraries that abstract away.
http://code.google.com/p/qevent/
This is probably the best answer to your question. It makes browsers as standards-compliant as possible.
http://dean.edwards.name/weblog/2007/03/yet-another/
Most people talk about progressive enhancement right now as serving browsers with javascript (enhanced version), and browsers without javascript (simple version).
But there is such a big difference in javascript performance between browsers that it may be useful to apply that term to support for choosing between javascript based features between browsers.
In a complex web app with numerous non-absolutely essential features (and animations), is it worthwhile to start thinking about cordoning them off for say, these sets of features should work in all browsers, and these sets of features only in Chrome and Safari, and these in Firefox and Chrome and Safari and Opera, and so on, because enabling certain features in certain browsers would be too slow.
Sometimes I feel like the user experience would improve if they did not have access to certain non-essential features. For instance disallowing IE users from resizing certain panels that Chrome users would be able to resize.
I have not done this myself, but i can see that it makes a lot of sense if your budget allows for it (and you can't control your user's browser choice)
At the end of the day, IE users may be using a slow browser, but they are still your users. So if you want to give all your users the best possible user experience, it may be worth it to spend some time giving IE users a different version of the application to give them a higher level of performance.
An application that is fast for 99% of your users is undoubtably better than an application that is fast for only 30% of your users. The only question is what's more important - the user experience, or your development time (and take into account that in a few years, the average user will be running faster browsers on faster computers)
Any such work should be driven by benchmarks though, since my experience is that you will often be surprised by what part of the code is slow and what part of the code is fast.
As an aside, Lombardi Blueprint has a very interesting approach, although likely impractical outside of GWT. They have layout algorithms written in java, written such that they can be run both on the client side (via GWT) and the server side (via a standard jvm). Consequently, based on the benchmarked performance of your browser, they are able to dynamically switch between doing the layout on the client side (for fast browsers) vs doing the layout on the server side (for slower browsers).
That sounds like a maintenance nightmare.
I realize that there are some web applications where it just doesn't make sense to have an html version. That said, if it's possible I would start by building an html version of every page first, then use JavaScript to enhance the user experience.
IE is less performant than Safari, Chrome and FF when it comes to JS - but have you really developed a page that is unusable in IE with JS turned on? I just haven't seen it - in the wild I think the various JS implementations are fast enough.
Two different issues with the browsers these days:
Speed. My experience has been that IE 7 works fine, just much slower than the rest. My fix is to give more frequent UI progress updates to the users. Since the UI updating takes time, I minimize the updates on the faster browsers. Eg on IE I update the screen with more feedback after processing another 50 events. For other browsers, after processing 200 events.
Lack of feature. Eg canvas. But it is big expense to build multiple sites. And test them too. So I spend my budget on 1 version for all current desktop browsers. And make additional sites for mobile esp iPhone.
HTH,
Larry
What I do is to write a basic javascript file that has the common functionality, going to the lowest denominator (javascript 1.5). I then have other files for more recent versions of javascript, and those will replace functions in my javascript objects, so that I can progressively add more support.
If I want to use the canvas tag, then I can add that in a different file, since IE and Firefox/Opera/Safari differ in how they create the canvas element.
This is not a joy on maintenance, but if I want to use the new html/javascript features then this seemed to be the best model.
I concur with Andy. Providing different version of an application to different browsers is a potential maintenance problem down the road. I have always found it a better bet to provide one version of an app, that works in all browsers. For example, I try to avoid browser sniffers. The application might not be the coolest one, but it works for everyone and is easier to maintain.
This sort of stuff is easier now with all the nifty Javascript libraries that abstract some of the browser differences away. Besides, you can do a lot of stuff in the older browsers. It's just done "differently" ;)
So let's say that you build a decently-sized application. You have browser-sniffing galore to determine what features will be on and which will be off. You sniffed for Opera 9.x, and now (today actually) Opera 10 comes out. You have to go and update every sniffer on every page. And then another browser comes out soon... and another. You are going to spend all your time, determining what browsers you support and what features to support on them.
I use multiple browsers in a day. So when I go to your site, I am going to see three different interfaces. I will be confused, since the features I expected to be there, or the behaviors I expected will not be there. Eventually, I'll get frustrated and never go to your site again.
Also, there is more to how quickly some piece of JavaScript runs than just the browser. I still have an old Pentium running Firefox 3.5. Sometimes, it can be painfully slow.
I think the answer is that you need to categorize your code into speed categories, not just categorize into browser capabilities.
In other words, give your site tiers of features, first tier is basic html, second tier is javascript usability improvements, third tier is javascript animation eye candy.
Then do a combination of allowing your users to step down a tier whenever they want to, "Click to turn off animations!", "Click to turn on animations!", "Click to view in basic html", and choosing to default to certain speed categories based on browser for speed reasons (e.g. if IE7 seems to evince speed issues with the full animations on, make it default to the second "javascript usability improvements" tier).
Perhaps I'm just unaware of the competitors, but it seems when it comes to client-side scripting in the browser and DOM, Javascript is it. I know there's VBScript, but it really isn't even in the same ballpark as JS (not even cross platform, for starters).
I'm just curious about how this came to be. Surely there would be a general desire for a new language to replace Javascript: built from scratch to do all the things Javascript has been bent and moulded into these days (look at the reliance on JS Libraries).
Momentum. JavaScript has been around for 15 or so years, and browser manufacturers have worked for 15 or so years to make it work in their browsers.
If a competitor came along, it would need to really bring something new to the table in order to convince everyone to a) adopt it, b) live with locking out all the users of older browsers like IE7, Firefox 3.0, Chrome 1.0 etc. and c) find replacements for all existing libraries like jQuery, prototype, extJS etc.
In short: we don't need another Standard, let's rather improve JavaScript and build on the rich foundation that already exists instead of starting back from stone age again.
There is! Ones that spring to mind are Flash, ActiveX, and Java... But these all have their drawbacks. Mainly security and integration with the browser/DOM.
Flash and Java live in their own little world, by design (and to address security issues). They can't alter the HTML around them. ActiveX has access to the DOM, but also everything else on your computer.
JavaScript seems to have found a nice balance between flexibility and security, it can trivially interact and alter the pages HTML/CSS, do "safe" networking, has a decent standard library (which has things like JSON, XmlHttpRequest'sih networking, DOM manipulation, and so on). Most importantly, it's available in basically all vaguely-modern browsers, on all platforms, in a consistent manner (compared to CSS)
There are problems with JavaScript, but nothing major. The biggest is the performance. Load a comment page on Digg and watch your CPU usage. Chance are it will be 100% of one CPU core. There are projects to improve this, like SquirrelFish, TraceMonkey, and other strangely named things. But the performance is adequate to do some extremely impressive things (Google Spreadsheet, for example).
Basically, JavaScript is great, and it's drawbacks aren't nearly as big as the other competitors.
JavaScript won because it was introduced by Netscape in the period when they had above 90% percent market share. IE and other browsers had no choice but to support it also.
If a new language should be introduced, it would have to be either by agreement between all major browser vendors, or in a period where a single browser have enough market share to push it through.
Microsoft could probably have pulled it off some years ago when IE has an extremely large market share (before the rise of Firefox and Safari), but they chose instead (for strategic reasons) to let the browser stagnate.
Today, a new language would require agreement between at least Mozilla, IE and Safari to gain traction, and I think that is highly unlikely. The browser vendors have invested a lot of ressources in optimization, compatibility testing and so on for JavaScript - why should they want to start from scratch with a totally new language - and have to support two languages in parallel for decades to come? The cost greatly outweights any benefits.
Anyway, it is quite unrealistic to believe that a new language designed from scratch could be significantly better than JavaScript.
Show me another language that isn't reliant on libraries?
C, C++, C#, VBs, ... all rely on libraries. The only difference is that they often come with a standard set of libraries.
So do we really want is a standard set of libraries? What we're currently getting is a range of library sets (JQuery, prototype, extjs, mootools, etc). This is a good thing since we the developers get to choose one that suits our needs. In addition these libraries can be included and evolved without changes to the client-side component.
I can think of no compelling language feature missing from Javascript. By compelling I mean so earth shatteringly important that I'd be willing to alienate those browsers that do not support it.
Standardized (ECMA-262)
Common syntax and relatively simple to master
Good browser support
Extendable
Still being developed
Relatively quick based on how much data it needs to process sometimes.
If a good competitor had arrived before 1999 (ECMAScript 3), it would probably be a tie between those two.
There are other languages for client side scripting, but AFAIK, none are integrated into a browser.
Both Flash and Silverlight have their own Languages. Flash has ActionScript, while Silverlight has many and all that work under the DLR including Python and Ruby.
To your second point as to why, more specifically you mention reliance on JS libraries as a flaw in the language; Libraries are popular, not because the language if broken, but because the standard API is broken. The existence of such great libs builds on the power of the language.
There is nothing particularly wrong with JavaScript, it has some features that up to very recently would have been esoteric or academic. First class functions for example.
Also, ubiquity / mass existing runtime deployment is a very compelling feature. ;)
I recommend you to view Douglas Crockford’s presentation about “The JavaScript Programming Language” to learn about the history of JavaScript.
I think Javascript (ECMAScript) with its C like syntax is so popular for some of the reasons C is:
Relatively small number of language
keywords (easier to learn).
Concise and efficient syntax (quick to write).
Easily extendable
through external libraries and APIs that do
not pollute the basic language (ie Browser DOM,FilesystemObject etc).
Creating a new language that will provide many of the current libraries "built-in" is always risky as it starts to limit future applicability of the language and makes learning the base language harder.
This would be even more problematic for a client side browser language because the language designers can't possibly know how the language may be used in the future.
I think Javascript the language is fine in its current role as the "glue" that links so many other client sode technologies.
There are no other competitors because while Javascript is not perfect, it does the job.
I guess because the demand for it would have to be huge for browsers to implement it.
After all, it's the browsers that process and run the JavaScript and you'd have to have a large amount of sites using the language in order to make the browsers interested in implementing it. Then again no-one would use it if there was no browser support in the first place.
i'd say that this is because client side web development is still a very young branch of programming.
if you look at it only now it has become more widespread since we moved to faster "intertubes" :) and we're not using modems anymore.
and the problem for clent based web development is that it's not up to the developer what platform he'll use but it depends on the browser manufacturers.
and they change slow.
VB script's demise was in my opinion its VB-innes. too much unnecessary stuff.
As for javascript it will mature, but it's a start.
Browser support. If its not an MS tech the it most likely will not go into IE. If it's not in IE then no one can use it. If it is an MS tech, then most likely only IE will have the right to use it as it will be closed source and proprietary. If only IE supports it then only some developers will use it.
To challenge JavaScript it must work just as easily and more consistently across all of the major web browsers. Without browser support any new client side web tech is destined to fail.
I think it has to do with standardization, because durring the last browser-war (ie v. netscape) there were two, Netscape's ECMA (+1 Geek point for you if you knew this was the real name for JavaScript) and Microsoft's JScript, obviously ECMA (JavaScript) won out and became the defacto standard.
Now, we have another browser-war in progress and each of the 2 (3 if you count Chrome 12% FFS) major competitors 3 fully (with a few edge-cases) support JavaScript.
My guess is that its ubiquity and ease of integration in any new user agent project. It comes built into almost all browsers so you dont have to download/install/configure anything to have it running. once you look at user agents off desktops (wii, iphone, windows mobile, n95 etc) the availability of any of the contendes dries up quick - so you code for html and javascript becuase it will work most of the time.
I agree with Michael, we should improve Javascript, not worry about competitors because there aren't going to be any, in fact even Javascript 2.0 seems so far from reaching reality.
Since Javascript is such an ambiguous language, we're able to create libraries (jQuery) and even abstractions (Objective-J) and not worry about all the problems that Javascript has at its heart.
After so many years we don't even have CSS implemented same in all the browser, same goes for the JavaScript, IE has one model and rest of browsers has another Model (I mean like Event Handlers and attaching events).
If new competitor comes, it has no chance, neither it has so much time as css and javascript had.