NoticeI have moved to Medium. You can find my new posts here. The below posts will stick around for posterity.
Who is this for?
So you want to write your own framework? It’s a web framework, eh? Well, then you are my target audience. Yes, that is to say that this blog post is targeted toward you (just in case you were trying to dodge that bullet). If you’re not contemplating creating a framework, or even better, you are an experienced creator of frameworks then you’ll probably like this as well.
So, you’ve experienced a problem or created some solution in which you’d like to create a framework for or derive a framework from, respectively. Well then, good for you. You’re probably on the right track. You have seen a problem that could be solved better, and have set out to do just that. So my first piece of advice as you start down this path is simple, and is as follows:
It’s quite simple to follow, really. No reason you shouldn’t be able to do just that.
If this is your first framework, then you’re probably all giddy to start working on it. You’re excited about the learning experience, about putting your work out there, about people using it, and < insert whatever else >. I’ve been there. I’ve put quite a bit of work into some “frameworks” that I thought would solve all the world’s problems.
So what happened to those frameworks I was working on? I never released them. For the most part I actually just zipped up the work, put it in my archive, and I’ll probably never look at that code again, let alone actually use the code. You’re probably wondering why. Well, most of the problem is that I didn’t think about what I was doing before I started doing it.
The fact of the matter was, there were already frameworks out there that solved my problems. Did they solve 100% of the problems I was trying to solve? No, but they solved about 95-98%. So, is it really worth it for me to recreate existing work just to make up the 2-5% difference? I think not. I value my time too much to do that. I want to do interesting work and, to me, working on an already solved problem is boring.
I fight this battle all the time. I find myself working on a problem that is in need of some framework and the first thought is to create it myself. I just love creating things so this is where my mind heads first, but I have to stop myself. I know that the first thing I should be doing is seeing what is already out there. See if I can find something that solves most of my problems. If so, then that is what I should be using.
All these little frameworks out there really just cause a lot of clutter. This is especially true of web frameworks. I feel like 2 or 3 new frameworks come out every week. Take Ruby for example. Although most people think of Rails, a quick Google search for Ruby web frameworks turns up:
- Ruby WAF
That list took me about 3 minutes to compile (mostly just the time to type and check the spelling). These were not hard to find. Do I know what more than 2 of them are really about? No. If I’m new to the Ruby world, am I going to read about all of them? No. I’m going to read about the top 3 most-popular and just pick one I like.
Creating Great Frameworks
If there are already frameworks out there that solve a large majority of your problem and if they are fairly popular then, there’s probably a reason. Most likely, they’re quite good. It’s likely that many people have added functionality, reviewed and refactored, and tested thoroughly the framework.
My suggestion to you, clutter framework creator, is that you contribute to a framework that is already out there and being used by an audience greater than one. If you think that there are problems that the frameworks don’t solve, then add a patch, create an extension, etc. Basically, contribute instead of creating clutter.
If you’re problem is truly unique and you can justify creating a framework, then I don’t have any advice for you except this, _If you’re going to clutter my ecosystem, please don’t clutter it with garbage.