Again? There sure seem to be a lot of futures for the UI in the browser.
From the sound of it, they are good enough that future is already here-- except for some glaring exceptions like shadow DOM re-projections.
Not that i disagree that components are the way forward. It's why i switched to extjs in 2008. Encapsulation into components is the only way to build large scale user interfaces without programming yourself into a corner.
A "component" in every library/framework ever has just been some HTML template along with some accompanying JS that makes it "do" stuff. You shove that on your page and watch as your CSS styles conflict with it and break the way it looks or your JS modifies something it relies on and breaks its functionality. They break, all the time. A component as described here does not suffer from such problems.
FYI: if you think you're being more productive towards building any scale user interfaces with ExtJS, you're doing EVERYTHING wrong.
They still use absolute positioning, don't use CSS whenever possible, and manually do everything in JS just to support IE. All of its vbox/hbox code is already obsolete as of flexbox but it doesn't use flexboxes (instead it manually calculates everything, and it's about 1000x slower than the browser at this, and I can provide benchmarks of this if you'd like). It doesn't even try to do this via feature detection. Why would you expect this thing that absolutely positions everything, even when it's almost always unnecessary, to conditionally support web components? Flexbox is well supported in SASS/Compass and they don't even use that (styles, enable via feature detect with a class, it'd literally be a 100 line patch to support). Never gonna happen. ExtJS is an abomination. I don't understand why Sencha hasn't killed it yet -- they have so many bright people and so many awesome projects, yet this continues to be the giant radioactive elephant in the room.
Instead of building for the lowest common denominator, it should progressively enhance. Specific CSS and supporting code for IE loaded as a module. Firefox, Chrome, Safari, and others don't need about 60% of the code ExtJS has as it literally serves to re-implement browser features for IE. Web developers do this by hand to great success, and create richer and more capable web applications than anything I've ever seen built on ExtJS without "coding themselves into a corner." Like I said, ExtJS is a terrible example of how to create and use a component-based model.
ExtJS components do break exactly as I said. For one, their interfaces change and fundamental problems with the layout system cause significant breakage from version to version. Build a custom component that itself contains other components -- next version it's broken. This isn't possible with web components. Take styling: every major version difference has completely broken styling in ExtJS applications. This isn't true of web components.
As for your opinions about ExtJS itself, we'll have to agree to disagree. I never had this bad experience you describe. Version upgrades for me went smoothly, even with a custom theme. My bugfixes overrides file is less than 500 lines, which is quite reasonable on a library that size. I admit that i'm still on ExtJS 3, which might go a long way to explain our difference in opinion. In another comment you mentioned having to rewrite a lot of components. That sounds like someone trying to make the framework into something it's not. In my experience as long as you accept that each component is a black box (like they will be under shadow dom) and only use composition and documented properties to build new things, then stuff works just fine. If however you start adapting the internals... "you're doing it wrong" ;)
Also, i strongly disagree on the feasbility of progressive enhancement. I tried that for years before ExtJS, to the point of writing my own progressively enhanced grid with many of the features of Ext's grid. The need to support IE6 meant i could never build the rich UI's i wanted without a gazillion ugly hacks that took up way too much time. Ext through its abstraction of those hacks was an incredible productivity boost. I suppose the feasiblity depends heavily on two things: (1) do you need desktop-like UI primitives, and (2) do you need to support legacy IE? I my case the answer to both is 'yes', and progressive enhancement didn't pan out. But maybe i was doing it wrong by not dumbing down my UI for the browser's limitations.
[Citation Needed]
The day I started using things like AngularJS and Backbone, I was able to create well over 100x more stuff in the same amount of time, all of it comparably bug-free and significantly more in line with web standards. I built a massive 1000+ view SPA in ExtJS. Getting it to scale to that point was an enormous technical feat -- it has O(n^2) and O(n^3) and worse algorithms EVERYWHERE and does massive amounts of unnecessary layout work because it doesn't actually use the DOM/CSS and let them do the things they were designed to do. The end result is everything is absolutely positioned with overlaps abound and a single page layout causes tens of thousands of unnecessary reflows and repaints. This is why you will never find anyone complaining that ExtJS applications are fast.
This is the future of UI in the browser.
The declarative nature, the encapsulation, the data bindings, the attribute and event-driven APIs are all orders of magnitude simpler than existing JavaScript / HTML UI element componentization. The reusability of a custom element compared to an HTML snippet with some associated JavaScript and CSS cannot be overstated.
EDIT: understated > overstated