5 ms·

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 wen

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. No thanks.

mooreds 9y ago
Wow. That is truly dailywtf material.
megous 9y ago
I doubt that ExtJS was parsing/analyzing JS code at runtime.
- whipoodle 9y ago
  OK, so what's your explanation?
  - hoskdoug 9y ago
    OP is confused.
    - catpolice 9y ago
      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.html 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.html 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.
      - skinnyarms 9y ago
        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.
- abritinthebay 9y ago
  ExtJS required a custom build system (sencha) so it’s possible it’s related to that.
  - humblebee 9y ago
    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.
  - BinaryIdiot 9y ago
    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).
- DCoder 9y ago
  It's quite possible they did do that. For example, Angular parses your source to perform Dependency Injection based on argument names.
  - Akujin 9y ago
    Well thanks for that. Now I know what not to use.
    - jinglebells 9y ago
      That's AngularJS released in 2010. Angular 4 is TypeScript and therefore much less hacky.
    - tomca32 9y ago
      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.
- catpolice 9y ago
  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.
- GroSacASacs 9y ago
  it is possible to read comments on runtime in js and do things based on what you read with a while loop + if else

mooreds 9y ago

Wow. That is truly dailywtf material.

megous 9y ago

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

whipoodle 9y ago
OK, so what's your explanation?
- hoskdoug 9y ago
  OP is confused.
  - catpolice 9y ago
    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.html 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.html 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.
    - skinnyarms 9y ago
      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.
abritinthebay 9y ago
ExtJS required a custom build system (sencha) so it’s possible it’s related to that.
- humblebee 9y ago
  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.
- BinaryIdiot 9y ago
  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).
DCoder 9y ago
It's quite possible they did do that. For example, Angular parses your source to perform Dependency Injection based on argument names.
- Akujin 9y ago
  Well thanks for that. Now I know what not to use.
  - jinglebells 9y ago
    That's AngularJS released in 2010. Angular 4 is TypeScript and therefore much less hacky.
  - tomca32 9y ago
    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.
catpolice 9y ago
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.
GroSacASacs 9y ago
it is possible to read comments on runtime in js and do things based on what you read with a while loop + if else