ExtJS: a dream or a nightmare? (2013)(markhamstra.com)
markhamstra.com
ExtJS: a dream or a nightmare? (2013)
https://www.markhamstra.com/extjs/2013/extjs-dream-nightmare-jquery/
23 comments
Wasn't Flex a better alternative to ExtJS in this problem-space?
Recently I've seen entire apps packaged up as Silverlight, which seems to work well - especially where security (exam marking in this case) is important. Not sure how they're built mind, and it took an age to download, but for intranets it's another interesting approach.
Recently I've seen entire apps packaged up as Silverlight, which seems to work well - especially where security (exam marking in this case) is important. Not sure how they're built mind, and it took an age to download, but for intranets it's another interesting approach.
I very much agree with all of your points. ExtJS is hard to beat in terms of the breadth of its widget set, layout configurations, data handling models, etc. Just for the almighty GridPanel, it's worth it I would say. But it's also more appropriate for internal, non-public facing apps. For that, you get pretty much all the usual benefits of a web application (ease of deployment, etc.) without getting lost in a traditional desktop GUI jungle. It's true that the library is frighteningly monolithic and the learning curve quite steep, but personally, I very much appreciate the declarative syntax, the very complete documentation, the multiple examples, the flexible MVC structure and the fact that it can easily result in nice decoupled code, as you can plug any backend you like, as long as it communicates through a well-defined protocol (I personally favor Python and Flask).
My biggest complaints about ExtJs is that it has an extremely difficult learning curve and, while the docs have gotten better, they still don't cut it. For example, the venerable ComboBox is rife with pitfalls. I've since forgotten the details, but the various config options interact in strange ways.
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.
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.
I've worked with Sencha frameworks for 3 projects over 5 years. There is definitely a love-hate feel about it.
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 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.
Facebook React is the answer IMO.
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
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
My experience with ExtJS is that it is the best Component with MVC framework the javascript community has to provide, and is still years behind where Flex and Silverlight were in 2010.
When I used it, it was documentation hell. You would always need to delve into the source code.
I've co-authored a book on ExtJS 3.x and I've worked heavily with Sencha Touch.
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.
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.
I started using extjs in the tail end of the Jack Slocum period. He was a formidable one man army who delivered what I considered an elegant but incomplete vision. I feel that after he dropped out of it they never managed to reach the same level of clarity in building out the missing pieces. Each release brought more features but also more cognitive load, and it made it harder to learn. Eventually, with v4, they just built a new framework with a different philosophy that they then branded as extjs. I wonder how extjs would have turned out had jack been there all along.
What did Jack Slocum move on to do? I found his blog [0] but it says very little about what he's doing now.
0: jackslocum.com
0: jackslocum.com
> AMD for example
We use Dojo and AMD has been a god send. We use it to subset our web client into parts that can be dynamically loaded only if/when needed. Keeps our browser footprint small.
I'm going off-topic here, but what are the equivalents for AMD when using the newer tech like Angular and React? I really want to try and move to Angular or React, but am I going to miss my dynamically loaded modules?
We use Dojo and AMD has been a god send. We use it to subset our web client into parts that can be dynamically loaded only if/when needed. Keeps our browser footprint small.
I'm going off-topic here, but what are the equivalents for AMD when using the newer tech like Angular and React? I really want to try and move to Angular or React, but am I going to miss my dynamically loaded modules?
You can use AMD with React (though most in our community use CommonJS I think). Angular implements its own module system which is somewhat similar to AMD.
My experience with Sencha Touch was pretty terrible. I'm not sure if it didn't fit my mental model or what, I had a lot more success with Kendo Mobile and Kendo MVVM.
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.
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.
Article's a bit over a year old, but the points it raises are still very valid.
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.
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.
Your app is I think the perfect use case for ExtJS.You need widgets,charts .... all in one place ready for use.No directives or jQuery plugins to write. That's why the framework was created as first place ,LOB apps in JS instead of flex/silverlight.
They just forgot the declarative part that made flex and silverlight easy to work with. I personally dont like these huge JSON like scripts to configure a component. But I guess that's also why they sell a IDE.
How about unit testing? does ExtJS provides tools for that today?
They just forgot the declarative part that made flex and silverlight easy to work with. I personally dont like these huge JSON like scripts to configure a component. But I guess that's also why they sell a IDE.
How about unit testing? does ExtJS provides tools for that today?
Yeah, I agree that ExtJS is a pretty good fit for Stockor, and is why I choose it originally.
Now I'm struggling with being more responsive and wanting to open the code up for embedding widgets into third party pages. Extjs really doesn't work well for either of those cases.
As for testing: They've got some fairly decent tools for it. I'm just using Jasmine though.
Now I'm struggling with being more responsive and wanting to open the code up for embedding widgets into third party pages. Extjs really doesn't work well for either of those cases.
As for testing: They've got some fairly decent tools for it. I'm just using Jasmine though.
I think you're misremembering IE's version numbers. ExtJS started up as a YUI extension called YUI-ext circa 2006. IE3-4 were long dead by then. You might be thinking of IE7-6.
http://www.w3counter.com/globalstats.php?date=2007-05-30
http://www.w3counter.com/globalstats.php?date=2007-05-30
I may be misremembering, but my recollection was my then employer started using Ext version 2 primarily since it had the rich widget ecosystem and also supported IE 4 well. We were writing internal enterprise apps and it was a good fit.
As you can guess, that's been quite awhile ago. My memory is fuzzy on the details to be sure.
As you can guess, that's been quite awhile ago. My memory is fuzzy on the details to be sure.
I also used extjs 2 and i can assure you it didn't support anything below ie6.
What would you choose now? taking into account open source and commercial products.
I am feeling a Windows GUI development deja vu with the current web UI state of the art. You could see excellent or nice user interfaces (e.g. winamp) but at the end they are custom made. Even Microsoft didn't provide the basic widgets (thinking in MFC) to build a basic application.
I am feeling a Windows GUI development deja vu with the current web UI state of the art. You could see excellent or nice user interfaces (e.g. winamp) but at the end they are custom made. Even Microsoft didn't provide the basic widgets (thinking in MFC) to build a basic application.
Thats the one thing ExtJS has going for it...a full suite of widgets that make it so any jackass can plop in a data table and move on.
The problem is when you want anything outside the realm of those widgets, or actual proper program structure and html/css...then you are in for the fun.
But as far as a replacement where you have a full suite of ready-made widgets you just wire up? I am not sure there is anything else out there near as comprehensive. Everything else will require you to wire up the logic for each of your widgets at the least...there are some html/css frameworks that will get you your widget on the page, but behavior? That's up to you.
The problem is when you want anything outside the realm of those widgets, or actual proper program structure and html/css...then you are in for the fun.
But as far as a replacement where you have a full suite of ready-made widgets you just wire up? I am not sure there is anything else out there near as comprehensive. Everything else will require you to wire up the logic for each of your widgets at the least...there are some html/css frameworks that will get you your widget on the page, but behavior? That's up to you.
Exactly! Well said, "any jackass can plop in a data table and move on." The problem with that approach is that it's very deceptively easy. The data table morphs into a screen, then into an app, and before long you've got a big fat steaming pile of JS that is a 5mb download.
And then you get some really weird bugs like "If these two components are layed out inside an hbox, every once in a while you get a "Layout Run Failed" exception". Not that that's happened to me or anything :)
I'm actually in the middle of an exploratory re-write to use straight Backbone. I'm hopping to wrap up widgets like DataTable, Select2 and such into Backbone views and use them.
It's early days on it, but am hopeful that I'll arrive at something useful.
And then you get some really weird bugs like "If these two components are layed out inside an hbox, every once in a while you get a "Layout Run Failed" exception". Not that that's happened to me or anything :)
I'm actually in the middle of an exploratory re-write to use straight Backbone. I'm hopping to wrap up widgets like DataTable, Select2 and such into Backbone views and use them.
It's early days on it, but am hopeful that I'll arrive at something useful.
I would like to hear your comments about Telerik, nobody talked about Telerik in this thread yet.
I really like Telerick. They do seem to have a good system of widgets and data bindings. I haven't used them in anger though so don't really know for sure.
I was pretty bummed they removed the grid from the open-source components though. That's the main thing that's stopped me from going further in evaluating them
I was pretty bummed they removed the grid from the open-source components though. That's the main thing that's stopped me from going further in evaluating them
One thing missing from KendoUI for me is the TreeGrid. Last I checked (a few months ago), it's still not available. It's an important component in our solutions.
Telerik is just Kendo UI right? I remember seeing people mention it in this thread.
Nice demo page.
My experience with ExtJS is terrible...I will actively run away from any future positions that even remotely consider it.
It might have made sense 6 or 7 years ago...but these days it is mostly a pain in the ass.
It might have made sense 6 or 7 years ago...but these days it is mostly a pain in the ass.
I liked the part where he quotes himself
My hope is that React is going to be the foundation for the next generation ExtJS-like project. It has been designed with both components and speed in mind.
I'm confident that it will be. I'm in the process of building a component library on React at work and I'm sure there are others doing the same. My biggest question is if and whether all the parochial component systems will somehow be able to cooperate.
> My biggest question is if and whether all the parochial component systems will somehow be able to cooperate.
If I understand this right, this is a big concern of mine too, I feel strongly that React needs to provide a standard Cursor-like interface to state, otherwise each parochial component system is going to be incompatible with the others.
Here is some discussion on cursors: https://news.ycombinator.com/item?id=7906657
Here is a component library we built at Wingspan: https://github.com/wingspan/wingspan-forms
If I understand this right, this is a big concern of mine too, I feel strongly that React needs to provide a standard Cursor-like interface to state, otherwise each parochial component system is going to be incompatible with the others.
Here is some discussion on cursors: https://news.ycombinator.com/item?id=7906657
Here is a component library we built at Wingspan: https://github.com/wingspan/wingspan-forms
ExtJs has been a pain where I work. I remember being horrified at how it takes over and starts adding styles all over, even to the body tag even if all you were doing was displaying a grid in a div. Why would it leak out of your div and take over the whole page like that?
I have worked with Ext JS for quite some time. Started with Ext JS 3.x and more recently Ext JS 5. Mostly large financial applications. Full disclosure that I am a proponent of Backbone, and Angular too. Right fit for the project.
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.
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 didn't use that many server side components, but I noticed they followed a pattern I liked, a filter component, a selection and the url. I think that's pretty adequate for the great majority of use cases.
The sass I found was horrible. I remember the grid had an 800 line sass file.. What??! I made my own grid and styled it in like 50 lines or so. Too bad the app I designed it for died, and no one at the company kept the source.
The sass I found was horrible. I remember the grid had an 800 line sass file.. What??! I made my own grid and styled it in like 50 lines or so. Too bad the app I designed it for died, and no one at the company kept the source.
> I think Sencha has a mature product. Excellent support and a great community
You mean the one or two people on the forums that answers 90% of the questions...that community?
Granted its been about 6 months since I looked...but thats how it was last I saw.
You mean the one or two people on the forums that answers 90% of the questions...that community?
Granted its been about 6 months since I looked...but thats how it was last I saw.
That one user "Condor" http://www.sencha.com/forum/member.php?343-Condor.
my experience with ExtJS 4 has been a nightmare
ExtJS is an interesting study on dual-licensing. The open source licensing for ExtJS is GPL3 + exceptions; posts appear constantly on the forums asking for clarification/permission. Unlike Kendo, ExtJS includes all of their controls in the open-source release, including the ever-necessary grid control.
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.
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.
I built an app a couple of years ago with Sencha Touch. The quick mobile build demo (and a few of the prebuilt widgets) sold me on trying it. About 2 weeks into the project, I was hating life. The forums seemed to be answered by one guy. (He was extremely brilliant, but probably VERY over-taxed). What's worse, since the critical mass of users were using other frameworks, getting help on places like Stack Overflow seemed impossible.
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.
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.
Never once had a positive experience with ExtJS or any of its derivatives - GXT, Sencha Touch, anything. Total nightmare to work with. Non-performant trash at its best.
Background - I have been using ExtJS in production systems since before they started charging for it (remember yui-ext?)
I have worked with all of their major releases and am now dabbling in ExtJS 5.
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.
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.
We've been replacing our ExtJS with AngularJS. Couldn't be happier with the decision.
I agree jQuery is too low level for a framework switch.
I agree jQuery is too low level for a framework switch.
What are you using, if anything, to replace the UI components ExtJS provides?
I was tasked with using ExtJS for a large project, without having prior experience with it. It was both a dream and a nightmare for me (OK, that's a bit dramatic, but it was a mixed bag.)
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.
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 to write a bunch of ExtJS. The whole abstraction bothered me so much that I wrote a whole post about it.
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.
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.
If I'm writing an app, I'm doing it to deliver something. If I want some zen-like learning experience I know where to get it, and prefer that the ugly inner working stay out of my immediate workflow.
Sure, in the short term. I generally find that understanding the system (or building abstractions that cover the complex system in sensible ways), you find ways to solve problems more elegantly.
Put another way, in building an app, I always learn something about my original vision of the app that was wrong, and needs correcting. ExtJS doesn't help with that iteration loop: I just create hard-to-debug things that do exactly what I want when I finally get them working. The rubber of your ideas meeting the road of the complex system is an important step in creating a better app, and papering over the system ignores that step.
Put another way, in building an app, I always learn something about my original vision of the app that was wrong, and needs correcting. ExtJS doesn't help with that iteration loop: I just create hard-to-debug things that do exactly what I want when I finally get them working. The rubber of your ideas meeting the road of the complex system is an important step in creating a better app, and papering over the system ignores that step.
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?)