Wow. That is truly dailywtf material.
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.
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.
To be fair, that was a fallback and was used only if you didn't annotate your dependencies, which is what Angular expected you to do.
Re:The rise and fall of Ext JS
by jinglebells on Friday September 29, 2017 @04:56PM
(#15369136)
That's AngularJS released in 2010.
Angular 4 is TypeScript and therefore much less hacky.
Re:The rise and fall of Ext JS
by GroSacASacs on Friday September 29, 2017 @04:39PM
(#15368974)
it is possible to read comments on runtime in js and do things based on what you read with a while loop + if else
Re:The rise and fall of Ext JS
by abritinthebay on Friday September 29, 2017 @02:23PM
(#15367740)
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
by BinaryIdiot on Friday September 29, 2017 @03:37PM
(#15368425)
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).
OK, so what's your explanation?
OP is confused.
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.
Re:The rise and fall of Ext JS
by skinnyarms on Tuesday October 03, 2017 @02:18PM
(#15394673)
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.
*Note: Not sure which version this was.
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.