MODx 3.0 based on Composer + Laravel 4 and Angular.js + jQuery

I can almost guarantee you we will not be adopting Doctrine or Eloquent as an ORM, or using Zend Framework or Laravel to build MODX 3. Just because existing libraries are available, does not mean they fit the needs of what we are developing. Where they do make sense, we will certainly adopt available libraries, but we can discuss this on a case-by-case basis once we have the foundation laid for MODX 3.

More to the point, MODX 3 will be Composer friendly. And it will support a wide range of document storage back-ends; just not through Doctrine or Eloquent. MODX has it's own persistence layer, that actually is faster in it's raw form than Doctrine (I've not done any benchmark work with Eloquent yet) and I'm going to be discussing this in much more depth in the coming weeks. And the reality is MODX carries an existing API that will not be completely discarded, which is based on that persistence layer.

There will be some BC breaks in MODX 3, but I see absolutely no reason to completely scrap what makes MODX as unique as it is.

Goals:

1. Faster
2. Lighter
3. Simpler

Implementation:

TBD

Personally, I think xPDO is for PHP a serious breakthrough in ORM or ORB or whatever it is called. It should really become a standard itself, if it were better known.

Ok cool.

Here are my two cents:

The big discussion that Mark Hamstra started with a blog post about jQuery as framework for the manager, instead of ExtJS, brings up the point about adaptation, ease of use for developers, and so on. Very valid points I think. I have been using MODx for over 3 years now, developed a bunch of customer websites, but I still get scared whenever I happened to find my self on the modExt documentation. I've never even dared to approach developing something for the manager, or barely even to make customizations (maybe didn't have to?). I do use MIGX frequently.

I started a new web app project recently, doing some research, and deciding on Laravel 4 + AngularJS. And I'm totally blown away with the ease of use (especially Laravel), and how fast I can prototype stuff. 1-2 months of research + learning, of two completely new ways of thinking for me, and it's STILL easier to chew and swallow than MODx and modExt. Maybe it's because I haven't given modExt a fair chance.

To be honest I'm starting to weight pros and cons of MODx and Laravel for things I've always used MODx for in the past. Regular simple to medium sized websites. I'd probably still deliver faster in MODx, but the fact that I'm even considering some (for me) totally new things, over MODx, after 2 months of learning, is pretty crazy.

I really like all these new (again; for me) ways of developing. Composer. Bower. Grunt. Doing things from the command line. Even Git. New database types; NoSQL. And a whole BUNCH of other cool stuff that surfaces every day.
I'm aware that some of these things will disappear as fast as they came, but I'm sure some are here to stay (for a while).
And I really like MODx, but I'm afraid to fall behind all these new cool things and ways to develop.

No law says you have to use MODx for everything. Learning new stuff is fun. Do what seems best for your purposes, and enjoy yourself.

Theoretically, it's supposed to be possible to create custom manager interfaces using whatever one likes. A case of theory over reality, I'm afraid.

Having recently gotten semi-comfortable with ExtJS, I can say that it's completely incomprehensible until you actually create something complex with it. Then it kind of makes sense and you wonder why you had so much trouble with it.

TBH, I think much of the apparent difficulty of ExtJS is mixed up with MODX's way of using it and the interaction between ExtJS and the main index/action file, the controller index file, the controller files, the base JS file, class files, JS widgets/grids, the request handler, the connector file, and the processor files.

It would also be much easier to learn ExtJS (or more correctly, modExt) if there were a tutorial other than the Doodles one for people who want to create a CMP but don't need custom DB objects. The system is complex enough without the added hassle of learning about creating and using custom DB objects at the same time.

All that said, I suspect that the MODX 3 Manager will not be based on ExtJS and that you will be able to use whatever platform you like for CMPs (actually, you can do that now -- my book has an example of a simple CMP that's done entirely in PHP + HTML/CSS). I think you could do any MODX CMP with just PHP and HTML forms if you didn't mind the page reloads.

One thing I don't like about ExtJS is the awful nested mess of divs it uses for its grids. Just do an "inspect element" on any of the Manger's grids and you'll see what I mean.

Many of us have our issues with ExtJS and modExt, and the lessons learned from adopting that framework for Revolution will be as close as ExtJS gets to being part of the MODX 3 solution.

All that said, I'd certainly not be disappointed if someone attempted to code a prototype of MODX 3 using Laravel, or <insert favorite framework here>. I created the original prototype for Revolution using Propel before I decided to attempt xPDO; there are at least lessons to be learned from such an exercise.

I'd like to see someone try Ember JS for the Manager. I'd do it if I had time.

I'd like to see some code of someone trying any of these frameworks to build something like MIGXfe within a few days
https://github.com/Bruno17/MIGXfe

no joke.

I couldn't find any js-framework out there, which is that powerfull for stuff like that as ExtJS, but I would be really happy, someone could show me one and how a working solution would look like.

Wow. MIGX, MIGXdb, and now MIGXfe.
IMO all three should be fully or partially integrated with MODx (3.0). Very "basic", flexible and important functionallity.
Can't wait to find out more about MIGXfe.

It looks like MODx 3.0 will be quite different from MODx Revolution in terms of frameworks, and usability. I'm excited.