Develop Reference

HTML5 Boilerplate vs. HTML5 Reset [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.
Hey everyone — HTML5 Boilerplate and HTML5 Reset are two HTML, CSS, and JavaScript templates with a lot of modern best practices built-in. Their goals are largely the same:
Fast, robust, modern Web development
HTML5 (duh!)
Cross-browser normalization (including support for IE6 and mobile browsers)
Progressive enhancement and graceful degradation
Performance optimizations
Not a framework, but the starting point for your next project
Obviously, they're very similar in function. In what ways are their implementations different (for example, perhaps IE-specific CSS fixes are achieved using different techniques)? Are they at all different in scope? It seems like HTML5 Boilerplate is a bit larger (build tools, server configuration, etc.), but it's hard to know where it goes beyond HTML5 Reset when it comes to the actual site that people will see.

In general, both projects set out to provide a solid starting point for developers working on web projects. They both get rid of a lot of the tedious, some-what error-prone boilerplate that many developers find themselves re-creating for each project. The details in how they go about it are slightly different, but for the most part, they achieve the same results.
HTML5Boilerplate has, as you noted, added in some build-script pieces to help developers follow best practices to speed up their pages in terms of server-side items, such as far-future expires headers, etc. where-as the HTML5Reset project is more focused on the semantics, content, and styling. For example, HTML5Reset has more example structure for the content of the page in HTML5 (to help show people how to use some of the new elements), whereas HTML5Boilerplate does not.
The response-time and page speed parts that HTML5Boilerplate includes get more and more important as more users find themselves on mobile platforms, and as Google increases the effect page response times have on page rank. There are lots of papers that show a small increase in the page response time has a measurable negative impact on how your site is used and perceived (especially in an eCommerce setting...often a 100ms slower page will get percentage less things sold).
On the CSS front, the majority of the reset style section for both projects is very much the same, with some minor differences in what the baseline is set to. The IE specific fixes, however, are largely the same, with HTML5Boilerplate asserting a bit more control than HTML5Reset over how IE styles some things like form elements (ie. check box / radio buttons and valid / invalid states)
Two major CSS areas that HTML5Boilerplate covers that HTML5Reset does not are common helper classes to assist with making sites more accessible, such as .hidden and .visuallyhidden, as well as some substantial adjustments to the print styles that serve to both make printing more similar across browsers, as well as some cost-savings and accessibility things like making background images transparent (to not waste toner), and adding the actual URL to links and the title to abbreviations.
I would highly suggest reading through both projects' info and how they do things in a side-by-side comparison because the similarities, and also the differences (and the reasoning behind them) is quite informative and has helped me to better decide what parts of each I wanted to use.
Ultimately, just like any "library" sort of project, you as the developer need to understand what you are doing and probably should tweak your baseline to meet the particular needs of the project.

You can use either one...
Like #murtaugh said (http://5by5.tv/bigwebshow/45) you don't need to learn anything when u first start with Reset. In my experience, working in an R&D department, when you need to demo or do quick iterations you can use the Reset (or Boiler if u already know it). When I need to build the product for deployment I turn to Boiler just because has more stuff.
Works for me but now because I know both I can easily use either one.

I actually almost want to say using the traditional reset.css is the best... I find no problems with compatibility in my mobile apps. However, I am developing these apps using the jQuery mobile framework.
So I guess it's really conditional as to what kind of tools you are using. Phonegap doesn't seem to have any problems compiling my code into all OS. And viewing my source code in emulators looks perfectly fine...
So I really don't see the point of a boilerplate unless you are trying to achieve polyfills.

I work in an environment where previous developers roped the company into using both JQuery and Prototype...and it's a mess. Not only do we have to work out of compatibility mode, but just think of the extra overhead that it causes. When debugging, Prototype "hijacks" debug messages in Firebug, which leads to even more work. And the maddening part is that I've been undoing this mess for months and am just starting to get close to being done with it....and just when I'm about to pull the plug on Prototype I always seem to find another section that relies on it...
It's for this reason that I argue every time against combinations of frameworks that have similar purposes. For example, no matter how cool you might think YUI Grids is, if you load the entire YUI Framework you best not be doing Jquery, Moo, or Prototype. You'd be just needlessly bogging yourself down. It kills the load time (which wrecks the user experience) and just gives developers headaches and needless work.
Look at this phase of your site like building the foundation. You have the opportunity to use anything you want to use, but you have to be careful not to "paint yourself into a corner" so to speak. So, use purpose-built and best in class tools that are available based on your resources. Don't just use something to be cute! We're lucky in that many very high quality tools are free, so we have a choice. But know that you're steering the direction of your site for the future, and you might be the person like me who has to deal with the consequences if your decisions are hastily made.
So, unless you're NEVER going to use another framework, I endorse Reset...or even just doing top quality standards compliant CSS.

Dojo vs YUI javascript framework

I want to know what you guys think of these 2 frameworks, in terms of:
robustness,
code quality,
core developers moving forward with new features,
cross browser problems,
module components,
easiest to learn and integrate
I already know and use jQuery, I recently found it lacking in terms of 'enterprise ready' components for large web app.
Now I don't want to start a debate on jquery, or why mootools is not in there, I want to know what you guys think of these 2 frameworks specifically.
Thanks!

Disclaimer: I am a Dojo committer.
Somehow nobody presented the Dojo side in this comparison — it is not a comparison without one, is it? Let me go over your points.
Robustness
Dojo is used in many IT projects by major international corporations. I personally participated in projects for VMware, IBM, Cisco, Reuters Thomson to name a few. Instead of forwarding you to the "marketing literature" I can show you the actual list of contributors: http://docs.dojocampus.org/developer/contributors — scroll down to see corporations that contribute (and use) Dojo.
We keep the list of individual and corporate contributors so our users can be sure that the IP lineage of Dojo code is clean — every contributor signs a CLA stating that he/she/it wrote the contributed code and/or has a right to contribute it under dual AFL/BSD license. So far we didn't have any problems with that.
As far as I can tell YUI is mostly developed by one company: Yahoo! YUI started to accept external contributions only two years ago being in development since 2005 and now requires CLA too.
I am not a stock market expert but something is always up with Yahoo!: one day it tries to forge an alliance with Google, next day it kills its search business and goes with Microsoft, even selling the whole company to Microsoft was discussed back in 2008 — who can predict what it will do tomorrow. Now in 2010, the share price went down since 2008 — is it going to be on sale again? OTOH some say that Microsoft would be a better mother for YUI, if it decides to keep it. Then again, Microsoft has its own software properties and not exactly a backer of open source JavaScript projects.
Unlike YUI Dojo is backed by several companies with IBM being the most influential one — several prominent committers were hired by this company. While Dojo has a strong corporate support, it is still a project driven by its community, by individuals. If any company or even several companies will experience market hiccups we will still plow ahead.
Dojo is distributed under dual AFL/BSD license and free for all uses. All officially released versions of Dojo are served by AOL and Google CDNs.
Code quality
I am biased :-) and I consider the code to be of a very good quality. As Dojo is an open source project you can always judge it for yourself, and improve it, if you feel up to it.
The source code is kept in Subversion with official mirrors maintained on Github (git), and Bitbucket (hg). For convenience there is a mirror on Launchpad (bzr).
Core developers moving forward with new features
Dojo has an active vibrant community, which keeps the wheel moving so to speak. Being one of the core developers I assure you personally that we will continue to move forward pushing the proverbial envelop even further.
Dojo has a proven track record of innovations, and we are not going to stop.
Cross browser problems
Currently Dojo 1.4 supports following browsers:
Firefox 2 support dropped. Firefox V3 and V3.5 supported.
Latest Safari (Safari v4) and latest Chrome (Chrome v3) supported, but not previous versions.
IE6, IE7, IE8 all supported.
Latest Opera (Opera v10) (Dojo core only).
The upcoming Dojo 1.5 (will be released in a few days) was extensively tested with following browsers:
Firefox 3.5/3.6
Safari 4/Safari 5 and Chrome 5
IE6, IE7, IE8
Opera 10.53 and later (Dojo core only)
To highlight the differences with YUI's A-grade browsers:
Dojo supports Linux in addition to Windows and Mac.
Dojo supports Google Chrome on all supported OSes.
Dojo supports Firefox on all supported OSes.
Dojo Core supports Opera on all supported OSes.
Personally I can add that I still test dojox.gfx (the cross-platform graphics package) on Firefox 2 — it involves Dojo Core and it works as expected. And I test Dojo Core on several exotic browsers like Midori.
Another difference is that Dojo can be used (and it is used) in desktop and server environments. Obviously browser-specific components are not used by those environments.
Module components
From day one Dojo provided classes, modules, and packages (collections of modules). Dijit provides widgets: packaged HTML + JavaScript with unified interface.
All building blocks are exposed to users, so they can create their own components, which will be 1st class citizens: they can be loaded like any other modules, processed by the builder (dependencies tracked, minified, CSS preprocessed, and so on), even exotic CDN builds can be done by users. Anything you can do with stock Dojo components you can do with your own components.
Dojo itself is split into 3 subprojects, which can be used separately:
Dojo (including Dojo Base as a single file)
Dijit: a collection of widgets
DojoX: even more widgets, and ~50 packages covering everything from cross-platform charting to encryption.
Easiest to learn and integrate
Dojo is just JavaScript and regular HTML/DOM (for widgets). It does not pretend to be something else, it is not a cult with a fuhrer at helm, it is not a "framework", which takes control of your app and forces you to do some bizarre things, Dojo doesn't want to "improve" "imperfect" JavaScript, Dojo doesn't want to masquerade a browser to be something else. Instead Dojo provides practical tools to make a programmer more productive, to facilitate RAD, to solve common problems, and to support useful techniques and methodologies.
Every experienced programmer usually has a mini-library of things that worked well for him/her in previous projects. He or she knows what to avoid and what to use. It "clicked" in my head when I realized that Dojo is this library on steroids — like several experts got together and carefully combined their personal libraries. Sure, it has a lot of different modules, but I can use only what I want for my specific project — I am not forced to use everything, and I don't pay for things I don't use. Not even an abstraction penalty.
If you know JavaScript and familiar with HTML, CSS, and DOM — you'll be right at home.

