Shared publicly  - 
Reader's questions: "What are your thoughts on ExtJS4? This version also follows the MVC pattern and while the framework is quite heavy, it can be interesting for large scale web apps"

Answer: I've previously looked into ExtJS4 before and there are actually quite a few teams here at AOL using it actively for non-trivial projects.

My initial thoughts on ExtJS were that it was unnecessarily 'heavy', however this has improved in recent years, particularly with the last release. The base framework for developing your application should be as lean as possible (which I understand it's always feasible), however with ExtJS there are a number of other reasons I opted not to use it personally.

Here are some pros and cons (which whilst not exhaustive, should give you some insight into my research on it):


- Very comprehensive documentation
- Active forums where users can get lots of assistance fairly regularly (this can't be said to hold true for all MV* frameworks or toolkits)
- As a structural solution it's both comprehensive and easily extendable
- A relatively complete set of widgets and components for RIA development
- Vast array of community-curated user extensions available
- The community regularly write tutorials aiming to solve common problems the framework addresses


- Size: It still has a relatively large footprint compared to modern MV* solutions that aim to provide a very small core/base (Backbone.js is < 9kb). These other solutions of course don't cover UI components for the most part (Dojo's Dijit does) but I would still expect something smaller for the core. Perhaps it would make more sense comparing ExtJS to Dojo in this regard? Dojo 1.6 has a < 30kb core (minified) whilst ExtJS4 has an 84-500kb core (minified) [reference:]. I'd love to hear from those using ExtJS4 more frequently what value their larger base offers.

- Complex output: ExtJS has a relatively solid data model and store setup but the output it generates from a UI perspective is imo, unnecessarily complex. This may be due to it's reliance on JS for generating much of the UI, something that can mean it's difficult to find the correct classes to style or generated markup to alter. You are afterall relying on the framework to generate something sane and flexible. When using any UI/widgeting framework, it would be nice to reduce the effort required to debug/locate items using any sort of DOM/Web inspector.

- Learning curve: It has a steeper learning curve than many of the other modern structural frameworks (I mention this as you referred to MVC). One can argue that if you're investing in ExtJS for the long-term this time spent learning will pay off, however I think solutions like it should aim to better minimize the time it takes to train teams up in using it. Some developers with experience in both have commented that ExtJS and Dojo have roughly equivalent learning curves (again, in the interests of maintaining fairness and balance)

- Debugging: This been a problem in the past, but got better in version 4. It is however still more difficult than any statically-typed language like Java (GWT). One could argue this is an issue for other JavaScript frameworks too however.

- Licensing: considered restrictive and difficult to understand by some. Developers have pointed out that more people would be investing in ExtJS if it was clearer what the upfront and long-term costs of using it are. This isn't a concern with some other structural solutions but probably isn't as much a worry for larger businesses.


I think at the end of the day as with any framework it comes down to investing time in researching whether the pros of using ExtJS outweigh the cons for your specific project. For more thoughts on Dojo vs. ExtJS (which I think is probably more fair here), see:
Max McNally's profile photoRobert Kovacs's profile photoSteven Roussey's profile photoAlan Plum's profile photo
To be fair, I think ExtJS works best in combination with Ext Designer. It gives it an edge beyond the other GUI frameworks by letting non-programmers mock up the UI so programmers can fill in the blanks. I think comparing it to MVC frameworks like Backbone doesn't do it justice -- its strength lies in creating rich GUIs, not lean web apps.

For rich, commercial back-office applications I think ExtJS remains the best choice when it comes to JavaScript solutions (i.e. not GWT etc). For public-facing web apps I'd rather have something that gives me more control over the markup (and ideally something that degrades gracefully).
I have been using ExtJs since last two years. It's certainly heavy. It's build using object oriented concept. I guess that makes it most preferable framework because you have flexibility to override base components and add your own features and create custom objects.
+Alan Plum Thanks for your input. I'll be happy if my summary at the very least helps prompt more discussions to clear up some of the misconceptions about ExtJS (from those using it) and some of the downsides (from those that heavily investigated it and opted not to). I agree to an extent regarding it being better suited as a solution for rich, desktop-like GUIs. I'd also be interesting in hearing your thoughts of ExtJS vs. Dojo (and Dijit) in this regard as it's probably closer capability wise than something like Backbone.
Sadly I can't say much on how Dojo compares to ExtJS. At the time the decision to use ExtJS was made Dojo was in between two major release, leading to parts of the documentation being incorrect or broken.

I think a big feature of ExtJS 4 is that it throws you into the MVC mindset and the preferred filesystem structure right from the bat. With Dojo the initial tutorials seem to be mostly about augmenting existing websites whereas ExtJS assumes you're starting from scratch.

Using ExtJS doesn't really "feel" like you're dealing with HTML at all. The component library is rich enough to let you go a long way without touching more HTML than what is needed to bootstrap your app.

It'd be interesting to see how both compare when web components become more widely supported. This would finally allow manipulating the DOM without being afraid of breaking any widgets or causing your app's internal state to become inconsistent.

Dojo seems more "pluggable". By choosing ExtJS, you'll pretty much buy into the entire Sencha stack eventually. With Dojo the choice seems to be less absolute. It's probably a bit closer to the metal.
Hi Addy, thank you for your elaborate reply to my question! And I have to say I fully agree with you and Alan Plum.

I've been working on an ExtJS4 project for quite some time now and one of the reasons to choose for ExtJS was the high quality of the widgets (especially the Tree panel) and being able to use Ext Designer to quickly prototype new features.

Besides the steep learning curve, I also would like to point out that working with the good old DOM in ExtJS can be quite difficult. You've got the DomQuery and DomHelper classes to select and generate HTML, but coming from jQuery and PrototypeJS, I just can't get the hang of it.
+Sebastiaan van Kerkfort You're very welcome. I'm glad that this started some interesting discussion around ExtJS4 :) +Alan Plum would you agree that working with the DOM in ExtJS can be a challenge at times (even using DomQuery and DomHelper)?
+Addy Osmani Absolutely. That's what I was trying to get at by saying it doesn't feel like you're working with HTML at all. You're working with trees of ExtJS components, the actual DOM seems more like an implementation detail.

