ExtJS: a dream or a nightmare? (2013)

As the creator & maintainer of a large ExtJS application (stockor.com/demo), I find it very much a mixed bag.

Love the comprehensive widgets that are all integrated with the data sources. Back in the early days of SPA architecture I'd say they were far above everyone else.

Hate the slow, JS driven layouts. Something that's not immediately obvious when using ExtJS is that all layout is conducted by it's own engine and applied via inline style tags which set the width/height of each element. This might have made sense back in the IE3/4 days (when I started using it), but I find it really sucks now since you're hobbling the browser and not allowing it to do what it does best - Laying out webpages.

And there's the perennial bugs. Sencha is attempting to re-create the entire web ecosystem themselves, so it's no surprise that they don't quite pull it off seamlessly. I won't elaborate on this too much since it's pretty easy to visit their own forums to get a sense of the frustration level with this.

I'd posit that ExtJS made quite a bit of sense back when IE4 support was still a big thing, but I'm pretty sure it's best days are behind it. I'm sure it'll hang on for quite awhile in corporate environments, but I don't see any reason to use it for new development.

I mostly saw it used for intranet applications, where not being forced to deploy stuff for each change is a big bonus. In these cases, you're not coming from knockout, backbone or react -- you're fleeing from the wrath of Java Webstart and Swing. And compared to those beasts, ExtJS is a welcome change.

Yes, all the bad things said in the post and this thread are certainly true, but that still makes ExtJS better than some of the alternatives in this peculiar shithole. And no other framework/library seems to move in that direction. Components, sure, but no full-fledged widgets that end up in providing a desktop-like experience. Most widget libraries I've seen were enhancements/additions to mostly conventional web pages (Cappuccino as a possible exception).

Sure, you don't want to provide a 80%-ish emulation of native GUIs on the real internet. But for the corporate stuff like CRMs, it's darn useful. Even ravishing the DOM is better than Swing.