I think your reason for rejecting jquery sounds suspicious, and recommending a framework as "enterprise ready" is a backhanded compliment in my book.
However, I have a lot of experience with YUI (2 and 3) and I think it might fit your use-case.
Robust - YUI is used internally by Yahoo, so that should give some clues as to its robustness.
Code Quality - I'm a contributor to the project, and the code quality is very good. As it is open source you can take a look for yourself.
Moving Forward - It is backed by Yahoo (but also incorporates community contributions) so moving forward it is pretty safe. Again, you can track development and community involvement yourself.
Cross Browser - it supports all the Yahoo A-grade browsers
Modules - there are a ton, and (especially in YUI 3) it is easy to incorporate just the pieces you need. If you want mostly GUI modules, you'll still need to mix in some YUI 2 (which is easy to do). Widgets in YUI3 are coming soon, though.
Easy to learn and integrate - YUI has probably the best documentation of any JS library I've seen. However, YUI 3 is very opinionated about how you write your javascript. It is opinionated in a good way and gives you a lot of bang for your buck, but to just "drop in" to an existing project YUI 2 may be easier.

YUI has a great testing toolkit and doesn't pollute the global namespace. Also, YUI test results can be read by JUnit, which is a plus in my book. I haven't used Dojo so I can't comment on it in detail, but the way it integrates with the DOM is worthy of notation.