It's not very satisfying if you come from an HTML authoring background, but it lets you focus on the application at hand instead of having to worry about document structure and semantics. That's why I think it's closer to GWT than to conventional JS frameworks and widget libraries.
Currently I'm developing a Mobile App with Sencha Touch 2 and soon have to start building a Webapp. My first natural thought was ExtJS4. But since I've used Touch 2 for a while, some things are quite complex and you always have the "Sencha Look". Unfortunately you never know a framework well if you don't spend quite some time with it.
I have to agree that ExtJS is a fantastic package for rapidly building out RIAs for internal use. I for one, love to build with HTML and JavaScript, and I for me there's great satisfaction in muck around at that level. At some point I get that nagging feeling that I'm just tinkering there to satisfy myself. At the end of the day, it can feel like often times too much time is being wasted working at that level when a GUI builder would get 'er done so I can focus on the real value add work.

That said...I absolutely agree that it's very heavy and I don't think I'd recommend it for an external facing web application. My biggest beef with the package overall is actually that it's more of a PITA to test with than I'd would like. Our tester actually ended up switching to Sikuli because it was becoming too much of a battle trying to work with it in Selenium.
"When using any UI/widgeting framework, it would be nice to reduce the effort required to debug/locate items using any sort of DOM/Web inspector."

That is what Illuminations for Developers does[1]. See the intro[2].

As for large... yes, they have a way to include everything. Easy when developing. But when you deploy, they have a tool that looks at what you are actually using, and builds a smaller version based on that. And, if you aren't doing some 3-month project to boast about on hacker news, but instead have a team of people working a year or more, then the integration issues of getting all the UI stuff from a dozen different sources will become a real issue.

Sencha really needs a theme builder though. I was going to build one, but figured they would, so I never did. Should have done it....

