Stand With Ukraine. Stop Putin. Stop War.

The MODX Manager interface is a very rich interface: there's right click options all over the place, modal windows are pretty much second nature and dynamic validation and AJAX submissions make it a very interactive experience. The design is easy for clients to understand, yet it offers the power users even more power to do the things they need to do. All of that is powered by a library called ExtJS, developed by Sencha. As a very powerful JavaScript framework it generates virtually everything you see in the MODX manager. A newer version is also used for the MODX Cloud Dashboard.

I've been learning ExtJS since 2010, every since I got interested in MODX Revolution development and extending, bending and plainly hacking the sh*t out of it. Tutorials, lots of code gazing and client projects, and over two years later I feel like I'm comfortable with what it can do and understanding the often cryptic errors. At some point, it starts becoming a source of frustration. And I can boil that frustration down to one sentence..

I love ExtJS for what it does, but I hate the way it does it.
~ Mark Hamstra

ExtJS is a dream

Don't leave yet! At least hear me out on this one. After having spent 2+ years learning ExtJS and its implementation within the Revolution manager, I am convinced it's a developers' dream. I totally understand why it was chosen to power Revolution back in the day.

  1. Rapid prototyping and interface building. Just define (basically) a big array, and you have a fully functional interface, completely blended in with the rest of the manager.
  2. Packs a large amount of widgets that are infinitely configurable and customizable.
  3. Through its object oriented philosophy, you can easily reuse other definitions in an object oriented fashion and save the hard work. Define a widget once, use it everywhere.
  4. ExtJS makes stuff work and look fancy across browsers.

In a nutshell, ExtJS is an insanely powerful framework that makes fancy stuff easy to achieve. It takes time to learn (and I bet a more senior developer would pick it up much faster than I did), but once you bridged the learning curve you have a lot of power at your fingertips.

ExtJS is a nightmare

  1. It's obviously a JavaScript framework, and ExtJS builds the interface from JavaScript definitions. There are exceptions where you can take existing DOM elements as basis, but you still need to use (and load) all the JavaScript to use the interface as intended. If an error occurs somewhere, ExtJS tends to decide to show an empty page instead.
  2. ExtJS builds elements with a shitload (yes, that's a technical term) of divs and tables. Here's an example an actual "Save" button. My guess is that it does that to make it look good cross-browser, but it clutters up the DOM and makes it more difficult to cleanly create a custom theme with crazy inheritance and royal class-soups. Truth be told, this seems improved in ExtJS 4.
  3. Similar to the previous point, sizes are *very* often defined inline (style="width: 134px;"). This could be helpful, but it isn't one bit if you try to build a more fluid layout.
  4. The ExtJS learning curve is quite steep. In the context of MODX Revolution, this harms community involvement as the amount of developers improving the core is small, and takes a long time to grow. In a proprietary environment (such as MODX Cloud) this isn't a huge concern as you can invest in training and hire the right people, but I'd argue it is a huge problem in the open source scene.
  5. The ExtJS licensing has historically been vague, at least in our context.
  6. ExtJS is slow. Not only does it have to load a few megs would worth of javascript before it can even start building your interface, but it's not particularly fast in doing that in many cases.

Despite being a big proponent of ExtJS for the reasons mentioned earlier, over time I have become more frustrated with the cons of the framework that I believe are doing serious harm to community involvement in Revolution. Learning ExtJS has been a great business decision (it made up probably a good 85% of my freelance work), but as I'm a big community fan I'd rather see something a bit more.. approachable.

The Ideal Framework

So, taken the above considerations, what would be The Ideal Framework for a MODX manager? Here's my personal list of requirements.

  1. Easy to get started with, plenty of existing documentation and tutorials.
  2. Easy to extend and capable of Object Oriented paradigms to cut on development time (rapid prototyping) and code duplication.
  3. Large set of available widgets to build interfaces with, but with a lean core.
  4. Fast.
  5. Progressively enhanced so that users with old browsers can still get a proper experience. As it's a backend I'm fine with it requiring JavaScript, but regular HTML and CSS should provide a baselevel experience.

In my mind (and I can hear sighs coming), jQuery fits a large number of those requirements. Getting started with it is easy, documentation and tutorials are everywhere and the amount of widgets (plugins) available for jQuery is enormous. It easily lets you use progressive enhancements paradigms and considering JavaScript itself is an object oriented language, yes that applies to jQuery as well.

Does just sticking jQuery into the manager provide a maintainable product? No; it needs more thought. The manager is big and complex and just filling up a footer with $(document).ready() tags wont make things better than ExtJS. But I do think a properly implemented object oriented "wrapper" could definitely be what MODX needs.

And that's what I started mocking up.

Introducing a jQuery Based Manager

If you follow me on Github, you may have noticed some recent commits to a new alternative-manager branch in my Revolution fork. This contains a Proof of Concept of how I think a jQuery-object-oriented-wrapper-framework could provide a better experience for the MODX Manager.

So far only the manager login and dashboard has been (mostly) converted, but it's a lot of work. Everything that can be represented as plain HTML/CSS is being converted to that, while other bits of HTML are being used to load up widgets based on a "data-role" attribute.

My first impression of this proof of concept is that it would definitely be powerful, lean and extensible enough to replace a heavyweight like ExtJS, without getting stung by the downsides of the framework. So far (at an early state, obviously), my jQuery alternative sure feels smoother and faster than the ExtJS one too. It needs a lot of work, and tearing out ExtJS of the manager sure is more work than just removing the files, but my belief is that in the end it would be worth it.

So now what?

Now.. I want your feedback. What do you think about ExtJS; and my jQuery-based alternative? Would you support (and better yet; help out) an initiative like this, or am I being a pity fool? Do you want to see a demo?

Depending on your feedback, I want to publish a couple blog posts in the coming weeks on some of the decisions I've made so far and what I think the implications of them are.

Just to prevent any rumors: no I was not asked to work on this for my job at MODX, nor does this proof of concept mean that jQuery is what will power MODX in the future. It's me being curious if jQuery could be a practical alternative and at some point a few weeks ago deciding there's only one way to find out..

UPDATE T+45mins: Despite publishing this article at a time where people are either enjoying a nice drink or a comfortable bed, the response (in the comments, on twitter and on skype) has been awesome! Please do keep it going and let me know anything you'd like to know about the jQuery manager in the comments below. I'll try to answer as much questions about that in a follow up post in the next week or so. Of course, feel free to just go ahead and have a look at the JavaScript. I'll also look into making a public demo available.