3 ms·

> I imagine at some point they'll be able to retrofit the API to use web components underneath. They still use absolute positioning, don't use CSS whenever pos

by just2n 13y ago

> I imagine at some point they'll be able to retrofit the API to use web components underneath. 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.

Joeri 13y ago
Well, shadow dom and web components are browser level features, and it will take many years before all browsers in active use support them, so right now the benefits they offer are purely theoretical in the real world. But, i don't see anything in ExtJS that would prevent keeping the same superficial API and rejiggering the component internals to use shadow DOM. With sencha touch they already demonstrated that the API can remain largely unchanged yet be based on pure CSS, but again this is not feasible for ExtJS until IE9 is the oldest version in active use, which is years away still. You're right that they should have two layout systems, one for legacy browsers and one for modern browsers in pure CSS, but it seems they lack the resources to do this right now. 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.

by just2n 13y ago

Joeri 13y ago

Well, shadow dom and web components are browser level features, and it will take many years before all browsers in active use support them, so right now the benefits they offer are purely theoretical in the real world. But, i don't see anything in ExtJS that would prevent keeping the same superficial API and rejiggering the component internals to use shadow DOM. With sencha touch they already demonstrated that the API can remain largely unchanged yet be based on pure CSS, but again this is not feasible for ExtJS until IE9 is the oldest version in active use, which is years away still. You're right that they should have two layout systems, one for legacy browsers and one for modern browsers in pure CSS, but it seems they lack the resources to do this right now. 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.