
The rise and fall of Ext JS - myth_drannon
https://medium.com/@ModusJesus/the-rise-and-fall-of-ext-js-c9d727131991
======
LeonM
I developed Ext-JS applications from 2011 till 2017, and during the ExtJS 4
time, it was great. I loved the quality of their documentation, and most
importantly: the ability to comment on each class/method/property etc. This
contained invaluable hints and insights. The community was really good.

Then they upgraded ExtJS (can't remember if it was to Ext5 or 4.x) and deleted
all the comments as 'no longer relevant'.

Then they started to move certain classes (such as a SOAP client) to the
'premium' edition. Which was understandable, but annoying if you just wanted
to experiment with the framework.

Then they removed the GPL edition from the download page, the only way to
obtain the GPL edition was by begging on the forums. Eventually Sencha simply
no longer responded on threads about the GPL version.

Last year I did a small project and attempted to use Ext6, I found it had
become a monster, or even 2 monsters because they split ExtJS into the
'classic' and 'modern' editions, which were promised to be merged eventually,
but I'm afraid that's never going to happen. ExtJS now requires a custom build
system (SenchaCMD) to compile a project, debugging is becoming a nightmare.
Bugs in the build system are rarely solved once reported.

The way I see it: extjs was a great product, but they started treating their
community like sh*t, and after that it all went downhill.

Goodbye ExtJS.

~~~
albeva
I have fond memories of ExtJS until version 4 was released. I used to be huge
advocate of extjs at our company, but I remember feeling horror and dismay
seeing how down hill it went with 4.0. Communication with the community, their
pricing policies, quality, perfomance ... too many issues. We pretty much
stopped using it and ported all our projects away from it. It really was a sad
day.

It was ultimately their mad push to make ExtJS "enterprise" ready and forget
all the good people who helped them and were with them from the start. There
really was this huge middle finger from Sencha to everyone around that time.

~~~
robpalmer
I met Art, the Sencha CEO, back in 2013 after having some positive experiences
using Sencha Touch on iOS to develop consumer-facing apps. He said that the
company was going to solely focus on Enterprise because that's what the
investors wanted.

At the time that felt like it signalled the death of the company. I note that
the successful JS ecosystems we have today are not enterprise-only or
consumer-only.

------
DougHaber
This article misses a point as to why the community was outraged at the
license change from LGPL to GPL. I was testing switching an application to EXT
JS at the time, and I was really liking it. The prototype worked so well that
we were preparing to get the commercial license, and then the license change
happened.

After the change was announced, a number of people said they would fork and
maintain the LGPL versions. One of the people behind EXT JS showed up in
online discussions at the time and insisted that would be a violation.

The problem came from it not really being under LGPL. They tacked on this
extra piece:

    
    
      Ext is also licensed under the terms of the Open Source LGPL 3.0 license. You may use our open source license if you:
    
       * Want to use Ext in an open source project that precludes using non-open source software
    
       * Plan to use Ext in a personal, educational or non-profit manner
    
       * Are using Ext in a commercial application that is not a software development library or toolkit, you will
         meet LGPL requirements and you do not wish to support the project
    

There was some debate over this, since the GPL prohibits further restrictions
in some cases, and a lot of people believed they could ignore those extra
restrictions and treat it as true LGPL.

The EXT JS company in online forums insisted they were wrong, and further
outraged the community. A lot of people, myself included, decided to stop
using EXT JS. We were planning on the commercial license, but the response of
the company didn't feel right, and so like many others, we abandoned EXT JS.

------
catpolice
I remember the moment when I drew a line in the sand and simply refused to use
ExtJS any more: I discovered that the mysterious bug I'd been hunting all day
went away if I removed a comment.

It turns out that ExtJS was building some kind of dependency tree by scanning
my source code (at runtime!) and looking for things that looked like variable
assignments. And it got confused by a commented-out assignment. I don't
remember exactly how this caused things to break, but I do remember walking
through the stack trace, slowly figuring out what it was doing, and then
simply getting up and leaving for the day.

No thanks.

~~~
megous
I doubt that ExtJS was parsing/analyzing JS code at runtime.

~~~
abritinthebay
ExtJS required a custom build system (sencha) so it’s possible it’s related to
that.

~~~
humblebee
This would be my guess as well. I worked on a ExtJS project (v4.0.7 or so), we
didn't use the sencha build tools, but when I started there we had a bash
script which was a 7 iteration sorting "algorithm" that used grep to try and
match the `requires`, `extends`, `model` properties to determine dependency
order. It too also uses commented out code or documentation of usage, as they
were the first lines it saw. I still do not understand how it worked for so
many years. The first thing I did was build a deterministic dependency
ordering build tool using esprima.

------
minsight
Idera bought out a company that I used to work for. They immediately let half
of the workforce go without compensation. They are normally (in Canada)
expected to pay severance, but an extremely optimistic interpretation of our
employment contracts led them to believe that they could let us go and pay
severance to anyone who was still unemployed some lengthy time (If I remember
correctly, about 9 months) later. They are the Gordon Gekkos of the software
world and I wish them absolutely no success. If you get bought out by them,
lawyer up and start searching for a job immediately. If a product that you use
is acquired by them, then start shopping for an alternative.

------
cjauvin
As a solo freelancer, I have developed and maintained an internal management
web app for a small wine importing company from 2012 to this day: a huge
portion of its 15+ KLOCs codebase is ExtJS 4 (the rest is the Python backend)
and I have mixed feelings about it.. Given the heavy use of complex widgets
and layouts (the Grid component in particular does about everything you could
ever imagine, and probably more), I often think that porting to another (more
modern?) framework would be almost impossible.. I regularly browse what's
available, and I'm certain that an upgrade based on a React + Material stack
of some kind would be an interesting evolution, but I'm not sure I have the
courage to undertake such an endeavor (not to mention the fact that my client
probably wouldn't see the immediate advantage). Despite the often-mentioned
appreciable learning curve (which I can't really appreciate anymore since it's
been amortized on so many years and hacking sessions), here are four things I
appreciate the most of Ext JS:

1\. The fact that well-written Ext JS code has a very "declarative" feel to
it, despite being JS

2\. The documentation is very complete and written with love

3\. The dev environment I've been using is very monolithic, and seems very far
from the incredibly scattered stack of tools that seem to slowly poison the JS
landscape and culture, and which we often read articles about on HN

4\. The community (at least when I was interacting with it on a more regular
basis) is great

~~~
atesti
>the Grid component in particular does about everything >you could ever
imagine, and probably more

Is there anything available comparable with open license?

~~~
TheAceOfHearts
I'm not sure what features the Ext JS Grid has, but react-virtualized [0] is
pretty great for implementing windowing and similar features.

[0] [https://bvaughn.github.io/react-
virtualized/#/components/Lis...](https://bvaughn.github.io/react-
virtualized/#/components/List)

------
Joe8Bit
It's interesting that in such an otherwise complete account of ExtJS that so
little is made of the rise (and subsequent fall) of jQuery.

The author rightfully talks about some of the (terrible) decisions made by the
frameworks owners, that _pushed_ folks from the community; but (imo) the
greater effect was the rise of jQuery, which embraced an open source model
ExtJS scorned and built a staggeringly large community which _pulled_ many
folks from ExtJS.

It's a rather naive view, but Google Trends data from 2004 to now[0] tells a
VERY good version of this story

[0]:
[https://trends.google.com/trends/explore?date=all&q=jquery,E...](https://trends.google.com/trends/explore?date=all&q=jquery,ExtJS,Sencha,AngularJS,ReactJS)

~~~
debaserab2
jQuery is dom traversal and manipulation (with a common ajax interface) -
ExtJS is (was) a UI framework. It's an apples and oranges comparison - I
worked on several ExtJS projects, all of which used jQuery for one thing or
another. I think it's actually pretty accurate to say that frameworks like
angular are more responsible for its decline since their feature sets are much
more similar.

~~~
IgorPartola
That is all technically correct (best kind). But that’s not how it’s viewed by
the scores of people new to web development. Broadly speaking, you can use
both to create a dynamic UI, just at very different levels of abstraction. And
at the time when an ExtJS license cost hundreds of dollars and jQuery was
picking up pace and was proper FOSS, someone new to web development would be
much more likely to reach for jQuery.

The problem with jQuery was that it was almost good enough: it has a system of
plugins which were abused to no end to make things like morals and calendars
and whatnot. And then there was jQuery UI which promised all the loveliness if
jQuery but for UI (I still shake a little when I remember it).

jQuery was and still is great as a helper for “I want to show/hide this thing
on the page”. It’s just the show/hide behavior can quickly morph into 2-4K
lines of spaghetti code manipulating all the UI and having all the business
logic built in.

~~~
johnny22
interesting autocorrect modals to morals.

------
mstijak
People should give more credit to Ext JS. For a long time, Ext JS was the best
choice for enterprise applications and made possible for web applications to
replace desktop dinosaurs, such as inventory, accounting, trading apps, etc.
Sencha is still a great choice for such apps as it offers components optimized
for "data-intensive" apps, but with ES6 and React they are behind
technologically.

My company is selling premium themes for ExtJS and we saw a big decline in
sales with Ext JS 5 and Ext JS 6, especially after the "min 5 license" change.

We're now working on our own framework called CxJS which has features similar
to React, Angular and Ext JS combined. Please take a look if you're looking
for an alternative to Ext JS.

[https://cxjs.io/](https://cxjs.io/)

[https://www.codaxy.com/Themes](https://www.codaxy.com/Themes)

[https://docs.cxjs.io/widgets/grids](https://docs.cxjs.io/widgets/grids)

[https://cxjs.io/examples](https://cxjs.io/examples)

[https://starter.cxjs.io/dashboards/sales](https://starter.cxjs.io/dashboards/sales)

[https://worldoscope.cxjs.io/4v5b3k2](https://worldoscope.cxjs.io/4v5b3k2)

------
joelennon
I think most developers who used ExtJS will have love/hate memories of the
framework. I mostly used the framework from 2007-2014 at a previous job, and
at the time the extent of most developers' JavaScript knowledge was how to
manipulate the DOM with Prototype, jQuery or a similar library. ExtJS was a
whole other animal compared to that with its own Java-inspired class system
that sat on top of JS, a JSON-style declarative approach to design UI layouts
and an extensive data model, store and proxy system that was actually
incredibly powerful.

This day was always going to come, however. Sencha's commercial side has
always had a habit of making bad decisions, and have always focused on
attracting companies rather than developers. This led to initial success on
the enterprise side of things - they had a large percentage of the Fortune 100
on their customer books. The problem was that developers didn't use ExtJS
outside of the enterprise setting. This was primarily due to the decision to
use GPL for the open source license and later to completely alienate
individual developers by introducing a 5-developer minimum purchase for
commercial licenses. Although I was highly competent with ExtJS and Sencha
Touch, I never used it on any side projects mainly because of these issues.
All of this meant that when it came to hiring developers with ExtJS
experience, it was always a struggle, and I believe it is for this reason that
it never took off outside of the big corporates.

------
vintagedave
The article has one false assumption, "that IDERA is a company that focuses on
SQL & other IT performance tools". It's not. They started focusing on
developer tools in 2015, acquiring Embarcadero (Delphi and C++Builder.)

Disclosure: I work there. So I know that they are more than the article says
;)

I personally would suggest waiting and seeing what happens. Usually when there
is an acquisition it is a good opportunity to correct mistakes the previous
owner made. I'd suggest the author of this article actually contact Idera, let
them know his thoughts, rather than posting a blog only. There are real people
at the company and they'll read feedback, and now is a good time.

~~~
exhilaration
There's a dead comment below yours that says "IDERA fired the entire Ext JS
dev team yesterday" \-- is that true or false? Why was it downvoted to
oblivion?

Edit: apparently it's true:
[https://news.ycombinator.com/item?id=15366051](https://news.ycombinator.com/item?id=15366051)

~~~
Joeri
This exchange is pretty much what it felt like to be in the ExtJS community
after jack slocum exited. The sencha people would make grand claims about the
amazing things they would do for the community, then do essentially the
opposite, and afterwards remain mute to all criticism. Nice to see that the
Idera acquisition hasn’t changed anything.

~~~
buckyball
> it felt like to be in the ExtJS community after jack slocum exited

I've to admit that, on some rather rare occasions, I'm thinking about Jack
Slocum and how he gave away/was taken away that thing that once was a truely
remarkable, changeing lib for js, at least if you take into account when extjs
was released. And I wonder what would have happen to him if he invented
something like extjs in our venture capital and crowdfounding times.

~~~
netghost
Oh those were pretty venture capital times as well.

------
jph
Great post. The history matches my firsthand experiences with Ext JS and
Sencha, both in terms of tech and dev community engagement.

If you're curious about what Sencha code looks like:
[https://github.com/SixArm/sixarm_sencha_demo_rest_json/blob/...](https://github.com/SixArm/sixarm_sencha_demo_rest_json/blob/master/app.js)

------
wnevets
As a developer who was forced to use ExtJS, I'm quite glad it fell.

~~~
35bge57dtjku
I remember the debug/dev version of the library being the exact same thing as
the production one. :|

------
andreineculau
As a developer of some "popular" widgets, I owe a great deal to ExtJS because
it taught me that encapsulation, especially in JavaScript, a scripted language
with defacto accessible source code, is just absurd. A simple thing like that
reminded me of functional programming and the rest is history.

Extending a dropdown component meant that i had to copy some closure just to
change a number in a wrapped function, and then update the copy-paste with
each extjs version that touched it. Why? Because the developer didn't know any
better. Similarly now you have "private" fields in classes, etc because some
group wants them, because other languages have them so ofc JavaScript needs it
too. When all you have is a hammer...

ExtJS is very much rooted in me as a "not like this", as much as Douglas
Crockford is preaching a "keep it simple, stupid, like this". I get pleasure
just by hearing him give a talk and saying that while they kids are adding and
adding to this pretty ok language, he only needs tail call optimizations,
because keeping to the good parts is more than enough.

~~~
AgentME
Encapsulation to me is about limiting the supported API. It sucks to release
something, and then find many of your users are depending on accidentally-
exposed private values or functions that are all going to break if you do the
dream refactor needed to fix all the previous problems and enable new stuff.
In situations where the API consumers can't pin an old version (like how a
plugin can't choose the version of the product used), then you end up with a
constant churn of breakage if the system doesn't limit its API exposure to
just the mature public parts. In situations where the API consumers can pin an
old version, you end up with consumers updating as slow as possible only when
they want a new feature occasionally, missing many fixes or other improvements
until much later.

~~~
a-kojeve
I agree. I like functional programming, but at some point, you're going to
have some type of encapsulation, whether at the closure, module, actor, or
network boundary. It's always important to think about what API you're
exposing.

------
megous
I liked ExtJS 3.4 Never migrated to any newer version as it would require
rewrite of our app which would negate any benefit for a long time. I instead
dropped old browser compatibility cruft from ExtJS 3 and moved styling to
sass/CSS3. Gutted all network access code too in favor of modern alternatives.

It worked fine. ExtJS 4 was overengineered and less performant and sencha cmd
was crap.

I like the basic architecture and easy extensibility. Nothing "modern"
compares if your goal is to have a basic app and be able to simply include
another js file at the end to extend/override anything, even if you've not
anticipated it in the basic app.

Nevertheless I'll never use it again for anything new. Its (ExtJS 3) basic
architecture (component tree separate from DOM) is easily replicable in the
modern browser (for the amount of money they're asking for a license) and
that's all I really care for. I don't care for their widgets.

When web components will be supported universally, there will be no need for
separate component tree, and for me that will be it for ExtJS's architecture.

------
janlukacs
Our project management app - paymoapp.com is built on Sencha and we're a bit
worried. We spent a lot of resources building ext6 apps on top of the old ext4
core - hopeful Idera won't do crazy stuff, it's a good framework worth saving.

------
nodelessness
What the community probably didn't realise is that bills had to be paid in a
tough situation. The price rise was not something they did out of greed but
rather something of a last ditch effort to be profitable.

~~~
abiox
perhaps, but why did they let the 'bills' get so high?

~~~
dboreham
VC funded company...

------
dmitriid
And yet, to this day nothing comes even close to what ExtJS/Sencha offered and
offers :(

------
maxpert
With the world full of Reactish frameworks now I wonder if someday we will
return back to these neat frameworks that understood browser limitations
really well and created such a surreal experience in the initial days of SPA.
Names like Prototype JS, Mootools, Dojo etc. where evolving with some great
ideas and Ext JS took it to a whole new level. It's sad to see demise of most
of these libraries (jQuery I think is the only survivor).

~~~
whipoodle
What do you think has been lost?

------
coding123
We used to be in an era where Java developers had JSF and .NET developers had
Webforms - two technologies that were the perfect storm for component vendors.
This is all falling apart now that we have npm and webpack - and the only
thing Java or .NET are good for is the REST service infrastructure they
provide. No company should be using Webforms or JSF type technologies anymore.

~~~
rpeden
So we've gone from using components with lifecycles - in the form on JSF and
Web Forms, to using components with lifecycles - in the form of React and
Angular.

I'm not knocking React or Angular - I use and enjoy them both. And I find it
much more convenient to have components that live entirely in the browser
instead of trying to maintain a stateful UI server-side; I certainly don't
find Web Forms or JSF development to be very enjoyable.

I just find it mildly amusing that front-end web development seems to
continually re-discover old concepts. That's certainly not a bad thing; better
to re-discover good old concepts than to forget them completely.

~~~
taeric
I do wish they would remember some of the previous shortcomings, though.

In a way, I feel like security teams have it easy. Just look at whatever
vulnerability worked 5 years ago on old frameworks. Solid chance it is easily
exploitable on frameworks getting going today.

------
pixie_
Really interesting article. I used ext js for a project and found the
components worked better than anything I've ever used. The grid is super
powerful and polished. Setting up a server backed customized drop down is
super easy. Lookups are powerful. Trees and charts are powerful. Their dialog
builder works super well. A lot of the components can be built, positioned,
embedded with a purely declarative json syntax. If it stayed under the BSD
license I have no doubt we would all be using it today. For building super
data heavy internal enterprise apps it's amazing. Check out their component
examples here -

[http://examples.sencha.com/extjs/6.2.0/examples/kitchensink/...](http://examples.sencha.com/extjs/6.2.0/examples/kitchensink/#all)

Unfortunately I wouldn't recommend using it due to the licensing mess. So
depressing.

------
dustingetz
2010: Backbone.js, Angular.js, Knockout.js released

2011: Ember.js released

2012 (?): KendoUI came out and is just better than Sencha

2013: Angular, Backbone, Ember become mainstream

2013: React.js released

2015: Ember and Angular copy React

2017: React mainstream

I dont think it had anything to do with license. Browsers got better,
javascript got easier, single page apps became popular, competition happened,
Sencha is complicated as hell.

~~~
cmollis
I use Sencha ExtJS every day.. (now v.6). We still have a few applications
with it but have recommended that my clients move to React (for new
development). I have heard a lot of complaints over the years about Ext's
complexity and I guess I would have to agree. It's a bit like writing windows
code with MFC. Not completely horrible if you know like the entire library,
but somewhat daunting at the beginning. The grid control was pretty nice (I
think someone commented on that), but the newer component based architectures
are much better.

------
reed1
Is it just me or medium's comment section is fundamentally wrong? It's always
a pain for me to browse

~~~
rrdharan
It’s not you. It drives me insane. I really don’t understand why it requires
so many page reloads to navigate a thread.

~~~
gidan
If you have too much noise in your comment section, Graphcomment is a nice
(not free) alternative.

[https://graphcomment.com/en](https://graphcomment.com/en)

(I work for GraphComment)

~~~
chimen
"Features" is a 404

------
Macha
Our experience with ExtJS version 2 (later upgraded to 3), was even with one
of the people who literally wrote the book on it, the application still
descended into spaghetti code of a homegrown (very much "grown") framework
around it.

Our later rewrite in Angular was more structured, though I do admit at least
some of that is because it was much of the same team who were now more
experienced (and also no longer treated it as an afterthought to the backend),
and it being the second time round.

Also much like the Angular 1 -> 2 change, Ext 3 -> 4 was a very large change,
and while it was a change for the better (providing many of the features of
our homegrown framework in the core), it was still difficult to upgrade.

------
botskonet
We abandoned it at v4 because it just doesn't fit within the modern landscape.

Building the DOM via JS wasn't going to work for us. We had to re-learn how
make simple things and we were at the mercy of the Ext API. The resulting DOM
was incredibly bloated, different in IE, and was a nightmare to style.

Template-driven apps like Angular, JSX in React, Vue, etc are much easier to
use overall. Less to learn, faster adoption for new developers, cleaner
separation, better portability, and small, clean, and consistent output.

To be fair, the original authors of our application had little idea what they
were doing either and misused/abused Ext, which made everything 100x worse.

------
iamleppert
ExtJS is a prime example of what I like to call "Best Buy Developers".

What are "Best Buy Developers" you ask?

They are the kind of software engineers who shop for frameworks like they are
shopping for a TV at Best Buy. _What if I need to watch YouTube inside my grid
component?!_ What if I need to add in sorting that can only be done on the
server-side? What if the application grows to be 10,000 forms? goes the
thinking. Instead of focusing on absolute simplicity, clean code, minimal
dependencies, pragmatism and addressing the needs of the application at the
present time, they try to predict the future needs of the application without
having any ideas on what the future could possibly look like and not being
product visionaries themselves. Everyone always wants to feel like they can
predict the future and have solutions ready for problems that don't exist yet,
but most of the time they're wrong and the abstractions created in the
process, in retrospect, look rather crazy. I speak from experience here.

At the time ExtJS was becoming popular, there was a big desire to duplicate
the desktop look and feel in the browser. Anyone remember the ExtJS desktop
interface, complete with start button??? I'm guilty of making on those beasts,
complete with graphs and windows that could be dragged and minimized. It made
for good demos, but wasn't useful. It turns out that the web offers a lot
better UI's and UX interaction concepts than desktop apps and it was a poor
decision to try and duplicate 1990's and early 2000 UI paradigms in the
browser. It was cool at the time you could duplicate a Microsoft Access style
fancy filter grid component (and to your boss who didn't know about ExtJS it
made you look cool), and frankly many people latched on to it because it was
beyond their abilities to do in raw HTML/CSS, and the API was well done, and
hid a lot of the early complexity with doing more complicated layouts in CSS
and javascript and slow browsers of the day. For your typical engineer who
couldn't implement drag and drop using raw mouse events and the DOM, ExtJS
provided an easy way to get their job done.

I was an early adopter of ExtJS (since version 1 and I used 2 and 3). I
remember being excited about the remoting framework and I'd spend a lot of
time dreaming up UI's created with components from the kitchen sink page. I
was excited when the designer came out. I tried to convince everyone at my
current company to use it, thank god they ignored me. I remained excited about
it for a little while longer...

But then something changed. I changed the way I approached software. I no
longer cared about fancy stuff. I started to care more about the actual
product and what it can do, how easy it is to use for the user, and if it
actually solved the problem or not (rather than look fancy or like "big boy"
desktop software). I started to not care about component libraries. I learned
that its more important to have absolute simplicity and pragmatism than a big
framework with a kitchen sink that can seemingly do everything and solve all
your problems.

And just like that, I said goodbye to ExtJS and moved on with the rest of my
life.

------
fulafel
The stage setting sounds a little too grim- JS debuggers (Venkman etc) and
smartphones existed in 2005, and people haven't stopped using editors like vi
or textmate to write code.

~~~
Joeri
I built smartphone web apps in 2005, and I can assure you there wasn’t a
single smartphone browser even close to being worth a damn. Safari on the
original iphone was the first decent browser on a phone, everything before
that was garbage from a JS developer perspective.

It is true that there were some desktop debugging tools (i remember a js
debugger for IE6), but it was difficult to set up, and nothing like firebug or
chrome dev tools. Live DOM inspection and editing didn’t exist.

Despite the lack of tooling and the horrors of IE6 I still feel that was a
golden age in web dev. It was a time of wild experimentation, where a single
js dev could gain global notoriety by creating a cool hack or a nice library.

~~~
fulafel
Yeah, smartphone web apps were server side business. But smartphones existed,
windows mobile & symbian ones.

Here's a post on using the Firefox DOM inspector from 2005:
[http://www.codestore.net/store.nsf/unid/BLOG-20050228](http://www.codestore.net/store.nsf/unid/BLOG-20050228)

------
rhapsodyv
I love ExtJS, and still use the version 5. This post is very true for me too.
I didn't upgrade to version 6 because the new license system and the last
versions is still very unstable in my tests.

But I will really miss the JSON-way of creating interface. With Xtypes
everything is defined as a json object. And is incredible the customization
options of their components. Other thing that I will miss a lot is how well
integrated is the presentation components with their data layer.

------
lokerfoi
What's the best way to migrate from ExtJS (50k LOC codebase)?

They had many excellent components, buffered lists, grouping in lists, tree
panels etc. So many useful components.

Is there an alternative?

~~~
dustingetz
Probably react because you can do it piece by piece - you can embed react
inside other frameworks

These screenshots are from 2014 but have React and KendoUI playing together:
[http://curator-lilita-10664.bitballoon.com/related-study-
ite...](http://curator-lilita-10664.bitballoon.com/related-study-item-
picker.png) [http://curator-lilita-10664.bitballoon.com/faceted-study-
ite...](http://curator-lilita-10664.bitballoon.com/faceted-study-item-
list.png) [http://curator-lilita-10664.bitballoon.com/work-area-
metadat...](http://curator-lilita-10664.bitballoon.com/work-area-metadata.png)

KendoUI and Sencha are pretty much the same thing so I would expect you not to
have much trouble.

------
jugg1es
For me, Ext was the bridge between Flex/flash development to more native SPA
programming after Steve Jobs decided it would kill Flash. It held my hand as I
learned Javascript, and it gave me the space to fail when I realized I
couldn't use for-in in a javascript app. It also hid away the core
functionality under such a huge layer of abstractions that it was impossible
to debug anything in the framework. I loved Ext though.

~~~
rhizome
Heh, yeah. I often see this ahistorical "LOL why did anybody ever use this
loser code" attitude, when the last 10 years have seen a tremendous transition
in front end technologies and development practices. See also: YUI.

------
harel
Interestingly I found ExtJs (3) when I was evaluating every single data grid
component there was. I found theirs to be the best at the time (2009) and went
all in to the framework. Someone mentioned a love/hate relationship and that's
pretty accurate. The level of polish on it was unlike anything else at the
time but it was an all-in proposition. You had to buy into the eco system and
stay in to use it.

------
k__
I started JS in 2011 with ExtJS 4 and it was pretty awesome.

Later it got too bloated and expensive and I switched to Ember.

Whole other thing. Missed all the widgets ExtJS had out of the box. Also, it
seemed that Ember used MVC like ExtJS, but had a totally different idea about
it.

Now use React and craft most widgets by hand, didn't expect a framework to be
so flexible.

React components feel like using the ExtJS xTypes again, really nice.

~~~
joelennon
Sencha were working on a project called ExtReact that allowed you to use ExtJS
components in React, replacing the JSON-style component declaration syntax
with JSX. This would have been pretty amazing - as ExtJS' biggest strength was
always the variety and depth of their components (especially the grid).

~~~
city41
I feel like newer frameworks are catching up. I recently started using
semantic-ui-react and so far I really like it. It's nowhere near as complete
as Ext (doesn't even have a grid, just simple tables), but the trade off of
cleaner and simpler development is a good one IMO

~~~
joelennon
I love Vue and React. It's the UI layer where things don't match up, however.
There are plenty of examples of UI frameworks, some which sit atop React/Vue,
that on the surface look to have everything ExtJS offers. Ext had hidden
strength behind the scenes though. The Ext.util.Observable pattern for event
handling; the Ext.data package for binding component data to server-side back-
ends using Ajax, REST and SOAP proxies; under appreciated features such as
keyboard navigation and state management with options to persist to cookies
and local storage. At the time it felt bloated and the learning curve was
crazy, but looking back on it in an age where heavy client-side JS apps reign
supreme, it actually doesn't look all that bad.

~~~
city41
I worked at a company for 4 years that used Ext for everything. I got to know
the framework really well. Everything you say is true, but I honestly don't
miss it. I like that React (I've never used Vue), leaves this open to your
choice.

Sencha really wanted their customers to lock into Ext and not be able to
leave. I like that modern solutions are about choice and flexibility.

------
avremel
Can anyone recommend a stable, well documented alternative to Ext JS grids? I
am currently developing with React, and would like to replace our internal
tables with something as fully featured as Ext JS. (Features like remote
filtering, inline editing, custom components, custom queries, etc).

~~~
mstijak
CxJS offers a complete grid solution + all other components

\- [https://docs.cxjs.io/widgets/grids](https://docs.cxjs.io/widgets/grids)

\- [https://fiddle.cxjs.io/?f=vwyHzOO1](https://fiddle.cxjs.io/?f=vwyHzOO1)

Disclaimer: Autor here

~~~
avremel
What about remote data? I don't see any mention of built in options for remote
sorting, filtering and editing.

~~~
mstijak
Remote data works just fine. CxJS grid exposes sort information which can be
combined with filters and pagination to get data from the server.

[https://docs.cxjs.io/examples/grid/pagination](https://docs.cxjs.io/examples/grid/pagination)

------
everdev
ExtJS was a web client of mine from '09\. They were well funded, but always
seemed more focused on the next round of funding than their product. Also,
they seemed to penetrate the corporate market, but not the average developer.
Some smart people on that team though.

------
bertolo1988
Someone please explain me the difference between Override, Extend, Plugin and
Mixin.

And what happens when i apply all of them in any order to a given method.

Could you also explain why basing your development on overriding and extending
seemed like a good idea? Were people that scared of HTML and CSS?

~~~
Joeri
Extend subclasses, mixin composes into a new class (like traits), override and
plugin augment existing classes, with override replacing existing methods
(which can break with every new release), and plugin fitting into a hook that
remains compatible across releases.

All makes perfect sense to me. They’re standard OO techniques, the novelty was
introducing them to JS developers.

------
ausjke
if memory serves me right, ExtJs is popular in NAS solutions such as synology
and openmediavault, not sure how this will play out for them.

~~~
harel
They can keep running and developing on the old version they use. I think my
synology uses ExtJs 3. As a user, I could not care less - still works....

------
AmIFirstToThink
Caddy HTTP server is a history repeating itself like Ext-Js. It is quite sad.

[https://news.ycombinator.com/item?id=15237923](https://news.ycombinator.com/item?id=15237923)

------
jlebrech
can someone explain to me the benefit of acquiring a totally unrelated company
and how that makes business sense?

~~~
gotofritz
A quick way to inherit a lot of engineers

~~~
blktiger
But then they just fired all of them apparently.
[https://www.linkedin.com/feed/update/urn:li:activity:6316923...](https://www.linkedin.com/feed/update/urn:li:activity:6316923189536571392)

~~~
dwarfland
IOW, business as usual for any Idera acquisition (see Delphi)

------
of
ExtJS - I have good memories of working with its well-documented, excellent
API. For me, it was a precursor to learning iOS development. Only to denounce
Apple shortly after, once I realized that Apple will insist that I continue to
upgrade my hardware to their latest piece of shit perpetually, throughout my
entire life. So yeah. I'm still a web developer. ^_^

------
adamnemecek
> 2005: Smart phones did not exist.

Yeah, ok.

~~~
blauditore
Well, yeah. Phones at that time were mostly just laid out to render WAP pages
only, if anything at all. And virtually nobody used that feature.

Phones actually rending HTML/CSS/JS in a useful way came years later, roughly
2007+.

~~~
slantyyz
>> Phones at that time were mostly just laid out to render WAP pages only

Well, phones in general maybe. _Smart_ phones and PDAs like the iPaq running
Windows CE (or whatever it was called - it had so many name changes I lost
track) had a half decent version of IE on them.

Back around 2004-2005, you were universally mocked for putting a giant screen
against your face when making a phone call. Kinda funny considering how big
screen phones are so popular today.

Some of those Windows devices even had decent res. I had a Toshiba e800 (pda,
not phone) in 2004 and it had a VGA screen, which was quite sharp (esp
considering that even the original iPhone in 2007 had only 320x480).

