I get this question just often enough to merit a post: “What CMS/Framework should I use for my apps?” The key is “apps”–that tells me the questioner hasn’t thought through his or her problem enough. There is no one answer, but there are several considerations you should keep in mind when deciding at what level you should build a website or web application: CMS, framework, or a custom application.

Frameworks, CMSes, and ground-up custom apps have their places. But they all involve tradeoffs. The key is figuring out what aspects are key for your project and living with or taking strategies to mitigate the tradeoffs you have to make once you pick. Let’s look at them one by one.

CMSes

CMSes are great for management of diverse content in a traditional website. There are subtypes among them, of course (page-based versus object-reuse, and all the spectrum of in-between hybrids), but generally that’s the problem they’re solving. So if you have the need for both traditional content management and a lot of ancillary features (workflow, privileges, versioning, localization, internationalization, etc.) and don’t have time or budget to build them yourself, they’re a good choice. The tradeoff is that a) CMSes have a certain way they expect a site to be structured and applications for it to be written, and if you want to violate them you’re going to find your road a lot harder than other ways of doing things. Also, they have wildly different performance and scalability characteristics. Any time you get stuff for free, you get overhead. Caching, etc., can mitigate, but that can also restrict your functionality unless you plan carefully–and the CMS may not support the kind of programming you’d need to get around it (for example, up to the second personalization can put a pretty big strain on your app).

Frameworks

Frameworks come with less functionality out of the box and make fewer assumptions about how your app is supposed to behave. But they come with assumptions and overhead. Particularly with RAD frameworks, the overhead can have scalability and performance issues that run the gamut from a little to a lot. They’re generalized solutions and so won’t be as tuned to your setup without a lot of work. For instance, do you really need portable database code? If you’re deploying to lots of different environments, sure. But if you’re just going to host it in-house, then no, you probably don’t for the life of most apps. But the gains in flexibility and speed of development may make up for it.

DIY Frameworks

You can tune the overhead to match your situation, but then not only do you have to spend time building the app, you have to spend time building and generalizing the framework. So you can potentially either speed up development even more (SyntaxCMS does this where I currently work, since it is geared toward the types of solutions our strategorists tend to come to) or iron out other limitations. Then of course, you’re stuck maintaining it all by your little lonesome.

POPAs (Plain Old PHP Apps), AKA Custom Development

The classic DIY, but that means that security, error handling, and everything are up to you to build as needed for the app. But I’m not sure Facebook could be built on a framework. Tread here only if you’re confident you need an ultimate level of control. You’ll frequently still find yourself looking for libraries of functionality so you don’t have to rebuild data validation, for example.

So in conclusion, it’s basically about figuring out your requirements and picking a system that has limitations you can live with. Everything else is a matter of reading the documentation (and occasionally query logging or profiling). And here’s the fun part: you should be doing this per project, or choosing projects that match your preferred solution. Otherwise, you’re just going to be attempting to bang everything with a hammer, no matter if it’s actually a screw.