Knowing that JQuery is the easiest to use and immense popular, Dojo has its advantage of being integrated in Zend Framework. Also, the difference in being a library or framework counts.
- A library is about reusable functionalities, but a framework is about reusable behaviours
- A library is something you call/inherit from your code, but framework is something that calls your code or provide services for your code
- A library is a collection of components and classes, where framework is how abstract classes and components interact with each others.

Are HTML-based AIR apps equally fast/powerful v. Flex AIR, or just a "lesser" sibling?

I've got a HTML/JS (YUI framework) photo-organizer that needs access to the local FS. Should I move HTML/JS to AIR, or bite the bullet and "port" it to Flex AIR?
I know what the marketing says, but I want the real answer -- what an I "giving up" by going HTML/JS AIR? I'd like to get some feedback from people with deep experience building HTML-based AIR apps.

I don't think you'll see many issues in using the HTML AIR mode, AIR uses the Webkit engine under the covers iirc, which can work well enough, and has most of the same native features of the Flash/Flex built applications. You'll also see most of the HTML5 features you'd find in Safari. I would say if you need animations that Flash will generally run better than Canvas at this point... There's plenty of examples of ExtJS and other frameworks running on AIR.
As to what you are giving up, I don't think you'd lose anything from an HTML to HTML/AIR standpoint. You could gain a lot of what you gain in having an application in general based in Flash over straight HTML. In flex specifically controls and other features can be more readily tweaked than standard HTML controls. The animation tools in Flash are much nicer. ActionScript doesn't line up to JS on a one to one basis, so there may be issues with code. Dealing with remote content/data is actually a little nicer imho in AS over XHR, though only when dealing with XML.
From an administrative standpoint, going to AIR with HTML from an already written application is probably the shortest path. If you REALLY needed to, you could convert later, and a lot of the underlying logic would be worked out. Time to market would be shorter with whatever is closest to what you are already using more often than not.