(Did I mention that I don't like Swing?)

One thing that probably isn't mentioned very often is that Sencha now recommends the use of Sencha Command for managing Ext JS and ST apps. It's a nightmare combination of open-source and closed source, which means fixing any bugs that arise is a total nightmare.

One reason they use this is because part of Sencha Command parses your source code and builds a dependency tree which is then used generate a concatenated build, a minimised build, and for Sencha Touch, a diff which is used to deliver delta updates to the browser so the user has less to download when the app updates.

This is all great, but I can't help but feel if they'd used a more standard approach - AMD for example - to create their module definitions, they'd have reduced a whole level of complexity in the framework code and in the surrounding toolset.

This is just one corner of the Sencha ecosystem which provides pain points. I still believe it can be the right choice for some applications, but in many situations the power it provides comes with too much complexity, a lot of which you won't get burned by until you're tied into their framework.

My biggest complaint is that the template holes in components aren't html escaped by default. You end up having to override the default templates just to add "htmlEncode" liberally. For example, the venerable ComboBox should just escape the items by default instead of allowing html in the combobox menu items by deafult.

The first project was working with it through GWT. Views are built imperatively with Java. I didn't touch any JavaScript, HTML or CSS. Java kept all the types in check. Things are smooth.

The second project was working with it JavaScript, after I've gained a year of experience working with HTML and CSS. Things are hard. Layouts are confusing. Seemingly simple stylings are hard to control.

The third project is where I am now. Although we're still using the Sencha framework, a lot of the components are actually custom built. I guess the only parts of Sencha we're using are class system, layout (only very sparingly), and touch interaction. Things are smooth. We're now considering the possibility of switching out the full Sencha framework to Ext Core.

This is where I say that I wish there can be an open source fork of Sencha. There are parts of Sencha that are good (class system, MVC, touch interaction) and there are parts that are bad (large component library that most people don't really need). A large part of the Sencha framework is actually the component libraries. If these are stripped out, I think it's possible for it to be smaller than Ember.

The way Sencha Touch (and probably ExtJS) handles data sources for remote data seems cool at first, but a lot of it ends up feeling pretty gross. Also, offline data storage or things related to that for mobile seemed broken/confusing/nonexistent.

ExtJS interaction with external developers is a mess, taking patches through their private bug tracker instead of fostering a collaborative development environment. Open-source developers have been driven away after their patches are only officially made available quickly to users with a commercial license. (There is a delay between open-source releases, while commercial customers get intermediate releases.) Ultimately this friction will push mindshare elsewhere.

One of the primary strengths of ExtJS is legacy browser version support due to use by so many enterprise customers; it's only in the very recent v5 release that they dropped support for IE 6 & 7.

There is definite beauty in this framework. I liked the descriptive layouts. I liked setting up stores for all my data models. But in the end, I was stuck trying to figure out the "Sencha" way, and often having to just forget about it. (I'm not saying things couldn't be done, just that I couldn't find proper docs on HOW to get it done)

The product shipped. I was mildly pleased with the result. But once visual design tweak requests started rolling in.... I turned it over to someone else.

http://mumbledrantings.blogspot.com/2010/04/reaching-utopia-...

The tl;dr version is that it's so good at building complex things that it hides none of the complexity. Instead of learning about the interesting system of JS + HTML + CSS + server interactions, you let ExtJS handle the interactions and specific everything in massive arrays. And that exercise bores me out of my damn mind.

It might have made sense 6 or 7 years ago...but these days it is mostly a pain in the ass.

In the end, I was able to do what I needed to, albeit not on mobile due to performance issues, but I wouldn't choose to use it again if it was up to me. It just felt too bloated, and I'd much rather work with various smaller libraries, and fill in the gaps as needed.

I used ExtJS heavily for years and identify with this post, I use React now and couldn't be happier. We had to build our own component library[1] (wrapping KendoUI widgets) but React makes it a breeze to take these primitives and build composites.

https://github.com/wingspan/wingspan-forms

Ext JS 3.x did what we needed it to do and did them well; grids. Lots of grids. Other than that it was kind of difficult to build a single page application without routing since Ext JS 3.x didn't have anything built-in, so we had to make our own. We used Ext JS 3.x less like a framework and more like a utility. There were some pain points around the REST aspects as well. Remote data with Ext JS can be difficult.

We found that after moving to Ext JS 4.x everything was more polished. The ability to theme with SASS, mixins, etc. The MVC pattern was a big plus. Performance was faster, and the integrated builds Sencha introduced with Sencha Command were excellent for automation. We still ran into problems with internationalization, which Ext JS 4.x does support in its own controls, but you have to roll your own for content. There were also some pain points again with remote data. Still much better than previous versions. Ext JS 5.x is building on the MVVM pattern and adding a number of great features. Migrating and upgrading to new versions is actually much more streamlined and automated.

One topic I want to point out that throughout any of the projects I worked on with Ext JS the remote data was always the pain point. Every single, time. On a large scale project usually teams are split up, UI, middleware, etc. We found that you had to design the REST endpoints carefully with the middleware team so that they worked well with what the Ext JS proxy expected. Like pagination for a simple example. You can customize and extend Ext JS of course, it is just we found bending Ext JS to meet another teams interpretation of how a REST endpoint worked was really difficult. Granted that comes down to communication, but even then I still saw problems. There are plenty of others on the Sencha forums.

I like Ext JS, I think Sencha has a mature product. Excellent support and a great community. Like any framework, it has pros and cons. I can't speak to Sencha Touch as I do native iOS, but I am sure it is similar as they share a lot of the same concepts.

Other frameworks like Angular, and Backbone I usually lean towards though as they are the groundwork, a foundation. They allow me or a team to build an application without getting in the way too much or dictating how.

I agree jQuery is too low level for a framework switch.

It is obvious that OP has great deal of experience in ExtJS and JavaScript and his nightmare points are valid for his use case. Here is what I think about his nightmare points -

1. ExtJS shows an empty page if an error occurs somewhere - YES. This is a real nightmare. And no matter how much they try to make it 100% cross browser compatible, there ARE instances when the application will load in Firefox but not IE and vice-versa.

2. Abuse of divs - I do not see how this is a problem if you are using ExtJS as an application framework and not just a component library within your bigger application. If you are using ExtJS as an application framework, you are letting ExtJS render to the body and never have to directly deal with DIVs except in some cases through some inspector to understand what you custom css should override. (This is also getting easier with theme customization support in Architect)

As far as load speed is concerned I don't see it as a major issue but my use is mostly enterprise applications where it is OK for an application to load and respond slightly slowly as long as the functionality is robust, "always works" and there is look and feel consistency among different applications - all of which ExtJS helps me with.

3. Inline styles - This is not really an issue again for the same reason that if you are using ExtJS an application framework, you let it do whatever it wants to with the DOM. There is no reason to directly manipulate DOM and if you need to, you can always override or extend a component with a new/modified template that suits your needs. I do agree about the fluidity issue though but I feel it needs to be addressed at the framework level by providing more controls through the component/layout API. (flex attributes only help so much)

4. Steep learning curve - Absolutely agree with this one. I have had the chance to work with developers new to ExtJS on multiple occasions. One thing I have found is that the learning curve is much less steep if (a) the developer has some level of javascript competence i.e. understands prototype, closures, etc. (b) Is willing to look at ExtJS as a FRAMEWORK with APIs and is humble enough to bookmark and use the API doc as often as necessary. It surprises me that so many otherwise good developers refuse to frequently access API documentation before asking questions.

5. Licensing - Absolute nightmare. There was a big backlash against Sencha when they first introduced commercial licensing and thwarted the ability of other developers to develop commercial frameworks on top of extjs.

I am all for commercial licensing and heck (I was happy when they started charging for it), they should charge more if that's what will help keep their lights on and continue spending good effort on improving the product. But the problem with their commercial licensing is the built in "vagueness". Last I checked, a license is tied to a _particular developer_ and cannot be transferred to another developer so theoretically, each time a developer quits and you want to bring in another developer, you have to buy a new license.

Other two important pain points I face are -

1. Support - The best support you can get is from other users on stackoverflow. Even there, approximately 5K out of 15K questions are unanswered (I don't know how that stacks up against SO average). To put things in perspective, I stopped answering questions actively about year ago but I just checked and I am still listed in the topusers page for extjs on SO.

2. Toolchain - Architect and Cmd are good steps in the right direction but are not even scratching the surface of what a solid toolchain support should be like. I have a big wishlist for Architect and I believe Sencha Cmd is too much of a mess than it should be.

Overall, I am glad the framework exists, wish there were options out there but for single page enterprise web applications, I don't see any other rich js component framework worth abandoning ExtJS for.