After listening to the most recent (and previous) episodes of Build and Analyze I got to thinking about frameworks and when and why you might choose one.
In the previous episode Marco advised against bringing 3rd party frameworks into a controlled platform like iOS. His example was using a 3rd party data abstraction layer on top of (or instead of) CoreData. The reasoning being that if you rely on this 3rd party tool – and Apple makes a big change to their framework – you could find yourself in a world of pain. It might take months before your 3rd party data abstraction framework is updated to work with CoreData again. It might never be updated again ever. In either case you’re stuck with a major rewrite on your hands. In this hypothetical situation, you would have been better off just to suck it up and learn and use CoreData to begin with.
Marco goes on to say, though, using something small and less critical to your application, like an XML parsing library, is less risky. It’s probably pretty easy to replace an XML library if you have to.
In the current episode, a listener asked whether the same advice applied to spinning up a PHP web site to support an iOS app he was working on. Marco related his experience of hating CakePHP (agreed) and ultimately writing his own framework just to fit his needs.
I don’t debate his advice, but it did get me to thinking about the topic of frameworks and how to evaluate them.
Software frameworks are so varied in scope, purpose, and scale it’s hard to talk about them conceptually – but when people say “I need a web app to support my iOS app” I can infer a couple of things about what they need and therefor what they mean by ‘framework’.
In general a ‘software framework’ is a conceptual model for solving a problem and a code library which attempts to solve that problem. Doctrine, ActiveRecord, and Hibernate are data access frameworks whose job it is to simplify persisting data in object oriented software applications. CocoaToach is the iOS framework for touch-based user interface applications. Rails, Grails, Spring, Django, Drupal, and Zend Framework are meta-frameworks which all incorporate other frameworks in order to simplify the production of websites. They combine data access frameworks, deployment frameworks, HTTP request routing frameworks, and the like together into a single package.
Marco’s listener was probably thinking about one of these large, general purpose, meta-web-frameworks. I think this is the case because a web app which needs to support multiple iOS clients probably needs a way to expose an api to the iOS app, and a web interface for the same api. A big framework like Rails or Zend would allow something like that fairly easily (that doesn’t mean it’s the right choice for him though).
Just what are you trying to accomplish anyway
Learning a framework can be its own reward. Many big IT shops standardize on a framework or two (for good or ill) and knowing the framework they use can be a leg up in getting hired. Also a learning a framework is a good exercise in learning a programming language or a platform. Learning to “hello world” in java is not terribly useful. But if you build and deploy a small web app with Spring you’ll learn a lot about how java applications are put together, what the pain-points are, and have something to talk about during a job interview.
The knowledge gained when learning a framework is transferrable. Once you understand what an “MVC” is you can apply those concepts to your own custom code or to other frameworks.
But choosing a framework for a new project requires that you understand the job you need to be done, and what the framework is capable of doing.
So. If what you need is a web API, maybe what you need is a means to route HTTP requests to code. You don’t need a full web stack – maybe all you need is something like Sinatra or Silex. It’s not particularly hard to write code which routes URLs to methods or functions…but unless your goal is to write code which routes URLs to functions, you probably shouldn’t spend your time on it. You probably should spend your time on solving the business problems of your app (there’s no framework for that).
If you need to crank out lots of custom web sites or web apps, each one a little different, each one with it’s own set of differing requirements – or if you need to create a very large site which needs to add or change features often – a full stack web framework like Rails, Spring, or Zend might be a better choice. If you need to make lots of web sites that all share very similar features…perhaps you should consider a modular tool like Drupal.
If you want to host a blog, you should sign up for a Tumblr account, because that problem has been solved already. If you want to host a wiki, you should download MediaWiki, because that problem has been solved already.
The point I’m narrowing down to, is that frameworks exist to solve particular problems and they do they’re best work when you can pass off that specific problem to the framework and focus on the critical portions of your project.
If you have to do lots of customization or tweaking to an existing framework to do what you want, then you have chosen poorly and you’re wasting your time.
Baby’s gonna make it on her own
It’s a good learning experience to write your own framework. It might also be fun to do. But when you’re faced with goal oriented project you need to consider if the project goals will be met better, faster, or both by going solo. If the answer is ‘no’ you probably shouldn’t write a framework yourself.