Python folks love frameworks. They put framework in your framework so that you can create a framework. A friend of mine was involved yet another of these framework ventures and was seriously excited when he was trying to explain to me how good the new web framework was and what problems it solves.

This blog post is a long flow of mind try to pinpoint how to define if a framework is helpful for you or not. Though I use a Python framework as an example these thoughts can be applied for any programming language, framework, CMS, etc. out there. I’d be especially interest how Joomla!, Drupal etc. popular PHP platforms solve problems mentioned here.

The framework in the discussion was towards high level of web development, contentish things. To make tailored CMS, and stuff. This framework was on higher level than Pyramid, little bit higher than Django. It is named after an egyptian god and because Egyptian gods have difficult names spelled with symbols, my Finnish mind already lost it.

So the friend of mine was trying to convince me about the need and superiority of this new frame and asked the question: “Do you like it?”

And I answered: “Does it help me to get my work done?”

My question was the right question, but wrong in so many ways. We were discussing about the same thing, but from different viewpoints…. and in this point, the discussion got off the rail. My friend tried to justify the existence of the new framework and I was trying to help him understand what kind of needs I hope a framework would solve for me.

As we put a lot of energy in seemingly fruitless conversation, I become sad. This discussion and thoughts about it keep me awake during the night and I tried to come up a simple way to measure the usefulness of a high level web framework.

Now I have a new question, which in the end is the same question as above, but more communicative. This question was inspired by Douglas Crockford’s talk about Javascript metaperformance and especially the part where he tells that there are a lot of smart people doing web – sometimes they focus on wrong things, but  if you give them a proper target to shoot at they can get amazing things done.

Next time, when someones needs my opinion about a web framework, I’ll ask “How does it do a date picker widget?”

1. Modern Times

To see how my little question works you need to dive into the history of web development a bit.  The web user interaction is much about forms. The forms have input fields and these input fields are wrapped into user interact-able widgets which have additional properties besides simply handling punching of keyboard keys: input validation, typing auto completion, mouse interaction, nice bling bling decoration and effects  and so on… especially when creating things like CMS where the users are expected to input stuff through the browser you need to pay careful attention for the user interaction details.

The purpose of a software development framework is to make the life of a software developer simple and get the thing done.  Because web is much about forms a lot of effort has been put to make form development simple. My question could have been a less form specific; I chose a date picker because it is familiar and everyone has come across one e.g. when booking flight tickets. Thus we should have quite unified idea what we are discussing about. The date picker also tends to be one of the most complex form widgets available in your toolbox, so were are not setting the bar too low here.

2. Last Tango in Paris

Web itself was not originally designed to have or to do rich widgets for easy user interaction. We have a HTML mark-up language which tries to separate content from the presentation. We have a layout language, CSS,  which tries to separate layout from the content, but in the end fails doing so. Then we have a Javascript programming language which pulls strings in your web browser to make HTML and CSS co-operate and  do the widgets using Document Object Model. A model, which was not designed Javascript programing language in mind.

(sidenote: on the day I see bbc.co.uk level site delivering both web and mobile version from the same HTML code  just using different CSS stylesheets I can say that CSS actually delivers it promise to separate the layout from the content)

Now is now and web is steering more and more to the direction where it can do more for the user… or the interaction is more efficient because of richer controls and paradigms, enabled by Javascript and HTML5, can be applied to solve the same old problems. In this world if you do a modern web framework for and expect it to remain on the isolation on the server-side from all the gory details of Javascript and CSS you are doing it wrong.

Doing a web widget is like a dance of several participants who need to co-ordinate their actions so that the individual performances are in harmony and the actors are not stepping on each other toes. A web framework is like premade step guide telling you how to execute your dance. The result is magnificent performance of  0.5 seconds of your site visitor time when he or she subconsciously picks a date in the web form by clickety-clicky, or as on the mobile era, by thumbity-thumbly.

3. Missing in Action

Now, I could have asked “Does it do a date picker widget?” The answer would probably be “yes”, as of course you can put a date picker widget on every HTML page out there. Then I could asked “how?” and then the answer would be something like:

• Download your favorite Javascript widget library (e.g. JQuery UI)
• Toss CSS files somewhere, Javascript files somewhere in your project
• Edit your  main template <head> to have these files included – if you are smart include them only on the pages where the user interaction is actually needed
• Bootstrap <input> fields doing date picking using a CSS class markers or similar markers in the source code somewhere, or have a bootstrap JS running by <input> ids
• Convert between Javascript widget framework date model and your web framework date model in somewhere of the form layers
• etc. etc.

This is what I call a blunt approach. It’s solving the problem of dancing like this:

This all is tolerable if you do it once for your web appy. But what about if you need different widgets on the page too? How about checkbox groups with internal dependencies? Time picker?  Yoyo? Again you need to toss files somewhere, edit head, etc.

When your web application grows this all quickly leads to a mess where you have tens of different files included in the main template. Different modules start to clash with their CSS classes and you need to start resolving the issues by your own hand written CSS overrides. Suddenly the page load times are through the roof, because you are doing too many HTTP requests per page. You need to start thinking about the cache. You need to think about merging static media files. Which leads you to think solving dependency orders between media files.

