This is a question I’ve been meaning to ask of the core team for quite a while: Will ExtJS remain at the forefront of the manager UI for the foreseeable future and, if so, has bringing its version up to date been considered?
I realize that there were major changes in ExtJS moving from v3.x to v4, making it a difficult move to migrate. And if I recall correctly the way Sencha structured its licensing may have been a barrier too. (For a time it seemed you could only move to post 3.4 versions via a very expensive commercial license). However, current major versions are available under GPL and Community Edition these days (as I’m sure you know).
Anyway, my concern is that investing time to master the nearly decade-old syntax and structure of 3.4, with Ext’s learning curve as high as it is, may dissuade extra developers (at least ones wanting to closely follow the lead of ModX’s core). At first I wondered why base Revolution’s UI on such a complex framework … why not use jQuery or the like? But with time I realized why a non-component based library like jQuery wasn’t chosen. But I do think, short of there being a legal/licensing reason against it, that migrating to a current version would be worthwhile.
ExtJS will certainly be used in MODX 3. I don’t think it will be in the version beyond that, but it’s too soon to tell.
That said, you’re free to use JQuery with MODX. I do it all the time.
It’s theoretically possible that JQuery could conflict with ExtJS when used in the Manager (though not in the front end, where no ExtJS is loaded unless you load it). It’s never happened to me and I think it’s very unlikely unless your choice of variable names is extremely unlucky.
If it did conflict, using JQuery’s no conflict mode would solve it.
There is the advantage that ExtJS is always loaded in the Manager, but your users will almost certainly have JQuery in their browser cache when they visit.
Thanks for chiming in. I’d really love to hear from the lead developers on this though. I am not against ExtJS, just continued usage of a legacy version.
I’m fully aware that you can use pretty much any JS framework you want, but I’m of the mind that the standard established in the core system should be followed. I really don’t care to end up with multiple frameworks being loaded in the backend (possibly multiple times), which you’ll often see in the competition’s CMSs (e.g., Wordpress, Joomla, etc.).
One of the main reasons that ExtJS wasn’t upgraded is because of licensing issues. Sencha’s licensing has changed for their newer versions and it’s not open source friendly unfortunately. The other main reason according to Sterc (who was leading the charge for MODX 3 and the new manager design) was upgrading to a later version would be almost as much work as changing to another framework.
It was decided to focus on modernising the core for MODX 3 and rebuild the manager later on (after MODX 3 is released).
The goal for rebuilding the manager is to have a headless API which would allow for swapping out different manager interfaces. So for example if Vue is chosen for the default manager framework and someone prefers React, they can build a React manager themselves that connects to the API.
@digitalpenguin hit the nail on the head. I’d just like to add (in my role of core integrator) that there’s not been a decision on the future system to use. Everyone has their preferences, and I think we want to learn from the ExtJS 3.x lock-in to avoid that in the future.
There has not been a ton of progress on that front (tho I hear there’s been some promising concepts in the Russian community recently; haven’t looked into those myself yet) and the first MODX3 alpha is pretty close, so MODX3 definitely will still use ExtJS.
Whether or not MODX4 uses ExtJS depends on the community and wether or not we can build something better together. The “core team” does not have enough time or energy on its own to accomplish such a rebuild.