
Ask HN: Why is ExtJS not getting any traction? - porker
It&#x27;s 2014. I&#x27;m looking for a rich-widget JS framework (datagrids, forms, widgets - all the stuff you need for building desktop-equivalent admin focused apps) and all I find is Sencha&#x27;s ExtJS.<p>Yet everywhere I turn (esp on HN) people are talking about AngularJS, EmberJS and Backbone-based solutions. While no doubt great, none seem to be focused on back-office tasks. With the rise of building mobile apps in HTML5&#x2F;JS I&#x27;m surprised - I can&#x27;t be the only person building data-focused apps (and associated CRUD).<p>So, why do you use these, do they have a sweet spot (custom apps, games, some &quot;I&#x27;m a website but I don&#x27;t want to be&quot; malarkey?) and why not ExtJS? ExtJS sucks, I know that - but it looks the most RAD way to develop admin interfaces, data input etc.
======
x86_64Ubuntu
Let me preface this with the fact that I am a Flex dev who ventured into the
HTML/JS/CSS stack during the "Flexodus". Cleary, ExtJS seemed to suit my fancy
more than the other libraries in the JS world.

As far as why it doesn't have traction, I would attribute this to 2 things.
The first being that the JS community isn't really into app development. What
I mean by that, is when you look at JS, and you look at languages like Flex
and Silverlight, you notice a massive disconnect in ideas. In the JS world,
visual components are rarely if ever first class citizens, simple layout tasks
are far more difficult than they need to be, and SPA paradigms are also second
class citizens. After noticing this and poking around, you find out that the
main JS community either doesn't want the solution to begin with, or they seem
to be re-inventing the wheel.

The second strike against ExtJS is the cost. I got a license for it a few
years ago when I was delusional and thought I could use it to replace Flex.
Dropping $1,000 on something when virtually every other tech out there is free
is hard to choke down.

Also, it seemed like a major step down for those of us coming from the Flex
community. Like I said, with JS app paradigms seem like afterthoughts and each
peculiarity wore me down further and further. For instance, if you have a
button and you declare a listener function but misspell it, you don't get an
error complaining that the listener doesn't exist, you get a blank white
screen. Another issue was marshalling data into objects. Whenever I brought
back a Classroom JSON representation, the Student objects in the students
collection remained unmarshalled. I had to use ANOTHER store to get those to
behave as objects. All of these "why on earth is this acceptable" moments led
me to believe such features weren't really in demand in the JS community if
not resented altogether.

~~~
porker
Thank you, that's a great answer! I hadn't considered the different community
mindset.

I'm curious what you settled on instead of Flex?

You've got me thinking wider than HTML/JS, for something which could be more
satisfying (for me): mobile apps could be the way but I need
desktop/browser/cross-platform support; Silverlight I've heard good things
about but again isn't widely used I believe.

~~~
x86_64Ubuntu
I went back to Flex ='(. Like I said, the lack of basic app principles and the
fact the JS community wants to fist-fight you for saying there is a better way
was kind of off-putting. If you want desktop support, you might want to look
at Adobe AIR. There is also JavaFX, but it appears very, very, very half-baked
to me right now.

~~~
cellis
You should really try out AngularJS. The declarative syntax of it reminds me
of Flex quite a bit. I haven't used AS3 or Flex in years and really miss that
environment, and when I started using AngularJS I felt like I got a taste of
it again.

------
lightblade
Having you checked out KendoUI? They seem to be somewhere between the
ExtJS/AngularJS spectrum.

I've used Sencha's frameworks on 3 different projects now, and I still hate
it. For many different reasons:

1\. The learning curve: This is probably something you already know. But you
may not be aware of is the other effects this can cause. If your team consists
of members of different level of experience (from 0+), the code quality is
going to suffer a lot from the lack of knowledge.

2\. ExtJS and Sencha Touch are 2 different products. Today's web app demands
to be runnable on many different platforms. With ExtJS you get point and
click. With Sencha Touch you get swipe and pinch. But what if you're running
it on a touch laptop that needs both point and click and swipe and pinch? I'm
working on a product right now that integrated the 2. While we succeeded at
reaching the goal, the result is not something I'm proud of.

3\. Sencha is a walled garden that makes it hard to integrate other libraries
into it. For the most part, Sencha already have a lot of things that you
needed (like data grid, combo box, etc). But what if you want to do complex
data visualization with d3? Complex interactive behavior with Rxjs? Or
realtime updates with socket.io?

Eventually, I found out that no matter which framework you choose to use,
you'll end up needing to read its source code to understand what's underneath.
If you have to do so anyway, why not pick a framework that's simple to
understand?

~~~
porker
Thanks, I've looked at KendoUI from their 'Preview' days onwards, when the
license was so confused (and no one could answer) that I gave up. I've been
back since and read through the demos, but to be honest I'm not a fan. KendoUI
doesn't feel cohesive, and while I'm pleased they advertise framework
bindings, having their own MVVM implementation seems crazy.

