This is a fine introduction/package/setup of all the things I’ve been hearing other savvy devs chit-chat about for the past few years. However, it still doesn’t answer the CMS question: Just because you can make a fine HTML+CSS+JS site, doesn’t mean it’s WordPress/Drupal theme compatible – those two packages add in their own CSS classes, and throw CSS+JS includes everywhere & anywhere based on the plugins. Granted, you should only be using high-quality plugins, but that still doesn’t stop 15 <link />s from being dumped in.
CMSs really, really, really need to allow for this kind of workflow. I’m starting to think that an ideal CMS should be a separate folder that runs alongside this kind of setup; something like:
/app /app/assets/css /app/assets/js /app/assets/font /app/CMS /app/CMS/editor (or something)
Such that CMS is a very JS-calling REST-oriented server (anywhere from LAMP to Node.js). This would allow the HTML pages to have default content, unless there is content in the database. During dev, it’s called via JS (then use some sort of Grunt-build to dump it in on-editor-save). This makes things like end-user form-processing/validation pretty much built-in. Looks like DocPad is pretty much what I’m describing, but a little more focused.
I’m sure you could hack a WordPress or Drupal theme that would do this sort of thing (return JSON instead of HTML), but not sure how efficient it would be, basically using a templating engine on top of a templating engine. Ultimately, WordPress answers the non-developers questions immediately, creating a non-developers’ site. Being a code developer myself, I’ll likely always be at odds with this sort of approach, though I entirely understand it’s raison d’etre, and would really like to see the best of both worlds. The final-final is to incorporate the designers’ world in, answering the “why can’t it be over there” layout & style questions.