I have tried to get going with extJS and I can safely say that the learning curve is not only steep, but it is long aswell ! I am a Java developer (both desktop and enterprise) with over 15 years experience and I did not find the javascript easy to get to grips with. It did not help that all I had is eclipse and no tools other than firebug. Every step of the way was like pulling teeth.

As you may guess, I gave up with ext and have instead adopted Vaadin, I feel like I am developing a swing application - all the communication detail is hidden and the only digging under the hood I have needed to do has been to get at the session to get the user id.

The widget set in Vaadin seems as rich as ext's - at least everything that I have wanted to do in Vaadin I can.

In 2 days with Vaadin I developed that which took almost 4 weeks in ext. That is not a negative comment on ext but an indication of the slope of the curve! I freely admit that I am not a JS developer and that I feel far more at home in java.

I would be interested to know about the performance issues but client side rendering and server side. Vaadin appears to make more calls - due to the extensive use of listeners - but the listeners are the equivalent to the store.loading in ext so it is probably about break-even.

Sure I am probably paying for the "extra" java server side processing but when the application being developed is an intranet site which probably wont have more than 50 or 60 sessions per day I doubt it will be an issue.
+Robert Kovacs It sounds like your main issue was having to learn a whole new language (js is nothing like Java) rather than ExtJS itself. That ExtJS is relatively Java-ish doesn't make this easier, quite the contrary.
+Alan Plum
Absolutely right Alan.

I will never denigrate a development language just because I don't know it! That said when it is enforced on a development team who do not have the js skills then I take exception and fight hard to change snr mgmt minds as to the applicability for my team. I believe ext and vaadin are equivalent frameworks and perfectly valid for an intranet web app. But to force it on a team that has java skills and not JS skills is bad PM (imho).
"When using any UI/widgeting framework, it would be nice to reduce the effort required to debug/locate items using any sort of DOM/Web inspector."

Use Illuminations for Developers for god sakes! You right click on the web page and it tells you what you clicked on and will bring you to a panel that shows you the view and widget hierarchy like the Element/HTML panel shows DOM nodes. 
+Steven Roussey but then I would have to use Firefox for development instead of Chrome. Personally I find the Chrome dev tools far more useful than Firebug.
+Alan Plum Sorry, I haven't had much time to devote to Firebug this last 1.5yr. :(

I do have work done on Illuminations for Chrome though. Google does some things that make me want to cry though. I nearly pulled all my hair out this weekend in fact. :/
Disregard that. ExtJS is a mess.

Working with ExtJS 4.0.x I kept on running into ridiculously obvious bugs only some of which were later fixed in ExtJS 4.1.x months later. It is almost impossible to create a non-trivial application without using DeftJS, which adds promises, view controllers and other concepts Sencha does not believe in.

The built-in handling of async logic with events and callbacks is incomplete and inconsistent, the use of AJAX and "loading" state is naive at best. Although ExtJS uses plenty abstractions internally, the possibilities of extending built-in functionality without using overrides or verbatim copying of large portions of code are ridiculously limited.

What's worse: Sencha Architect (formerly ExtDesigner) can in some cases produce code that doesn't work. At the same time, despite "team" workflow being a major selling point, it creates noisy commits, doesn't provide any sensible import/export functionality and still only supports built-in views. Don't even think about internationalization either -- there are ways to monkeypatch it in, but if you want any consistency, you're in a world of pain.

Oh, and theming? Yes, it supports Sass and Compass, but there is no real tooling for ExtJS (there's Sencha SDK, but it's mostly geared towards Sencha Touch, because mobile apps are where the money is). If you want to do anything more complex than adding a silly widget variant style or changing the colour scheme, you're pretty much on your own.

Looking at it after having spent over a year working in a large-scale project (monolithic web app with dozens of views that each can have multiple instances with related data), I would not recommend it. For its poor code quality and limited scope it's simply overpriced.

Apparently the sweet spot are enterprise-y desktop-style web apps that only show one resource at a time. Capability-wise it's just too limited for anything non-trivial. Price-wise it's just too expensive for small companies (for a single project, anyway).
Add a comment...