Does the framework help you solve the problems like above to get the thing done?

4. Notting HIll

I studied industrial engineering and management in University of Oulu (home of IRC – never forget to mention this when I have a chance).  We had a course called Quality which was about quality. You can study subjects like this from very broad perspective especially if your plan is to become a pointy haired boss who doesn’t know crap about what he or she is doing.

The definition of quality is simple. Quality is not the same thing as high value brand (e.g. Mercedes Benz). Quality is not the same thing as faultiness (no bugs in the delivered software). Quality is about whether the customer is satisfied what he or she gets.

The customer of a software framework is a developer. What the developer is buying is a tool to make delivering software more easy – to get the thing done by the end of the day.

My friend was telling how high test coverage the framework has. This is a nice trait for a framework. Higher the test coverage, the less  bugs you are likely to encounter. Essentially this is faultiness.

Now a bad, but thoughtful, analogue: in industrial engineering faultiness comes with a price. On your production line you’ll pay a high cost of 100% faultiness products. You usually want to do testing by sampling and simply let few bad products slip through instead of having the high cost of testing every single manufactured item. In the end, the testing cost of the product is away from the other areas of product development and manufacturing (features, delivery options, etc.)

Faultiness is important, but it does not make high quality software framework alone. Inspired by the leaked rant of Steve Yegge if you dial test coverage 100% but have no accessibility you have no product.

Which brings me to the punch line of software framework quality: accessibility. To enable developers get the thing done with the framework it must have documentation telling how you get the thing done.

Django folks get it. Django has always had very detailed documentation and no surprise it won the most of the hearts of Python developers back in 2006ish when the framework situation was different with Turbogears et. al. being still in their strength.  Anti examples would be packages z3c.form or plone.portlets (chosen by a fair dice roll – guaranteed to be random). Both the packages are frameworkish and have near perfect test coverage. Too bad it seems that only 0.0001% of people are smart enough to use these packages and mostly get frustrated whilst trying to get the thing done.

(sidenote: even though z3c.form has plentiful documentation does not primarily address the needs of the framework users)

5. Diamonds are forever

Another trait of quality is that it must be measurable.  The absolute measurement of the quality is the customer satisfaction: how happy people are with your product. However the level of satisfaction is difficult to measure directly. Indirect, easy numbers, are measured instead.

One easy quality measurement  is that you go around and ask random users whether they are happy with the framework. If you do not know any of these developers users yet you can simply follow the chat on a related IRC channel:  friendlier atmosphere usually correlates with happiness which correlates with quality.

But being an engineer I hope we could use something more tangible than random chat around a pint or two.

The most important indirect number of your framework quality could be API documentation coverage. How many of the functions of your API have sane helpful documentation or documentation in the first place? As this number  translates to how easily people can pick up your framework and simply read how to get things done with it. Especially with Python a good API documentation (parameters in, results out) is important because Python has poor statistical code analysis or auto-completion support, something  what Java and C# IDEs enjoy.

6. I Am Legend

The another nice thing you can learn about the quality on the university courses is that less numbers you need express the quality of your product the better. It’s over simplifying of things to say how good or bad your product ultimately is. Your pointy haired boss might be able to process few percent scale numbers a day, but less he needs to think anything besides golf, the better. You suggest a new framework to be used for the new software project and the boss takes a decision if it’s good or not, essentially the boolean value or quality. On the rare day the PHB is on his/her brightest the PHB might think one step forward and ask why the framework is any good and then you can answer that the goodness has been tested with the scientific method found from a random blog in the internets.

.. and to shine at the very end of quality simplification spectrum I came up with the following objective decision tree to measure the quality of a web framework:

Is a web framework, CMS, tool etc. any good for modern development needs? Yes / No

Yes if…

• You take one average developer, like me, who has wide general programming experience, but not yet insight how the framework works (don’t pick any super smart guy like the framework developer itself might be).
• You give the developer four hours of time (I am generous about my time today), a hello world style tutorial and API reference manual.
• The developer is able to create a simple form / content type / page  containing a date picker widget with some customizations like template changes or non-default options. The customizations are important because that’s what you eventually will do – you won’t be mass producing hello world applications from the conveyor belt with the framework.
• The resulting Javascript and CSS widget bindings to HTML are handled in maintainable manner and media files are merged, compressed and HTTP cache headers are set  properly.

…else no.

This is just a litmus test. It doesn’t necessary tell how good a framework is, but if the test fails then it might be a sign that the framework is either not a developer friendly or is not solving the needs of modern web frameworks. The most possible failure mode is that there are no API documentation at all –  which means that the project is not disciplined to communicate what problems the framework should be solving in the first place and is worth as much as any random bunch of code you can find from the open source archives.

Also, this blog post is just guidelining: no need to nitpick the details unless they advance the humankind somehow. As mentioned before, the blog post tries to give a good target to shoot at and highlights what kind of facts you might need to communicate out to success as a software development framework. Please feel free to challenge me, but as far as I am aware, none of current web frameworks or CMSs passes this test.

Finally, how the proper dance of HTML, CSS and Javascript should look like, Chuck Norris style:

 Subscribe to RSS feed Follow me on Twitter Follow me on Facebook Follow me Google+