I gave a presentation recently at Web414 that promoted the idea that frameworks were the future of web development. The presentation didn’t go well (It started its slide downhill when I realized too late there would be no way to show my slides. I switched to a more interactive, discussion-oriented presentation, which of course I hadn’t properly prepared for, which in turn only contributed to a further slide.) Still, it served to clarify a little more my thinking on the subject. (Half the reason to make presentations at your local user’s group is to help you view a subject from a different perspective; think of them as “code reviews for your mind.”)

The fundamental point I was making, that the future of web development lies with web application frameworks and not in traditional CMS’s, relies on two rather finely drawn (I cheerfully admit) lines.

The first is on the difference between implementing a CMS and developing for the web. To implement a CMS you typically need specialized knowledge and skill concerning which modules to employ to achieve the aim. The user group got hung up on this distinction, I suspect because many of the CMS implementors thought I was denigrating what they do. I wasn’t. I was simply saying that particular skill set is different from a developer’s skill set. It’s the difference between a production designer and a graphic artist — the graphic artist creates the images the production designer uses. The one who implements the CMS (I’ll call that particular skill set “systems integrator,” for lack of a better term) has a specialized knowledge that comes into play as the modules are assembled to make a web site. The developer’s skill set creates the modules the systems integrator selects from. In the world of the CMS, both skill sets are required, and they are generally found in different people.

The second line is between a traditional CMS and a framework. This line is becoming even finer, as more CMS’s (such as Radiant or Expression Engine) are developed that rest upon published frameworks (such as CodeIgniter or Rails). For my purposes, I’ll define the CMS as a collection of software modules that require no (or minimal) coding in anything other than the standard languages of the web (HTML and CSS) to implement. WordPress, for example, requires little or no knowledge of PHP (the language it’s written in) in order to be installed and used.

I received a lot of push-back when drawing the first line; it seemed to me a lot of the noise was being generated by the implicit assumption that I was saying the systems integrator skill set was somehow inferior to the developer skill set. This isn’t the case at all.

What I was saying was that the systems integrator skill set wasn’t interesting to the developer. This isn’t saying it’s inferior; I could say the same thing about the developer skill set not being interesting to the integrator. It’s not interesting, because at root it’s not relevant to what they do best. Just as excellent graphic artists can make bad production designers, excellent developers can make bad integrators, and vice versa.

These days it’s possible to put together a CMS that adequately meets 80% of most customer’s business needs from a free or low-cost CMS, using off-the-shelf modules. If a developer plans on making more than a subsistence living in that market, it can only be by giving up or seriously limiting the amount of time spent doing what a developer does best (if satisfactory extensions are free, there’s not a good economic case for getting paid to write them from scratch) and instead turning into a systems integrator. Some developers can do this, some can’t, but even those who can do this only succeed by, in effect, ceasing to be a developer.

Therefore the developer has to step out in a different direction. One possibility is to build completely custom coded websites, while another is to develop and sell modules for the systems integrators to use.

If a developer chooses to go the custom-code route, a framework will provide a solid foundation to build off of. Frameworks provide stub code and basic functionality which can easily be extended to cover the precise needs of the site at hand, without incurring the burden of unnecessary code. Built-in or otherwise available framework modules to handle user authentication, for example, form the basis for a more complete user profile system, only requiring the custom features of the user profile required by the community site under development to be written by the developer. The framework does the heavy lifting, while the developer supplies the chrome and the custom business logic, tailored to 100% of the site owner’s needs. Instead of off-the-rack, the result is a custom-tailored fit.

This road isn’t easy. Off-the-rack suits fit most bodies reasonably well, so the potential market is smaller. But at the same time it’s more lucrative, so the two balance. And with a good framework, a creative and knowledgeable developer can provide enough of a value add to make the time and cost more than worth it to the customer. If the “standard” CMS yields 80% of the goal, a good framework under it can often make the other 20% easier to reach.

If the developer chooses to build and sell CMS modules or extensions, the market is tighter. There will be a lot of competition from low- (or no-) cost alternatives exerting downward pressure on the market, still it’s possible for a developer to make a living there. But in taking that route, the developer still is using a framework. In this case, the internals of the CMS itself form the framework that is used to build the extension. Sometimes that’s explicitly designated as a framework, as with Expression Engine or Joomla, and sometimes it’s just a published API, as with WordPress or Drupal. But whether it’s officially named that or not, it’s still a framework.

So what’s the “action list” for you as a developer?

• Look at the framework first. Don’t (please, just … don’t) write your own framework from scratch. There are plenty of Open Source ones out there to contribute to; find one you can live with and while you’re learning it, fix some bugs and add some features to make it better. It’ll be easier to add the features you want to an existing framework than write an entire framework from scratch around those features.
• What CMS choices are built on it? This will feed into the next decision you make. If there are some good CMS choices on the framework, it will make it easier for you to write extensions for others to use, expanding your reach and your market. And, hopefully, your bank account. (Yes, money isn’t everything but the lack of it makes it hard to buy new hardware.)
• Decide — Custom Code or CMS extensions. Make this decision on top of the best framework you can find. The framework itself will provide some of the tools you’ll be using to build the modules, after all, and no one likes working with inferior tools.

There’s you road map. Start your journey.