The rise and fall of Ext JS
medium.com
medium.com
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.
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.
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.
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.
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.
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
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.
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.
*Note: Not sure which version this was.
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).
Angular 4 is TypeScript and therefore much less hacky.
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
Is there anything available comparable with open license?
[0] https://bvaughn.github.io/react-virtualized/#/components/Lis...
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...
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.
For what it's worth, I think they later re-wrote in React and integrated the Ext grid in that.
I've somewhat fixed it here: https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0... but wasn't sure how to further specify Sencha.
Else Google Trends is worthless data unless you do this.
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://docs.cxjs.io/widgets/grids
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.
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.
Edit: apparently it's true: https://news.ycombinator.com/item?id=15366051
https://news.ycombinator.com/item?id=15365797
Edit: It certainly looks as though the entire team was let go based on the LinkedIn post you linked to in your edit.
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.
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.
We'll see how that turns out.
If you're curious about what Sencha code looks like: https://github.com/SixArm/sixarm_sencha_demo_rest_json/blob/...
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.
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.
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.
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.
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.
To me their approach seems absolutely brilliant, pushing even event handling to completely declarative code.
http://examples.sencha.com/extjs/6.2.0/examples/kitchensink/...
Unfortunately I wouldn't recommend using it due to the licensing mess. So depressing.
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 work for GraphComment)
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.
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.
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.
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.
Here's a post on using the Firefox DOM inspector from 2005: http://www.codestore.net/store.nsf/unid/BLOG-20050228
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.
I even wrote a blog post about it: http://notetodogself.blogspot.com/2008/08/debug-javascript-i...
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.
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.
They had many excellent components, buffered lists, grouping in lists, tree panels etc. So many useful components.
Is there an alternative?
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/faceted-study-ite... http://curator-lilita-10664.bitballoon.com/work-area-metadat...
KendoUI and Sencha are pretty much the same thing so I would expect you not to have much trouble.
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 really wanted their customers to lock into Ext and not be able to leave. I like that modern solutions are about choice and flexibility.
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.
- https://docs.cxjs.io/widgets/grids
- https://fiddle.cxjs.io/?f=vwyHzOO1
Disclaimer: Autor here
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?
All makes perfect sense to me. They’re standard OO techniques, the novelty was introducing them to JS developers.
http://existdissolve.com/2017/09/a-fond-farewell-to-sencha/ https://mitchellsimoens.com/next-chapter-in-2017/ https://twitter.com/dongryphon/status/911278681611370496 https://twitter.com/AnimalNige/status/911152490380451840 https://twitter.com/evantrimboli/status/910988537763323904 https://twitter.com/elmasse/status/906243331541360640 https://twitter.com/LemmonsGrab/status/911703530716618752 https://www.glassdoor.com/Reviews/Employee-Review-Sencha-RVW...
Yeah, ok.
Phones actually rending HTML/CSS/JS in a useful way came years later, roughly 2007+.
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).
In 2005 Palm and Blackberry both had phones with slow, limited but functional browsers. And they had had them since 2003 or so.