First of all I want to emphasize that I neither look back in anger nor want to blame MODX for their decisions. I just want to explain why MODX doesn't fit anymore for me while ProcessWire does.
I also want to point out that I am the usual freelancer, who designs and implements whole websites. So I am neither a screen designer only nor just a backend developer. Based on that my points for switching the system were the following:
The MODX Revolution Backend is slow. We all know that, no need to explain further. But beside the lack of speed my main reason is the impossibility (for me) to customize the manager in a reasonable amount of time. extJS in my opinion was a bad decision, no matter how well argued the decision was a couple of years ago.
extJS is slow (at least in the way it is used in MODX), it produces horrible code, it is not responsive and above all: It is not intuitive. As a guy who doesn't code the whole day I have no motivation to learn extJS. It is far too complicated. I am aware of the fact that - once understood - it can be pretty helpful for building UIs for your own applications. But the price is way too high.
Handling of data
When I discovered MODX by the end of 2005, it had a very valuable USP: The template variables, which were - in combination with snippets and chunks - something absolutely perfect for me. But even in those old days, Shaun and especially Jason said: If you want to handle a larger amount of data, don't use TVs. They were absolutely right, TVs were not made for that. But everyone did it that way, because it was easy to do so.
In Revo nothing changed (beside the fact, that I felt they got slower, depending on the snippet/caching). So nothing new: Shaun and Jason said: For data, use your own application. Well, so on top of dealing with extJS one has also to deal with MODX as a PHP5 framework. This is totally okay, but MODX closes the door for a lot of people, who can't write own applications. But these are the people that MODX attracted by having the flexibility of the TVs.
Nobody needed PHP to use MODX. The little PHP beginners had to use was straightforward. Now you have to handle objects, know PHP5 and MVC very well, and on top of that have to learn extJS. I think I am not the least talented coder, but that was too much for me. So I took the easy way (TVs, form customization) with bad performing results, even for very simple collections of data.
The focus on the MODX cloud
My feeling is that is has been the only topic for a very long time. But for people who don't want to use it or have other priorities this impression was fatal. Even if this product might perhaps be a great one, the other problems still remain and I wondered why so much energy is put into this topic while there are other problems which concern people like me a lot more.
Talking about mobile
Again, problems with extJS. No possibility to use the MODX manager on an iPad for example. Of course, Mark Hamstra built the mobile version based on jQuery Mobile which is great. But it is just fighting the symptoms, not solving the problem. Also it is a component and does only work with another path and a limited feature-set.
Lack of new features
I heard Bruno's great MIGX will be implemented in the core. That should have happened 2 years ago as requested by many users in the bug tracker 2 years ago. Those are features which other systems (not only PW) have implemented from the very beginning and in a much less cryptic way. Internationalization was done better in Revo, but it was not that intuitive and it is still not finished yet Topics like versioning or even draft versions where on the table long ago, never heard anything of it in the last 2 years. Surely there are components but those are not developed anymore or have been quiet for a long time now.
I don't blame MODX here, I just want to show that there was not as much improvement in the last years as I hoped. One could argue that this is an Open Source System and everyone - me - could contribute. But as I outlined this door got finally closed with the decision for extJS and an own underlying framework.
Then came ProcessWire
ProcessWire (PW) is pretty straightforward. It consists only of pages, those pages are served through templates which have as many fields as I want (only one field - the title/name - is mandatory). Even the user system is build on pages (every user is a page, every setting is a field). PW encourages me to use this fields system to serve as a custom CRUD. So I can build the stuff I usually did with TVs with those fields. And I don't have to bother with speed. It is FAST. And it SCALES.
The APIis a dream. This jQuery style like $pages->find("template=members, first_name=Ryan")->first()->last_name gives me first result of all pages with the template "members" and where the first name is Ryan and prints out the last name field. This was at first also the downside of PW: I have to handle with PHP a lot more. But in an easy way. Besides some foreach iterations I don't need much PHP usually. The decision not to rely on an own or existing template language was hard to understand as I first read it. But now, after several projects I fully agree to these arguments.
The roadmapis promising and the last two minor releases with a lot of cool new features (multi language the easy way, repeater fields to name a few) where released on time / as promised.
The backend uses jQueryUI. I am not a fan of jQueryUI, but in that case it matches the needs pretty well. It is easy for me to use any jQueryUI script in my applications. Yes, now I am able to write my own applications with own interface and such. I can customize the backend very easily and did that from the very beginning for each of my clients.
It is FAST. Even if totally(!) uncached, the system runs faster than an usual MODX installation which wasn't tuned to an excess. I don't know why this is so much faster, but I think it has something to do with those indexed database tables (I might be wrong).
PW has some downsides, for example the lack of a media manager, but I think - regarding the development in the last year (one year!) - this is also just a matter of time.
Ryan Cramer, the developer who maintains the project more or less alone while working half of the day for something else, reacts fast - I mean very fast - to the wishes of the community. If someone argues that some feature would make sense, he tries to implement it. And that in no time. Don't know how he does it, but he does it.
I chose ProcessWire over MODX because the development of MODX in the last two years was not the development I expected or hoped for. And ProcessWire filled that gap in a way, I couldn't have dreamed of earlier. Srsly.