4 ms·

I wouldn't use ExtJS as an example of how to do anything right. Nothing (no frameworks, no previous standards, not even plugins) has ever enabled true component

by just2n 13y ago

I wouldn't use ExtJS as an example of how to do anything right. Nothing (no frameworks, no previous standards, not even plugins) has ever enabled true component-level sandboxing within the same document. This is just HTML/CSS/JS that is sandboxed into its own component. This library isn't revolutionary, because it's intended to be a polyfill for future-facing (and present) standards which aren't yet widely supported. But what these standards describe IS revolutionary. 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.

k__ 13y ago
> if you think you're being more productive towards building any scale user interfaces with ExtJS, you're doing EVERYTHING wrong. [Citation Needed]
- just2n 13y ago
  Years of experience working with the library and being forced to rewrite almost every major component of it due to it being completely buggy and broken. Version upgrades massively break every application using it. It's impossible to style because its "component" abstraction is leaky. The component DOM-mirror they maintain is broken by almost any 3rd party code that does anything. Debugging it is a bigger pain in the ass than debugging in IE6. 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.
Joeri 13y ago
I've got 110.000 lines of ExtJS code and a million users who disagree with your assessment of ExtJS. It is most definitely not true that ExtJS components conflict in the way that you describe. Ext achieves this by abstracting html and css almost entirely, which is also why making ExtJS apps work in IE7 is almost effortless. I imagine at some point they'll be able to retrofit the API to use web components underneath.
- 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.

by just2n 13y ago

k__ 13y ago

> if you think you're being more productive towards building any scale user interfaces with ExtJS, you're doing EVERYTHING wrong. [Citation Needed]

just2n 13y ago
Years of experience working with the library and being forced to rewrite almost every major component of it due to it being completely buggy and broken. Version upgrades massively break every application using it. It's impossible to style because its "component" abstraction is leaky. The component DOM-mirror they maintain is broken by almost any 3rd party code that does anything. Debugging it is a bigger pain in the ass than debugging in IE6. 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.

Joeri 13y ago

I've got 110.000 lines of ExtJS code and a million users who disagree with your assessment of ExtJS. It is most definitely not true that ExtJS components conflict in the way that you describe. Ext achieves this by abstracting html and css almost entirely, which is also why making ExtJS apps work in IE7 is almost effortless. I imagine at some point they'll be able to retrofit the API to use web components underneath.

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.