Add a jQuery helper to the the MODX core?

@sottwell - I used to worry about the inefficiency of jQuery, but computers are so much faster now that I'm always surprised at how fast even fairly complex jQuery operations execute. I wouldn't say the same for modExt, but I don't think that's entirely the fault of ExtJS. I think it's largely because of the inefficient way it's implemented in the Manager. MODX tends to call a processor and re-draw the whole grid or panel (often twice) for every change, not to mention piecing together whole panels from scratch using JS.

I am not really sure, why ExtJS 3.x is that slow, but DOM calculations are slow and if you use them wrong the slowness is doubled. The main thing that slows the manager is the tree on the left, that is recalculated each load (AjaxManager helps a lot there).

Quote from: Jako at Jul 17, 2015, 02:16 AM

I am not really sure, why ExtJS 3.x is that slow, but DOM calculations are slow and if you use them wrong the slowness is doubled. The main thing that slows the manager is the tree on the left, that is recalculated each load (AjaxManager helps a lot there).

For one, DOM hits are one of the most performance costly actions and ExtJS hits the DOM like crazy to use inline styling to control the layout.

Just a note on how Ext JS is used in MODX:

Some quotes from various Ext JS gurus:

"using Ext.getCmp() is not a good practice for developers"

"Avoid using Ext.getCmp"

"If you’re building an enterprise JavaScript application, you should really avoid Ext.getCmp() at all costs in production code. It serves a valuable purpose as a debugging tool – but depending on this utility method is dangerous."

"My goal is to eliminate the use of Ext.getCmp all together, if possible."

"Ext.getCmp is similar to using a global variable and all its associated problems."

"I worked hard to remove all Ext.getCmp calls from application I'm working on because it was becoming impossible to maintain."

There are over 1700 instances of ext.getCmp() in the MODX code.