Yeah and we'll probably only have to wait another 5 years!
It's funny how .NET languages can have a consistent, predictable and precision framework built up around them and yet somehow we're supposed to believe that JS is better than bytecode.
Any toolkit that attempts to shoehorn a consistent experience on the web is doomed to failure. People have made efforts, earnest efforts, at solving the problem (dojo, ext, closure, capuccino). None have caught on and at the moment I'm assuming none will.
Bakground paragraph: I've been thinking about the issue since 2004 or so and always assumed that a widget toolkit would develop like it did for desktop environemnts and one or two would eventually win. The launch of mobile app development changed things. The kinds of apps being delivered were outright better than what equivalent web apps were delivering. Not the perf, I assume perf is going to be solved by better hardware and engine improvements, but what the apps accomplish. My conclusion is that every project has a semi-fixed budget of resources and that web developers burn roughly 50% of that budget on building a custom one-off interface solution for every project they work on. The obvious answer is components but component frameworks had not been catching on so the question is why.
The normally cited problem is the composition problem. It's incredibly difficult to achieve component isolation in the DOM and the Web Components effort is attempting to address. I approve the effort but I do not believe it will solve the problem. It's possible(ref yui3) to write components that will cleanly drop into pages that keep their CSS tweaks class based and that restriction isn't unreasonable in an app. Component use happens more frequently in apps but is not the default like it needs to be to escape the one-off tar pit. The issue is social.
The web's roots in documents mean that pretty much everybody wants a custom UI. All existing component libraries, following desktop toolit precedents, come as a packaged markup/CSS/behavior combo. These two requirements are opposed and that opposition is the core problem. I have never used a component library and not had to customize a signfiicant number of components. When doing so, I either have to maintain a private fork of the component or suffer in download/perf as the framework is super heavy and caters to all possibilities. The yui3 (and looks like current dojo) approach of core+plugin composition with auto dependency resolution is the best solution I know of but overriding is still non-trivial. Tweaking the CSS usually means having to build a complete theme and using generated markup is hit and miss.
My current thinking is that Web Components are a start but there needs to be a good solution for selectively overriding a part of the markup and for overriding style. CSS preprocessor features are also required to achieve styling goals efficiently. The rise of Bootstrap might prove me wrong by starting as an incomplete system, getting buy in (multiple themes, adoption for simple uses), and growing to a more complete one but we'll see.