I promised Packet Publishing (http://www.packtpub.com/) I'd do a review of jrockway's _Catalyst Web Framework_.
Packet seems to be sort of a boutique publisher who writes about whatever topic they have available passionate, knowledgeable authors. I wanted to do this review because the company that published me, APress!, has a similar mojo going and I believe in it. Its the opposite of the "everyone and their dog" approach.
And I recognize the name. I even met jrockway once, at YAPC. All in all, people who already have a name tend to write better books.
I had an ulterior motive too: I wanted to force myself to sit down and actually learn this Web framework stuff that's all the rage. Like a movie that gets played on TV over and over, I keep seeing bits and pieces of it, and wanted the whole story once all the way through.
I'm having a hard time writing the review. I read the introduction and was ready to write exuberant praise. The rest isn't exactly bad -- in fact it's probably also great -- but it really served to reinforce the bias I went in with.
The writing was great, and the production was solid. It's pragmatic; it briefly (one paragraph) lists advantages of over CGI and then doesn't touch that horse again. Talking about the "over 190 plugins" for common tasks like "config file parsers, logging tools, email, caching, user authentication and authorization, crypto, internationalization, localization, browser detection, even virus scanning", giving examples of building sites in a modular fashion, and so on. Lesser books walk you through; this one guides you. He stops to explain what the various files in the distro are and generally answers the question, "what's that?".
But when the XML, Perl, TT, DDL, XHTML, and configuration for the ORM all got spilled all over the pages, I cringed. As someone wrote, "an ill-assorted collection of poorly matching parts, forming a distressing whole". Granted, he holds off on the DDL/ORM till the second or so example. He talks about how everything is pluggable and you can use whichever modules you want, but it's clear that no matter how you slice it, but in the end, you get a fire truck. Sure, it's powerful, but it's awkward, bulky, difficult to manage, and complex. And while versatile, well suited to very few actual tasks. Yeah, it does a bunch of things for you, but it adds just as many tasks. The "ORMs are Vietnam" essay comes to mind. Seemingly, web frameworks are also Vietnam -- appealing at first, promising at the onset, increasingly difficult to complete the task, but far too complex to take to conclusion.
Don't get me wrong. I'm a fan of domain specific languages. Imagine HTML didn't exist. The Web would work like existing GUI toolkits: under software control, by long series of method calls setting values and building containers and adding things to containers, code would manually create the hierarchical structure of the display document. The code to construct the document would be twenty times larger than the document itself. It would suck.
I just have to imagine that DSLs would combine a lot more effectively. Web::Scraper combined HTML::TreeBuilder, some XPath module, and a few things in a stroke of brilliance such that you need to use none of the modules to leverage most of the effect of all of them. In Catalyst, you have to learn all of the modules to leverage the utility of any of them.
Through the introduction, the bearing on each thing on every other thing was clear. By the time we got into actually modifying the generated code, I was struggling to keep up with the web of relationships of what calls what and what identified is used by what to reference what in what scope. What matches? What depends on what? If I were writing this book, I'd have made a hairy ass diagram to illustrate the inter dependencies. Glossing over it, over simplifying it, sweeping it under the rug... makes it seem easier than it is... until you try to do it yourself.
As it is, things have not changed considerably since Zope.
This reminds me of when I was trying to figure out the combination to a padlock that I had lost the combo for. I was watching a video because I couldn't find text. I didn't know if the whole video was instructions or if he gave a demo at the end so I had no idea how involved the instructions were. You find where it sticks, write down those numbers, then find those that are all multiples of certain other numbers, divide, multiple, pick several from the list fitting something, do some combinations based on the first and second, and so on. I'd have been a lot more prepared for the process -- and a lot more careful -- if I'd known the actual level of complexity of the whole process at the onset rather than a continuous stream one-more-thing.
All the Web framework has to do is take requests from somewhere, figure out what generates the content for them, calls them, let them (none of your business at this point) call whatever they need to generate themselves, and let them have an area to dump temp variables into so the parts of the page can communicate with each other. So, here's my challenge to you: next time you go to use a Web framework, write your own instead. I bet you can do it in 10-20 lines. 100 tops. At a certain point, you have to shift focus from the end users to the developers. I think someone should write the book, _Writing Web Frameworks_.
-scott
