Core wars

Drew Campsie announces ucw-core, the next generation of Uncommon Web, a continuation-based framework for web applications written in Common Lisp. It's the first major announcement since Drew took over development lead of ucw and it seems to focus on establishing a core library of basic technology on top of which other functionality can be implemented (e.g. functionality like those offered by the ucw-ajax). To me as a UCW user this sounds like great news, since I had the impression that ucw seemed to linger in a state of void over the last year or so.

But even more interesting is that ucw just seems to follow a certain trend. For instance, according to the announcement that Ruby on Rails and Merb will merge, one goal is that Rails will be retrofitted to make it easy to start with a “core” version of Rails (like Merb’s current core generator), that starts with all modules out, and makes it easy to select just the parts that are important for your app. The main aspect of such development (at least I hope so) seems to be best described by one of Django design goals): A fundamental goal of Django’s stack is loose coupling and tight cohesion. The various layers of the framework shouldn’t “know” about each other unless absolutely necessary. The python folks have even gone so far as to write down a web server gateway interface specification (WSGI, a quite minimalistic specification).

It will be interesting to see whether there's going to be even more unification, maybe even across language diffferences. I'm not too certain that such an unification would necessarily be a good aim; as always there are probably as many benefits as downsides to it. For instance, a common specification certainly lowers the learning curve for people switching frameworks while at the same time may stiffle further development. Then there's the fact that the different frameworks have different approaches which are certainly reflected in their APIs: for instance, Django explicitly tries to avoid magic at all cost while there's traditionally a lot of magic going on behind the scenes of a Rails application. I'm also not sure where exactly one should draw the line between common "core" functionality and additional "batteries". As an application designer it's probably most important that there is such a line at all so that you can easily pick your poison without having to buy everything.