ExtJS vs Other Front-End Options for MODX 4.0 and Beyond

[smg6511]

I'm bringing over a conversation I started on the core-contributors Slack channel. Since this will no doubt be a lengthy exploration of what will power the manager in the future, it's best to discuss it here (since Slack entries are hidden when they're older than 90 days for non-pro accounts).

In a nutshell, I'd brought up the subject of ExtJS and whether we would consider continuing to leverage it in the future (assuming we can license a more recent, if not most recent, release). I noted there's been a lot of pushback to its use and that I think there's possibly an unfairly skewed viewpoint that the choice to incorporate it when Revo was born was a mistake. My hunch is that it was not, but the challenges of adoption and the subsequent mistakes made on our part of implementing it have made it seem so.

Full disclosure: I can't call myself an authority on Ext (not even close); my only experience with the framework has been from working with it in MODX. At first I refused to approach it because it was so intimidating and it seemed crazy to put so much effort into understanding the very dated version we use (3.4)—knowing that the framework had changed in a major way beginning with 4.0 and is now at 7.6. But I found that many of its principles have remained, so I eventually began trying to figure it out. It does begin to click after a while.

Anyway, to recount where we were on Slack, here's @Mark-H challenge to me, and anyone else who wants to be involved in the future specification (note that he'd mentioned Vue as an option and I'd asked how well he knew that framework and if he thought we could replicate what we have if we went that route):

Not well enough to go out and build it on my own.
I'd like to flip the question around if you don't mind, why do you think the new ext would be a good idea?
I could rant all night about the problems introduced by a decision over a decade ago but that's not productive and I feel like there's been plenty said about it. So assume we have a blank slate. Why do we go a certain route?

Fair question for sure. I wanted to take some time to thoughtfully answer it considering, as I said above, I'm no Ext guru. And, I've only begun to learn React (which Vue is inspired by) and have just started looking at Vue — so I want to get more perspective on those. In the coming days I'll post some thoughts and more questions on the matter. I'm hoping others will get involved too and keep an open mind about what the options are/should be.

[Ruslan-Aleev]

We put bootstrap in MODX 4 core and let the component developers, where the interface is needed, make it themselves, heheh

[Alexij2]

Cool idea to replace ExtJS with VUE. It remains only to find a sponsor for this case. In fact, whether there will be success if you rewrite everything to VUE is a big question. But there is a desire, for example, and I have. But knowing how much work it is, there will be a choice: either sponsor + Vue or ExtJS 3.4 will remain. Alas, everything rests in this case on money, as it is not sad..

[smg6511]

@Alexij2 (and others) -- To be clear, keeping Ext 3.4 is not a proposed option — moving to Ext 7.0 (or 8.0 if it's out by the time we're doing the rewrite) is.

[smg6511]

I've taken a bit of time to better understand the current major version of Ext JS and wanted to share some observations on why we'd want to choose it over what would probably be the two top contenders (Vue and React). I'm currently doing a deep dive to really get a handle on the framework so I can replicate a small part of the manager as a prototype and test of efficacy. It'll be awhile before I can report back on that, but here's what I've learned so far:

1. One of the biggest advantages of Ext is that it provides everything we need in one cohesive package, one that's been quite actively developed. Any other option we choose is going to require a lot of 3rd party functionality to be wired in. That's going to be harder to build and maintain. Think of all the features we have incorporated—trees, grids, tab panels, menus, contextual menus, toolbars, modals, windows ...
2. Ext has matured a lot since 3.4. It's now built around MVC/MVMM and has session management, routing, one- and two-way binding, testing tools, and is geared toward connecting data via REST, among other things. It's perfectly suited to the goal of the manager being powered via a REST API and being headless.
3. We can much more easily create a responsive manager with contemporary versions of Ext. If you really wanted to go crazy you could build a "native" mobile manager app for ios and android (but we'd not go that far). Point being, there's a lot you can do if so motivated.
4. There are questions around the licensing and its quirks. Ext is GPLv3 at major versions; commercial licensing is required for all others (i.e., currently we couldn't build on 7.6, we'd have to use 7.0). I believe to be completely "kosher," we'd need to move MODX's licensing from v2 to v3. I don't see a problem with this. For some, ideally the license would be MIT — but IMO that amount of flexibility (i.e., you could conceivably produce a customized version of MODX to sell and distribute [right?]) isn't needed. This subject probably needs to be explored further, but my sense is that it doesn't have to be a make or break factor.
5. Re the GPL applying to only major versions: There's been an average of 2.5 years between major releases since 3.x—with a little over 4 years being the longest time between. I think that's okay, considering we're likely more interested in overall stability than minor feature additions. Yes, bugs get fixed too in those minor releases, but any fixes important enough to us could be implemented via overrides when absolutely necessary.
6. I do think Ext is a little more challenging to learn, primarily because the ecosystem is smaller and Sencha's primary business model is clearly proprietary/closed source. It's interesting though, as all versions of the framework code are accessible — it's kinda honor system as far as that goes. It's the support, knowledge, and extras that are harder to come by — that's what your paying for when your a commercial license holder. Even so, there's been an increasing amount of information available out there to learn how to do things and the documentation is very good IMO.
7. One advantage of the framework's proprietary nature is that Sencha is supporting some high-paying, enterprise-level customers. It's not going anywhere and it's going to be very stable for a long time. It's a tradeoff, no doubt.
8. The above said, I don't think learning React or Vue to the degree we'd need to would be all that much easier. I've started to learn React and it's interesting, but it's still a substantially different way of thinking and there are a lot of manager features we'd need to figure out how to implement.

Anyway, that's enough for now ;-)

[Bruno17]

For my understanding, Ext is not really Open Source. What, if 7.0 has bugs, which are fixed with 7.1, 7.2, 7.3 and so on?
We can't switch to the newer versions?
And seems there are a lot of bugfixes, looking at the release notes.
https://docs.sencha.com/extjs/7.1.0/guides/whats_new/release_notes.html
Shouldn't for a OS Product, like MODX, only real OS software be used?

If you are looking for a very complete real OS Framework
https://quasar.dev/why-donate

have a look at Quasar
https://quasar.dev/introduction-to-quasar

[sebastian-marinescu]

If we truly consider rewriting the manager for MODX 4+ with another Frontend-Library, I would vote for Svelte.
I used it on an Agency-Project, and the learning curve as well as the developer-experience/-satisfaction are steep.

It is also positively picked up by other developers:
https://2022.stateofjs.com/en-US/libraries/front-end-frameworks/

And there are already some component libraries out there:
https://madewithsvelte.com/ui-library

And using webcomponents shouldn't be a problem, regardless of which framework we choose.

[sebastian-marinescu]

Just noting it down:

I took some time and checked out the component libraries available for Svelte, and the Carbon Design System by IBM seems the most mature, while also covering most of the needed UI-blocks:

https://github.com/carbon-design-system/carbon-components-svelte
https://carbon-components-svelte.onrender.com/

[pixelstuff]

Does anyone know what they are using for vvveb.com? I like the way the visual editor is handled.