Over the past couple of weeks, I was hacking up an MVC framework, mostly for my personal use. I am gonna post the code once I’m done, however. I have decided to go back basically to the drawing board with it, and don’t feel like starting right now (on “vacation” in SF) so I’ll just write about it instead.
Why? Aren’t there enough?
Yes, but I can never quite get what I want. Here’s a breakdown of my reasons.
Complexity/Usability
Cake does too much. Zend is a little more lean, but does things in a dumb way that requires lots of typing for really simple things (Zend:RD Frameworks::YUI:JS Libraries), Symfony just just didn’t appeal. There’s actually a pretty good feature comparison for 10 frameworks here. My basic complaint is that they all have too many checks for features. I think I just disagree with the use of the word “framework”
I’m a big fan of the 37signals guys and their general design/development philosophies. However, I think that with Rails they’ve strayed from their own philosophy of doing less, at least from the point of view of an external developer. From their perspective, it’s fine because they build Rails to do EXACTLY what they need, so it works great for them. But for a developer starting to develop his own application, Rails is the Microsoft Office of frameworks, and all the PHP frameworks followed Rails into intense complexity, even calling themselves “ports” of Ruby on Rails.
I’m all for not solving the same problem twice. But I don’t think very many problems are ever the same in the strict sense.
Scale/Performance
The more built in features your framework has built in, the more difficult it is to “stray” from the framework. Cal Henderson (OH SNAP, NAME DROP!) writes in his book on scalable websites about striking a balance between OGF (One Giant Function) and OOP.
As you move further right [towards OOP], you gain maintainability at the expense of flexibility. As you move left, you lose the maintainability but gain flexibility. As you move too far out to either edge, optimizing your application becomes harder, while architecture becomes easier. (13)
Cal classifies things like Rails towards the right; in my opinion Rails along with PHP clones like “PHP On Trax” 
fall way too far to the right.
Relatedly, this causes a concern for scale. Sure, it’s nice to be able to develop your application quickly and save the $$ and time (so, once again, $$) from your development budget, but you gotta remember – servers cost money, and your application will need servers for as long as it’s live. If you are lucky and your app takes off, you will very quickly realize that every extra little bit of overhead adds up. If your framework just decides to load sqlite on every page view even though you aren’t using it, you’re going to notice (I’m sure there IS a way to turn this off, but Rails would not function until I installed the sqlite3 gem despite the fact that my entire database.ini was mysql). Every file read/write ends up counting.
My goal in creating this framework was to balance usefulness with performance. It does what I think are crucial things to rapid development, but everything that the most basic application ever can live without is left to plugins. If your application doesn’t use databases, you don’t have to define any database confs.
Also, features like “AJAX” are not appropriate to a PHP framework. A PHP framework should facilitate PHP development. Not write JS code. Not rewrite URL’s (hello, mod_rewrite), etc.
Ease of Installation
I’ve only had to install Rails, Cake, and Zend and was just underwhelmed by how much work it took just to get things started. In my interpretation of it, a rapid development framework should allow for a quick start. If it takes me days just to get the damn thing to “Hello, World!” it’s really not worth it.
Dogfood: The Best Reason
The other frameworks just don’t suit my needs. I’m about to knock out a couple of quick freelance projects before I fully transition from student to “real person”; one is very small and simple with minimal db interaction and a tiny CMS component. The other is quite a bit more complex, with a fairly elaborate hierarchy of pages. The first one obviously doesn’t fit the bill for any of the existing frameworks. The second seems like it (I initially was planning to use Cake when the project was first discussed last spring) but actually messing around with cake proved that I would absolutely hate doing an entire project in it. I needed something simple that I could use over and over on projects of varying complexity without taxing the simpler ones with excess complexity.
So Tell Me More!
OK OK! Here’s a little info on the yet-unwritten barebones mvc framework.
The Basics
My baby is due in about 2 weeks. She’s going to weigh in at about 300 lines, probably including doc blocks. Yup. No more. I agree with Crowley’s assessment: if it breaches 300, start cutting back. That is exactly what happened. I was getting a little trigger happy with the plugin system and just starting confusing myself. “Uh oh,” I thought. “If I’m confused, how will an outside user feel trying to figure this out? Actually fuck em – if I’m confused, I’ve written a bad framework, because it should satisfy me first and foremost.”
I’m going to name it Ked. Why that name? Because it’s short easy to type – 2 of the letters are on home row. Just try it: ked ked ked ked::dispatch ked::$settings… it just rolls off the fingers.
There is, however, a metaphoric component – I didn’t get three liberal arts majors for nothing. Keds are my favorite type of footwear. They are very basic, they are comfortable as fuck, they are good for most situations in life (well, if you’re a programmer and don’t have to dress up for work, anyway), and they will rarely let you down. They are perfectly designed to fulfill a very simple function – cover your feet as you walk around. You can, however, put diamonds or Gucci fabric on your keds if your needs call for it. They’ll still be keds, and will still serve their basic telos but will now also serve as a fashion accessory. If you went to high school in the 2000′s, you just think keds are cool no matter what, but that’s neither here nor there.
This framework will aim to be the ked of frameworks – dependable and simple, yet perfect for its one function and extensible to fill whatever other role you need it to.
The goal is to require as little work for every page view as possible, allowing developers to add additional functionality on a per-controller and even per-action basis.
So what’ll it do?
Well, here’s a list of things it won’t do:
- Make you a mayonnaise sandwich
- Interpret and route pretty URLs. Use mod_rewrite, it’s faster.
- Write your XHTML/CSS and JavaScript for you
- Load a bunch of code to handle databases that you don’t use on every load
- Make you type 2 lines of code to do something dumb like set a template variable.
- Make you change your Apache config. Though using some Apache settings is recommended from a performance stand point, Ked will run on anything that runs a reasonable configuration of PHP5.1+ (5.0 might work, but I haven’t thought about it)
- Wipe your sysadmin’s ass by being backwards compatible to PHP4. Ked will use some very new and cutting edge tricks to make your life easier. If you are on a host that still runs PHP4, find a new host. Adding checks for PHP4 fail will inevitably inflate the otherwise trim code base.
Fine, here’s what it WILL do:
- Separate logic from presentation (DUH) and direct traffic appropriately
- Provide an easy way of passing variables. $this->var in the controller will bind to {$var} in the Smarty template (don’t worry, not all $this-> variables will be accessible from Smarty)
- Use Smarty. Smarty rules. Don’t fight it. Though someone is welcome to write a plugin that allows Ked to run w/o Smarty.
- Uhhh… oh yeah, allow some funky plugin interaction.
Pretty short list huh? Yup. It’s a ked.
)