MODX 2 manager development, yours likes and dislikes

About ExtJS, once I heard Shaun McCormick (aka splittingred) said that ExtJS has been choosen for backend manager because it's OOP feature. I myself agree with that. You can look at another javascript framework, but no one can match ExtJS in terms of OOP. ExtJS is the most complete and extendable OOP framework, and that really help the development and perfectly fits with MODx.

jQueryUI does not abstract you from HTML. I don't want to know about HTML when I write my app/component. And I want to easy dynamic creation/destroing of components. Yes, ExtJS generates heavy DOM structure, but this enables flexibility and power of components.

I hope we get cool canvas-based fast frameworks in future, but now we have to use slow DOM frameworks.

For future app-oriented frameworks AngularJS looks really nice...

1. Content Editors: Build, enhance and simplify the day to day management tasks for the Content Editor. Plan and simple editors want to do more in less time. This has to be a higher goal then what JS framework is picked. If a "purer" or more likable framework is chosen without improving the job process of the Content Editor, it does not matter.
   
   Also native version control and work flow. Like having a Contributor submit edits to a Content Editor. Have a new version/draft of the same page go live at a selectable time.
   
2. Design: Device Agnostic, Responsive or Adaptive Design out of the box with no addons.
3. Permissions: They need simplified and enhanced, see my proposal: http://tracker.modx.com/issues/9079
4. Developer: Simplify the process of CMP development. Suggestion use MODX to build the Manager and CMPs not Connectors, ExtJS with a mix of Smarty and PHP. It is so easy to build a website with MODX, so why not use MODX to build the Manager?
   
   What I mean by use MODX to build the manager is that it would be awesome if Web Devs Admins could see all manager functions as pages in the tree just like normal pages and edit them just like other pages. So you could choose a "theme/template" on each page or have it set to the "manager theme". This way you could have a Legacy theme to support Revo CMPs and then whatever the new theme would be. For what I see as the most compelling reason to use ExtJS in the first place was the use of the Grid and Panels/Windows. I think a grid could be called/created via a snippet call and so everyone with little instruction could put a Grid on their CMP. The "connector" would just be another page/resource defined as JSON, this again would call on another snippet that does all of the processing with just defining what DB object(s) to use and what processing class to use. Now a user that knows how to build with MODX and basic PHP and DB stuff could create a simple custom functional data grid or CRUD in minutes. Also since this would be built the MODX way each snippet would have Chunks relating to how it is being built. So in theory a developer could build the his own grid theme and have the manager use it and even publish that theme in the Extras. On the same thought form creation has to be robust also and be allowed to be built and extended using Chunks. If the manager is built this way then there would be a very low learning curve on how to build your own CMP. I have been working on a project with the goals described here but it is not ready to be published and currently has no docs with it. If you you are interested and have a good understand of MODX and PHP development you can check it out: RAD-UI.
   

I'm sorry, you want to write an app/component running on the web without knowing about HTML?

var button = document.createElement('button');
button.innerText = 'My button';
button.id = 'button1';
button.addEventListener('click', function(){alert('hello!')});

ExtJS, qooxdoo etc provide all that a developer needs. I just want to focus on programming my extra, I don't want to know what my components use for rendering - div, span, canvas or svg.

HTML initially is not designed for writing apps, so this lacks of many things , that developer needs. Such libraries as ExtJS eliminate these whitespaces...

[Developers building the DOM directly and not using markup] is a clear distillation of what scares me about the road we're headed down because for each layer you throw out and decide to re-build in JS, you end up only doing what you must, and that's often a deadline-driven must. Accessibility went to hell? Latency isn't great? Doesn't work at all without script? Can't be searched? When you use built-ins, those things are more-or-less taken care of. When we make them optional by seizing the reigns with script, not only do we wind up playing them off against each other (which matters more, a11y or latency?) we often find that developers ignore the bits that aren't flashy. Think a11y on the web isn't great now? Just wait 'till it's all JS driven.

I hope we get cool canvas-based fast frameworks in future, but now we have to use slow DOM frameworks.