
ExtJS: a dream or a nightmare? (2013) - wslh
https://www.markhamstra.com/extjs/2013/extjs-dream-nightmare-jquery/
======
nathanstitt
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.

~~~
wslh
I would like to hear your comments about Telerik, nobody talked about Telerik
in this thread yet.

~~~
nathanstitt
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

------
mhd
I think the comparisons with other frameworks like JQuery or Angular are a
little out of place. I don't really see Ext as a competitor in that area. It's
not really a traditional JS framework, it's more a GUI library that just
happens to use the browser as the backend and JS as the programming language.

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?)

~~~
cjauvin
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).

------
colinramsay
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.

~~~
Joeri
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.

~~~
porker
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

------
vjeux
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.

~~~
grayrest
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.

~~~
dustingetz
> 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](https://news.ycombinator.com/item?id=7906657)

Here is a component library we built at Wingspan:
[https://github.com/wingspan/wingspan-
forms](https://github.com/wingspan/wingspan-forms)

------
bokchoi
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.

------
lightblade
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.

------
rrrx3
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.

------
programminggeek
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.

------
j_s
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.

------
nobleach
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.

------
septerr
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?

------
trjordan
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-...](http://mumbledrantings.blogspot.com/2010/04/reaching-utopia-and-
why-its-not.html)

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.

~~~
x86_64Ubuntu
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.

~~~
trjordan
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.

------
reflectiv
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.

------
arms
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.

------
dustingetz
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](https://github.com/wingspan/wingspan-forms)

------
subv3rsion
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.

~~~
reflectiv
> 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.

~~~
subv3rsion
That one user "Condor"
[http://www.sencha.com/forum/member.php?343-Condor](http://www.sencha.com/forum/member.php?343-Condor).

------
x86_64Ubuntu
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.

------
syncsynchalt
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.

~~~
ndrake
What are you using, if anything, to replace the UI components ExtJS provides?

------
revel
I liked the part where he quotes himself

------
neves
When I used it, it was documentation hell. You would always need to delve into
the source code.

------
ark15
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.

------
tobltobs
isn't comparing ExtJS with JQuery comparing apples and tomatos?

~~~
lukev
More like an apple and a tomato seed.

~~~
jksmith
Or the Death Star and a tomato seed

------
wnevets
my experience with ExtJS 4 has been a nightmare