Not really, since FS access is available with the HTML/JS version. However, the other route does open up some more native support for application development -- Animation for example, richer controls etc which you will have to live without otherwise. You will greatly miss the debugger and the profiler as also the design view when you move to complex applications. Also, note that if you are worried about sharing your source you probably shouldn't use the HTML/JS way.

What's going to replace HTML & CSS & JS? [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 11 years ago.
HTML and CSS are showing their age.
SASS generates CSS (because CSS isn't clean enough). Graphic Designers don't work in HTML, they work in graphics tools then have to translate it to HTML/CSS. JavaScript has to have abstractions like jQuery, and CSS has a bunch of hacks to even start approaching consistent predictable user experience.
It feels like people are doing some wonderful things despite the technologies, not because of them.
Surely there is a better way?!? Something more closely aligned with the task at hand.. of providing a fluid intuitive (consistent) user experience to let users achieve their goals.
Thoughts?

Nothing, I believe they are here to stay for next 10 years.
The Internet experience might be enhanced by technologies like Flash & Silverlight but what's valuable about Internet is not the technology but the information.
Therefore, breaking Internet compatibility for pure technological enhancement will never work.

BLTML: Bacon, Lettuce and Tomato Markup Language.
In the future, the web with only be used for posting tasty things we want to eat, so it makes sense to develop a language geared just for this.
The pictures of kittens with words on them will likely be supported with a gross hack .

Graphic Designers don't work in HTML
DTP designers don't produce paper and ink either. Design something and produce something, these are separable tasks - when you have an idea for a tv spot you still need lots of technology between your creativeness and the result, the same applies for the web.
Javascript has to have abstractions
like JQuery, and CSS has a bunch of
hacks to even start approaching
consistent predictable user
experience.
Oh man, js doesn't has to have, developers simply like to make their job easier, this rule applies to various programming languages, it's like saying python has to have django. Frameworks and libraries are over the language, they are not a must.
CSS 'has a bunch of hacks' because some browser producers don't give a damn about something called "standards", not because the language is badly designed.
Surely there is a better way?!?
Something more closely aligned with
the task at hand.. of providing a
fluid intuitive (consistent) user
experience to let users achieve their
goals.
What user experience is not provided with html,css,js? I really don't get your point, and what you expect from the Web.
Oh, and if you are like 'you know, you need flash for something or whatever', start getting interested in canvas.

HTML and CSS are here to stay for a long time yet!
While they may not be as intuitive to use for designers as say PhotoShop, well formed HTML is machine readable - this means that it can be used by humans AND computers. This is very important and useful. Imagine a web full of pictures that look beautiful but cannot be crawled or searched by Google?
HTML and CSS are superior because of the structured information that underlines them.

I don't think that HTML and CSS are showing their age, I think that browsers are showing their age. I like being able to describe what I want done, but not HOW to do it.
I guess what I want is browser vendors to use one rendering engine, or if nothing else, a SSL-type of certification for browsers. Kind of a global impartial body that's measures browsers on a quality bar-like scale.
Just like with SSL certification, it's done by a third party. I'm not sure what the pricing structure would be but I don't think you should have to pay for it. I think that it would make a great "works in this browser" logo like the Spam Free and Mal-ware Free logos we've seen popping up on sites over the years. Or perhaps an Acid1, Acid2, Acid3 passed logos for browsers.
I would argue that libraries like JQuery and Prototype exist because browsers all have their quirks. We just got tired of writing all that handling code, so some very smart people did this for us.

Personally I think HTML and CSS are very elegant, and while the W3C certainly isn't hasty, I think it's probably fair to say that a certain browser has been holding back design on the web more than the technologies themselves.
CSS3 has support for fantastic things such as web fonts with #fontface. Javascript engines are becoming increasingly speedy and allowing for things like John Resig's processing port which would have been unimaginable years ago.
We need to see users adopting new browsers at a faster pace, and we need to see vendors getting behind efforts to encourage their users to upgrade.
I think it's a mistake to think that abstractions are a negative thing, and indicate some problem with the base technology - technologies naturally evolve through abstraction. There's some inconsistency in your post in the sense that you decry the need for abstraction, but then mention that you desire consistency - that consistency across clients is achieved through abstraction. I no longer have to worry about how different clients handle the DOM - jquery does this for me. CSS hacks by the same token aren't really necessary, and it's quite acceptable to serve a different stylesheet to that browser; the rendering difference between the other mainstream engines are pretty minimal.
Please also consider that we're still using a lot of "old" technologies (Unix, c, c++ to name a few), because they are functional, elegant and well designed.

Worse is better. HTML and CSS are never going away because of the large volume of content that's written against that platform. Same thing with C. It's a terrible language, but it will always be with us because nearly all software is written in either C or C++.
A huge volume of JAVA means that's never going away. There's still a market for COBOL programmers.
It's a popular idea among some programmers to get really frustrated at a crufty system like HTML/CSS/JS, and think "Hay, let's demolish it and start over". Well you know, I could invent my own phone that is 100 times better, and with better sound quality than any other phone. That's the easy part. The hard part is having someone to call.
Like it or not, HTML/CSS/JS is the technology trio that became popular, and that means millions of people have invested trillions of dollars in producing content for the technology. Millions of people will be quite reluctant to throw that effort away because someone says HTML/CSS/JS sucks.
It's a mysterious thing figuring out what technology is going to become popular. It's not something you can control for the benefit of your own comfort. But at least, you know, there's such lovely computer science concepts as "abstraction", which if you can master it, will be your secret weapon. Jquery is an example, but it can be taken very much further.

The problem would not be to design something to replace HTML/CSS/JS, but to get browser vendors to adopt it. Good luck with that.
As central as the web experience and HTML are in my life and in your life, the only computer most people in the world use is their phone. The web just doesn't work well even on a multitouch touchscreen.
Just like you no longer enter your game using the ROM basic before playing it, and you no longer see text only screens around (well mostly), some day the web is going to be consumed by specialized devices or by specialized applications for your phone. Machine readable web, or in other words, web services. You can call that web 3.0 if you like.

I believe that the problem is not HTML, CSS and JS or their age (they are constantly evolving anyway). Theoretically you should be able to create one version of something and have it work exactly the same across different platforms. Which is where the problem lies: the platforms.
Saying those technologies are old and therefore need replacing is like saying C++ is old and therefore should not be used for game development. They are actually very appropriate and powerful tools for what they were designed for. Therefore I would predict that its not the HTML, CSS and JS that need to or will be replaced, but that the current platforms need to get their shit together (some more than others) and follow the bloody standards!
That said, they do need to keep evolving to stay relevant.

I think XML with XSL is the future. Graphical designer tools would come with their own XSL stylesheets, tailored to the strengths of the tool, and the tool would generate XML files that use the stylesheets.
But I'm no clairvoyant; what's going to be hot in the next 5 years, who knows. :-P

If you listen to Microsoft, Silverlight will feature prominently in the new web. Since it uses XAML, which is just a text file, it has the potential to be search engine friendly.
Others like Flash.
Of course I am sure that something else new will be invented in the future....

I think RIA's like Adobe flex/air/apollo and Silverlight etc will eat into some of the html market share , but not totally replace it.
Some of the issues that plagued RIA's like SEO related stuff, lack of back button support are being resolved.
The good thing with RIA's is that it is browser independent (as long as the user has the right plugin) , I could foresee future browsers launching with RIA support built-in thereby ensuring a 100% market penetration for apps built using them.

For documents and usual web pages, HTML and CSS are there to stay and evolve (Sass is nice indeed).
For applications, mobile code (javascript most probably) driving canvas-like graphics will help merge web apps and internet-enabled desktop applications.
— I wonder how ridiculous these predictions will look like in 10 years :)

Why are there no real competitors to Javascript?

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.