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.
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.
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.
> Then they upgraded ExtJS (can't remember if it was to Ext5 or 4.x) and deleted all the comments as 'no longer relevant'.
Oh, wow.
My observation is that treating documentation thoughtlessly is frequently a leading indicator that "treating their community like shit" is coming soon.
Product folks and developer evangelists: never do this. Never do the thing where you simply blow away a community-grown resource. If you're absolutely sure you're in a situation that's the exception, you are probably still wrong. Wait a year or two after you're sure. Then warn people and give them a year to save whatever they think is valuable.
Any other approach is telegraphing either thoughtlessness or contempt, possibly both.
There were a good ideas in that framework, and it felt like they wanted to build a really exhaustive, fully integrated UI building solution.
The company I worked for at the time had chosen it for the wrong reasons: their first incentive was the desktop-like UI that comes with ExtJs!
But as I dove into it I understood what it was all about.
ExtJs is/was a fat framework and I have felt overwhelmed many times, but if I compare it to our current daily tasks of gluing Stores, Components, and Views libs together for the same result, I am not sure we have improved anything.
I would like to hear someone thoughts on a potential contender.
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.
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.
I doubted it too, until I saw it and could come up with no other explanation. I don't think it was a full parse, just something like a dumb grep for certain patterns. It threw errors trying to import something that was only mentioned in a comment, and removing the comment fixed it. I wish I could find the bug report.
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.
It didn't require it; it was optional depending on how you used ExtJS. In a project I worked on we simply had the minified, master extjs.min.js file included and then we simply referenced and used that.
I don't remember how the build stuff differed but it wasn't required (though I'm sure there was a benefit to using it).
I wish that I had been confused, it was an appalling thing to find. Basically, it was an interaction between the template system (https://docs.sencha.com/extjs/6.5.0/modern/src/Template.js.h...) and their dynamic class loader (https://docs.sencha.com/extjs/6.5.0/modern/src/Loader.js.htm...). The template system used regexes to look for JS expressions to evaluate inside HTML templates and then tried to figure out how to supply them with values. I had some /very/ complicated templates and IIRC it picked up on some commented out bits and ended up triggering the loader's dependency resolution. Again, I'm not saying it was running like a babel-style parser in the browser - it was just regexing for certain expressions and dynamically loading classes based on the results.
I saw a similar behavior in their binding formulas, I noticed the formula method would never get called unless you had used a "get" method inside of it. This may have been documented, not necessarily a bug - but it made me think they were scanning the source code at run time to figure out which events to observe.
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.
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
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
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.
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.
Of course you're right, and maybe I phrased it poorly, my intention was to highlight the jQuery eco-system as the main puller of folks from ExtJ e.g. jQueryUI and the 10,000's of jQuery plugins that replicated ExtJS/Sencha functionality several dozen times over (with various levels of quality).
Angular certainly didn't kill ExtJS. I was on a project that tried to move from Ext to Angular 1. UI-grid alone forced us to stay with Ext. Add in all the other Ext components and moving to Angular along with re-creating everything simply didn't make financial sense.
For what it's worth, I think they later re-wrote in React and integrated the Ext grid in that.
You need to tell google how to interpret the search terms by clicking each term and refining it via the dropdown. In your example, this is obvious because "reactjs" is a flat line at 0 which doesn't make sense.
jQuery came to mind, but mainly because i only foggily remember ExtJS. I was actually thinking of the library that was widely popular before jQuery, the one it actually replaced - Prototype.
While they compete in some way, jQueryUI is more similar to Ext than jQuery itself is.
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.
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.
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.
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?
I imagine because there was no source to back up the claim. There's definitely been an exodus of staff from the company in recent days, but it's not clear what the terms were. For some tweets from former Sencha staff who have departed over the past few days see my comment on another thread:
This is IDERA's way of operating. They're doing the same to Delphi. I've talked to the Delphi product manager about this. He said their way of doing things is to hire contractors on a (mostly) per-bug or per-feature basis, rather than having the people in-house as employees.
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.
> 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.
> "There's a dead comment below yours ... is that true or false?"
I do not know. I don't work in that part and couldn't comment if I did. I'm only commenting to point out that Idera does indeed focus on dev tools, where the article thought it didn't. FWIW, Delphi and C++Builder are still going strong under Idera.
if anyone of the people let go is interested in remote work (we're based in Europe) on an Ext project please get in touch at https://www.paymoapp.com/contact/
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.
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.
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.
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.
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.
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.
It wasn't a last ditch effort, the decision to change the pricing model happened 3 years ago. I think the community would have accepted a reasonable rise in price, it was the decision to mandate a minimum purchase of 5 developer licenses that sealed their fate.
Sencha's biggest failure was not building developer mindshare. If they wanted to sell commercial widgets, they should have done just that - their grid was pretty amazing and is probably the feature that led most people to discovering ExtJS in the first place. Instead they tried to sell an entire framework, with an entirely custom approach to building software. For that model to succeed, they should have made the framework itself free on a liberal open source license, and focused harder on selling services, extensions and tools around it. That way, it would have been embraced by more developers, widened the talent pool and encouraged their big corporate customers to expand the scope of its use in their companies.
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).
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.
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.
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.
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 -
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.
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.
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.
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.
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.
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.
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.
Ha!
If you were working at a company that didn't have to support ie6 in 2005 you must have been on another planet!
My memories of it are very different. console.log was not a thing (it requires a console, right?), attaching a debugger required visual studio, and the debugger was aweful.
And note that was 3 years after 2005!!! And we were still supporting ie6 full force just like everyone else.
Debugging ie6 in 2005 was very difficult.
Also I remember getting my first Android phone in 2008. iPhone was released in 2007. Before that time phones with big screens were not what you would call a smartphone.
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.
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.
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.
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.
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.
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).
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
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.
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.
I avoid stuff like react elements or native base and try to do all components myself.
These things often bring problems when you try to update the framework, because they're always behind.
Sometimes I have to pull in a few components, like navigation or carrousels because things get to complex or I lack the time, but I usually try to let the UI be self-contained.
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).
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.
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.
Idera (the company that acquired Sencha) own Embarcadero, the company who publishes Delphi. There's a third-party product called uniGUI for building Web applications with Delphi that heavily leverages ExtJS at the front-end. I suspect this has something to do with it.
I don't believe this is the reason. Apparently most of the existing team are going. Some key community members and developers' departures are already confirmed.
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. ^_^
>> 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).
Umm, you are completely wrong. I was using Handspring (and Later Palm) Treo starting from 2002 or so, and it did a pretty decent job of rendering major websites. Yeah, Blazer (Handspring browser) wasn't always perfect or fast, but it definitely didn't not "render WAP pages only". It was full web. By the time I upgraded to Treo 650 around 2004 or so, browsing web on mobile was in full swing. A few times when I was in a pinch in the airport I'd pull up Orbitz and look up/book flights on a regular website interface. Also, being on Sprint which just unrolled CDMA2000 and later EV-DO helped tremendously with this experience.
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.