This is a problem of perception cause by the inclusion of the default components with MODx (and yes, QuickEdit is included).
This is seen as positive by non-developers, as it makes it easy to quickly create something with MODx. It is completely negative in my mind, as it creates the perception that those default components represent the only way of doing things in MODx. This simply is not true, and by inclusion, these components, however handy to specific people, are going to turn others unnecessarily away.
As a developer, I want a blank slate to work with; a framework that doesn’t get in the way. Not a bunch of generic, easy-to-use components from various sources that do way more than I may need or want them to for a specific task or site I’m developing.
True
In any case, I see developers creating and marketing a whole class of related components around specific javascript libraries for end-users that do not want to deal with such details. That’s what we want. That means we have attracted enough developers to the platform for innovation to continue, and more and more components will start to emerge and thrive.
I think I meant blank slate in terms of components again. In other words nothing more than what is needed to start a project; the lowest common-denominator. This does not mean I want to reinvent the whole vehicle for every project; rather, I want an arsenal of techniques for transporting something from here to there when I start so I can choose the best one for the job at hand.
Honestly the idea of a blank slate personally bothers me as it is counterintuitive for a developer. The blank slate assumes that you have not already envisioned that canvas 100 times over in your mind, that you have never walked those steps with this function or that class or set of classes. Developers--at least good ones I have observed (I spout this off as a student of programming) generally operate on DRY for everything, hording away libraries, and classes and functions either in their head, in a file or in a larger library that they can grab and snatch for each "new" project.
Right; you went back to the lowest common denominator. "I know I need help organizing all these CSS resources, so let’s try this way. It had some benefits, but ultimately it didn’t help, so let’s start over from the what we do know is minimally necessary for dealing with this..."
As an example, I started building a CSS framework for my company and then BlueprintCSS came out then I tried it but now in its latest iteration I have found that the framework has become bigger than the problem it was intended to solve--to have a group be able to work on an agreed starting point for CSS based projects. Now it is file after file after file and a compressor and etc. I decided last project to abandon it, grab the latest version of Eric Meyer’s CSS Reset and rebuild my own starting point. Not a blank canvas but one that has been prepped and has the brushes set beside and one with the paints all out on the pallete.
Now the approach of developers of kernel MODx became definitively clear.
In our case, the lowest common denominator is being a PHP CMS. Not a CSS framework, not an Ajax or Javascript framework, or even a PHP/ExtJS framework. Not a front-end editing solution for everyone. Not a blog tool. Not an image gallery. Not an online shopping cart. Just a PHP CMS. I want to continue to help make managing content easier for everyone involved in the process.