Designing a new web framework
If you look at the example code (on node.js’ homepage) for a webserver, you can see that the API is quite primitive. And this is on purpose; to quote:
In order to support the full spectrum of possible HTTP applications, Node’s HTTP API is very low-level.
Because the HTTP API is so bare bones, I have decided to build a mini-framework on top of it1. What do I mean by “mini-framework”? Well, I mean that it will be something I will tinker around with in my free time, it probably won’t ever be finished, and will probably only ever be used by me or maybe some friends. What I don’t mean by that is something that is half-assed or small in scope. I’m dreaming big here people!
Why build Yet Another Framework? Well, mostly because I like building things. And partly because it is through trying to do something myself that I begin to understand it better. And then additionally, I have small complaints about the popular frameworks out there (And of course I can do it better).
When in the dreaming stage of a project, I like to look at what else is out there for inspiration. I have used three major web frameworks: Rails, Django and Joomla (which, yes, I realize is technically a CMS). I don’t like Joomla at all, so this is the last you will hear of it. But I do like both Rails and Django quite a bit. My experience with both of them is limited to small, simple websites and I have not really ever worked with the source code for either of them. So, take these thoughts as coming from someone who might not really know what he is talking about.
Anyway, without further ado, my thoughts on Rails and Django2.
What do I like about Rails?
- While Rails is both very powerful and quite elegant, it feels especially so if you are doing things the “Rails way”. And by this I mean that if you go along with the default options, then things are very, very easy. So, I like the smart defaults but also the power to easily override them if need be.
- I like the simplicity of the URL routing. I like that you don’t have to deal with regular expressions if you don’t want to. I like that you don’t even have to write URL routes, if you don’t want to.
- I like how easy it is to switch between serving HTML, JSON, XML, etc.
- I like how choosing the appropriate template to be rendered is usually inferred as opposed to declared explicitly. This sort of goes along with that smart defaults thing.
What don’t I like about Rails?
- I don’t like it’s ORM. It tries to make you feel like you aren’t writing SQL, but you still are. Though, this is sort of a complaint about most ORMs.
- I don’t like Active Support. I don’t like that it extends and changes built-in Ruby classes so much. I’m just philosophically opposed to this sort of thing. Keep your extensions in their own namespaces. Plus, it is such a pain to have to keep track of so many damn dependencies.
- I don’t like its size. It feels huge. When you install it, four separate libraries are installed. I prefer small and simple. It should be easy for users to browse the source and putz around. Because of all the metaprogramming in Rails, this is no small task.
- I don’t like that it doesn’t feel like writing in Ruby. Rails almost feels like its own language.
- I don’t like David Heinemeier Hansson. Frankly, I think he is a jerk. And maybe it shouldn’t, but it affects my opinion of Rails.
What do I like about Django?
- I love the idea of reusable apps. In typical web applications, there is so much overlap of functionallity: registration/logging in, blogging, commenting, friends, etc, etc, etc. Anything that can help limit this is much appreciated.
- I like its templating language and system.
- I like generic views. This goes along with the reusable apps point. So many webpages are just
SELECTing something from a database and then passing it to a template.
What don’t I like about Django?
- I don’t like its settings files. Or how applications are organized. Frankly, I find it a major pain everytime I set up a new project. This is the price you pay for not having a lot of rules in place about how your code should be organized.
- It feels like a lot of work. I can’t quite put my finger on why this is but if I get any insight into it, I’ll let you know!
It’s interesting that I have a lot less things I don’t and do like about Django than Rails. Strangely enough, that alone sort of summarizes my feelings about it.
- The ability to bundle up a collection of controllers/views, models and templates into “apps” for easy portability and reuse.
- Smart defaults that hide a lot of the options/power/complexity. I think this is important for getting up and running quickly.
- A code base that is as small and simple as possible.
I also have some ideas on an ORM and templating language, but I’ll save those for another post.
And that’s all I have for now, but as I start playing around, I’ll try and post more detailed thoughts on individual parts of the process.
Like apparently everyone else on the face of the planet: Djangode, Express, Coltrane, Vroom, node-router, etc. ↩
I’m sorry if it seems like I am ragging on these projects or dismissing them as trivial. I don’t mean to do that. Both Django and Rails are amazing frameworks that have changed how I develop websites and how I think about writing code in general. I’m trying to be _con_structive here, rather than _de_structive. ↩