So, I'm biased against KendoUI as my gut feeling says something's not right
with it, but have no actual experience to back that up ;)

Completely agree re the learning curve and hating ExtJS - I've 'used' a bad
implementation of ExtJS 3.2 in the MODX CMF [0] where it powers the CMS's
admin and it's hideous.

~~~
bjourne
The backend integration is completely optional. You can put any REST
controller (given that they follow Kendo's simple protocol) behind the widgets
and everything can be bound using Javascript.

It integrates well with other Javascript libraries. But not so much with
Angular, which is more because Angular doesn't play well with anything than a
flaw in Kendo.

------
kmnc
Most ExtJS apps are probably internal admin apps, but I imagine it has decent
usage throughout the corporate world. 5 Years ago if you were looking to
create a SPA business oriented web-app extjs was the only option really, and
at the time it also looked damn nice (against java generated web-apps).

It seems the ExtJS community has fallen off a bit as the company has (in my
opinion) put it in the rear-view as they focus on Sencha and mobile. I also
never really felt that I have seen what a true ExtJS app could be. The
examples are the same as they were 5 years ago. Only the theme has been
changed. You get a lot for free with the datagrid and charts but they aren't
the only game in town for this.

No one wanted to build customer facing ExtJS apps because of performance
issues, hard to style so that it doesn't look like some dull enterprise thing
and at the time Rails was just getting popular. I havn't touched ExtJS in a
while but building an admin CRUD in Rails would be much easier. The extra
features of ExtJS can be gotten elsewhere and easily integrated.

Angular just seems like a breath of fresh air when comparing it to ExtJS, and
again most of the components can be found elsewhere.

~~~
pisteoff
I think this is exactly correct. I've used ExtJS exactly once and it was for
building an internal, administrative app.

It's also correct that building an administrative interface with Rails or
Django is much easier. In the case of the app I was building we had to
interface with some Django code, so I wrote this Python meta-class that would
inspect Django models and produce classes that would then produce ExtJS
models, widgets, etc. that could then interact RESTful interfaces provided by
the Django app. It worked great but was slow due to javascript blocking
issues. So like you said performance issues were a barrier, but I doubt in
that case it was ExtJS's fault. I've thought about posting that code somewhere
but I'm kind of embarrassed that I actually tried it. After that little
experiment we scrapped ExtJS and built a strait Django application that did
what we needed.

------
Blinkky
Cost. In my day job we use extJS so I know it pretty well. I would have been
the first one to use it in my side project. But because pretty much every
other javascript frameworks is free and the extJS licensing is terrible they
weren't even in the decision.

------
matt_lo
TL;DR: I use Angular (or * framework) simply because I can rapidly develop the
features and adhere to ALL the requirements. ExtJS doesn't suck, but it
typically doesn't fit into scope or doesn't fit all the requirements.

ExtJS is a great way to facilitate development when working with large data
sets that involve (as you mentioned) CRUD utilities along with business
validation constraints. With that being said, these kind of tools (And KendoUI
too IMO) are being stuck inside intranet systems where the custom widgets and
tools remain proprietary. No visibility == no hype.

I work exclusively on FE stacks and if the choice is Angular or any other top
TODOMC* frameworks, typically that means the requirements don't fit well with
ExtJS. Most JS-engine driven apps typically require a responsive
implementation (cross platform is a big business trend), ability to
incorporate a comprehensive design, and being able to do it within a
reasonable amount of time (which is associated with budget).

ExtJS has a ton of overhead (especially browser performance and scalability in
SPA sites), a large learning curve (IMO), and requires a ton of time to
implement custom designs. This doesn't mean there aren't great tutorials or
start kits, but its not something you can master within a week. Responsive
support OOTB isn't there (KendoUI has solutions for this on their framework)
and the only choice for reusable code for portable devices is an adaptive
approach using Sencha Touch. This doesn't mean ExtJS is a bad choice, but
typically ExtJS excels in desktop apps that are data driven with designs that
were made for ExtJS (its rare to not recognize an Ext app if its built on
Ext).

There's my two cents. I'm sure Sencha is going to destroy me if they ever read
this.

~~~
cmollis
Absolutely correct. ExtJS definitely excels at Desktop applications (pushing
and pulling data sets from departmental DB's). That's we use it for and it's
fine for that. However, the learning curve is fairly steep.. 4.x is much
better than 3.x, more structured with some nice MVC hooks. Unfortunately, I
would never use this for anything BUT an internal app.

------
jdefarge
TL;DR: because ExtJS sucks.

Long answer:

1\. The learning curve is really steep. I mean, really really steep. There's a
critical shortage of (good) books, video, and tutorials on the web. I guess
ExtJS' learning resources should be 0.1% of jQuery's. The examples on Sencha
site were still using the 3 version last time I checked;

2\. If you need to customize ExtJS, or need something slightly more
sophisticated than CRUD screen, then you are pretty much on your own. You'll
spend a large amount of time trying to "fight" the framework and your chances
you succeeding are very low;

3\. It's expensive and its open source license has restrictions;

4\. Sencha seems to hide and obscure the access to the learning resources so
that you are pushed towards their paid support.

5\. It's slow;

6\. The error messages (when they show up!) are cryptic.

7\. ExtJS was re-designed for version 4, but some things like the Model
objects are cumbersome and suffer many usage limitations;

8\. It will never be adopted as a general purpose solution on Internet facing
webapps for the reasons exposed above;

------
PopsiclePete
Last time I tried ExtJS, it struck me as a framework made by people who suffer
from an extreme case of NIH syndrome. Personally, I prefer small, light
frameworks that play with other frameworks well. I don't like big "uber"
frameworks that re-implement everything. That's not value, in fact, it's
negative value in my mind.

If I want to manipulate the DOM or do AJAX I'll use JQuery, if I want to do
data binding I'll use knockout.js, etc.

But these are minor annoyances compared to the huge ExtJS no-no for me which
is the fact that ExtJS seem to actually _hate_ Javascript. Or, they targeted
the framework towards people who'd rather write C++ in the browser - giant
"class" hierarchies everywhere. Ugh.

------
wattengard
Could the problem not be the lack of desktop-looking ui-frameworks, but a lack
of willingness to design something that doesn't look like a java swing app
from the 90's. (Yes, ExtJS is butt-ugly).

Could the app you want to write maybe lend itself well to the UI-stylings of
Bootstrap? Or Pure? Or Foundation?

Or maybe you could combine something yourself... Googling Angular CRUD gives
me this: [http://angularjs-webapi-crud-
grid.azurewebsites.net/](http://angularjs-webapi-crud-grid.azurewebsites.net/)

------
ciokan
I mostly use Extjs for admins and such. I would say that it offers little
control over the design, structure and HTML compared to something like angular
which allows full control over the presentation. Creativity room is important.

The licensing is pretty restrictive also and the prices are big.

I wouldn't say ext has no traction. I see sencha going pretty well and I've
worked with extjs since the early days. It just looks more "business oriented"

------
bayesianhorse
The licensing is bad, the control over the design is terrible, and the
experience developing and learning it is painful.

Never ever use it for a client who has any ambitions on GUI design. Figuring
out how to put an extra pixel here or there can take hours...

------
davenonymous
[http://qooxdoo.org/](http://qooxdoo.org/)

~~~
alok-g
I came across this just yesterday. Would love to hear experiences with this.
Thanks.

~~~
davenonymous
I have no experience with ExtJS, so I can't really compare the two. I've only
used the Desktop variant of Qooxdoo.

It's easy to learn, but hard to master. Though there is quite some extensive
documentation, you will have to take glances at the qooxdoo sources to fully
understand some more advanced stuff. And to track down if something doesn't
behave as expected. The source is quite clean and readable though, e.g. the
button class: [http://goo.gl/Zw6zNI](http://goo.gl/Zw6zNI)

There's also a simple playground [http://goo.gl/QAht5O](http://goo.gl/QAht5O)
and an API viewer implemented in qooxdoo itself
[http://goo.gl/xV5tvn](http://goo.gl/xV5tvn)

From the top of my head some random facts:

* Strictly object oriented. Every widget is a class with properties, methods, inheritance, mixins etc. [http://goo.gl/AaPb6w](http://goo.gl/AaPb6w)

* It makes (or rather you should make) heavy use of data binding. Mostly to link widgets to data stores (being populated/transmitted by some sort of rpc call, the app itself or hardcoded etc), but also to bind widgets to other widgets. [http://goo.gl/DxvNWC](http://goo.gl/DxvNWC)

* Backend communication comes in several flavors, but most prominent is the JSON-RPC interface. Qooxdoo provides backends for several languages, but it's also rather easy to implement your own. [http://goo.gl/IjCT8n](http://goo.gl/IjCT8n)

* Communication between objects is done via a simple event chain, i.e. you will use addListener and fireEvent/fireDataEvent a lot. [http://goo.gl/Yxfmot](http://goo.gl/Yxfmot)

* You can mix your project and have some parts compiled and others loaded from source at runtime. We've been using this to create a metalanguage for forms, which streamlined our application a lot. Basically we don't have to write qooxdoo code anymore to create new forms, but just a xml description of it.

All in all qooxdoo helped us more than it stood in our way. I would use it
again.

------
cjbprime
It's pretty restrictively licensed.

~~~
ksherlock
To expand on that, their interpretation of the GPL is that your server code
must also be GPL'd if you use Ext.

Switching from LGPL to GPL (ostensibly to clear up some license issues with
the graphics) killed their mindshare.

------
elwell
Sencha Touch plays rather well with CoffeeScript

------
ablutop
anybody has experience moving from Flex to dojo toolkit ?

