Live data from Hacker News

The rise and fall of Ext JS

medium.com

91–100 of 134 posts

Re: The rise and fall of Ext JS

#91
post #64

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.

It's quite possible they did do that. For example, Angular parses your source to perform Dependency Injection based on argument names.

Re: The rise and fall of Ext JS

#92
post #91
post #64

Earlier quoted context omitted.

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

It's quite possible they did do that. For example, Angular parses your source to perform Dependency Injection based on argument names.

Well thanks for that. Now I know what not to use.

Re: The rise and fall of Ext JS

#93
post #64

Earlier 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.

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.

Re: The rise and fall of Ext JS

#94
post #48

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 of…

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

Is there anything available comparable with open license?

Re: The rise and fall of Ext JS

#95
post #64

Earlier 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.

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).

Re: The rise and fall of Ext JS

#96
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.

Re: The rise and fall of Ext JS

#97
post #38

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…

Can you perhaps point me to old concepts that are used in vuejs or react libraries like mobx?

To me their approach seems absolutely brilliant, pushing even event handling to completely declarative code.

Re: The rise and fall of Ext JS

#98
post #81
post #18

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…

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

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

Re: The rise and fall of Ext JS

#99

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 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

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.

We'll see how that turns out.

Re: The rise and fall of Ext JS

#100
post #64

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.

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.
Post reply on HN