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.
>> 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.
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.
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.
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.
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.
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.
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.
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.
It's great that you work there, but that does not necessarily mean you know more about the place than someone who does not. So tired of this line of argument being used, especially to defend companies like Google and Facebook. Employees are often the least informed of anyone.
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 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.
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/
> "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.
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.
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.
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.
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 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.
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 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.
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.
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.
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
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.
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).
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.
133 comments
[ 4.2 ms ] story [ 204 ms ] threadhttp://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.
If you're curious about what Sencha code looks like: https://github.com/SixArm/sixarm_sencha_demo_rest_json/blob/...
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...
http://jqueryui.com/
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.
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.
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.
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.
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.
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.
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.
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://graphcomment.com/en
(I work for GraphComment)
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...
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.