ExtJS: a dream or a nightmare?
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.
- 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.
- Packs a large amount of widgets that are infinitely configurable and customizable.
- 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.
- 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
- 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.
- 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.
- 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.
- The ExtJS licensing has historically been vague, at least in our context.
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.
- Easy to get started with, plenty of existing documentation and tutorials.
- Easy to extend and capable of Object Oriented paradigms to cut on development time (rapid prototyping) and code duplication.
- Large set of available widgets to build interfaces with, but with a lean core.
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..