torsdag 20. mai 2010

From strings to a centipede!

Long title: "From strings to a centipede - a web developers dive into frameworks, and the realization that tools should not abstract away from technology".

So, a while back I was fed up with not knowing what was going on inside all these web application frameworks and application servers I was struggling with all day long, and why they sometimes was so hard to debug. So I set out to build my own in hope of some better understanding of the situation.

This resulted in a project I called strings ( not because of string theory or "strings" or anything - rather cause I like picking my guitar ). It was a fun project and I've learned a great deal doing it.

One especially important lesson was the way these type of frameworks tend to abstract away important parts of the technology in use, stuff that a web developer should know and think about. Stuff like http requests and responses, http headers, character encoding, data storage. Frameworks tend to create their own metaphors for these things, in order to "simplify" the development process. But what often happens is that this locks developers in some framework specific world where they don't really have control over what is going on. This in turn is a big cause for confusion, debug trouble, unforeseeable time consumption, etc.

Tools should not abstract away from technology!

One can even be tempted to say that these frameworks hides the technology in order to lock developers to specific tools, though I don't think that is the case. But it sure feels that way some times.

There is of course the inverted argument, that developers should not use these tools or frameworks if they are not familiar with their inner workings and the technologies they use. And thats a valid argument ... in some theoretical world without any deadlines, raving project managers, broke-down coffee machines & cars, crippled backs, facebooks to be update, babies to be fed and dogs to be walked. Come on, who ever has the time ( or the ability ) to read and understand 20.000 lines of someone else's code. Not me anyway...

One can always discuss if the technology in use should be more approachable or modeled differently, but thats another discussion. One we would gladly participate in, as soon as we know what the frack we're dealing with today!

Still, there is no need to dangle from the velvet curtains in desperate tears just yet. In the era of free software, ideas flow freely, solutions are swiftly shifting and the distant drums of frustrated developers are becoming ever louder. There has been a lot of very cool things surfacing these last couple of years aiming to solve these exact issues.

Hidden away in a mozilla project called bespin I found a brilliant solution that fits my way of thinking perfectly. It makes use of the WSGI and a brilliant little decorator based router called urlrelay. Adding a startup script and a tiny bit of glue - centipede was born.

Centipede also makes use of other peoples code through the use WSGI middleware ( but these are often small modules aimed at doing one thing - that I can handle ), and might be even be called a framework ( though I don't think it is in the previously discussed sense of the word ) but imho it models the http protocol in a way that puts me in contact with the underlaying principles of web technology. Have a look at the code and you'll see what I'm talking about.

It feels like real knowledge and control to dabble around close to the protocol and still have a great range of tools at my fingertips, and no framework ball and chain to drag around. It's like I now know both the hammer and the bronze, and why it acts the way it does when I hit it.

I'd like to wrap up with a quote I stumbled across on my journey.

"Making a complicated design work is not a sign you're clever, it is a sign you failed" - Gilad Bracha

enjoy.

Ingen kommentarer:

Legg inn en kommentar