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 r…
I doubt that ExtJS was parsing/analyzing JS code at runtime.
The rise and fall of Ext JS
91–100 of 134 posts
Re: The rise and fall of Ext JS
#92Re: The rise and fall of Ext JS
#93Earlier quoted context omitted.
I doubt that ExtJS was parsing/analyzing JS code at runtime.
ExtJS required a custom build system (sencha) so it’s possible it’s related to that.
Re: The rise and fall of Ext JS
#94As 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 of…
Is there anything available comparable with open license?
Re: The rise and fall of Ext JS
#95Earlier quoted context omitted.
I doubt that ExtJS was parsing/analyzing JS code at runtime.
ExtJS required a custom build system (sencha) so it’s possible it’s related to 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).
Re: The rise and fall of Ext JS
#96Extending 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.
Re: The rise and fall of Ext JS
#97We 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 me their approach seems absolutely brilliant, pushing even event handling to completely declarative code.
Re: The rise and fall of Ext JS
#98The 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…
Here's a post on using the Firefox DOM inspector from 2005: http://www.codestore.net/store.nsf/unid/BLOG-20050228
Re: The rise and fall of Ext JS
#99The 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 opportuni…
There's a dead comment below yours that says "IDERA fired the entire Ext JS dev team yesterday" -- is that true or false? Why was it downvoted to oblivion? Edit: apparently it's true: https://news.ycombinator.com/item?id=15366051
We'll see how that turns out.
Re: The rise and fall of Ext JS
#100I 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 r…
I doubt that ExtJS was parsing/analyzing JS code at runtime.