• Why web frameworks are a bad thing, part 1: MVC
• 502 Bad MVC Framework
• Beyond MVC: A New Look at the Servlet Infrastructure
• MVC and web apps: oil and water
• Is MVC over-designed crap?
• Reflecting on MVC
• Struts 1 Problems

It’s hard to explain in simple terms why MVC is such a poor pattern for web development. I don’t claim any particular success in converting people away from the lure of GUI patterns but in my experience the hardest task is resetting people’s internal model of a web “application”. MVC works pretty well in the traditional GUI where you might have an item (e.g. a document) that you wrap with a model and expose with different views (as an icon and label in a treeview, a larger icon in a window, an editable word processing view, a print preview with different font metrics, a thumbnail presented when the mouse hovers over the icon). You add a controller to enable multiple interations in various views (selecting with the mouse, selecting by using tab key, activating an icon by double-clicking, activating an icon by pressing enter, modifying content by typing on the keyboard, copying and pasting content of the document, copying and pasting the document itself as an icon, dragging, dropping). Yes, in that complex world MVC can help to simplify the programming.

But the Web isn’t so complex. You have resources, which could be models in MVC. But you only have a handful of interactions and they’re all the same for every resource. You also have only a single way to view an item. You could possibly stretch the notion of representation to encompass multiple views but there’s nothing like the huge presentational differences that you get in a desktop GUI – just minor variations of markup language. MVC just obscures the mechanics of the Web, forcing the developer to write code that isn’t necessary and layer on more complexity when the mechanics start leaking through. Once you break your infatuation with MVC you find yourself writing much simpler code that mirrors the operations that drive the Web, and you actually start understanding a bit more about HTTP, the protocol that most frameworks try to pretend doesn’t exist.

What’s interesting is the culture of frameworks and what different communities deem valuable. My sense of it is that on Java, too many web frameworks – think JSF, or Struts 1.x – consider the Web something you work around using software patterns. The goal is get off the web, and back into middleware. Whereas a framework like Django or Rails is purpose-built for the Web; integrating with the internal enterprise is a non-goal.

Earlier this year Andrew wrote:

So, where to go from here? Well, this is certainly the last JSF project I will be working on, and eventually I hope to phase it out of this current one. JSF is web development for Java programmers – those who don’t know much about web applications and even less about HTML, CSS and certainly DDA.

At first pass I wondered if this was is a case of leaky abstractions, but concluded not. The problem isn’t the abstraction that these frameworks provide, rather that they’re changing the metaphor. The web is document-oriented: HTTP is about transferring documents from the server to the client. That’s a great fit for a lumpy information system. There are many other system metaphors but very few of them fit the web’s semantics, just as a transfer protocol would be a poor fit for an event-driven GUI. Emulating one with the other is likely to be a disaster. Most of the time its good to be close to the underlying characteristics of the system you’re working with. It’s good to know that your communication paths may be unreliable and that there’s latency in your messages just as it’s good to know that your user went on vacation for two weeks and only just picked up your application from where they left off.

The Web Architecture Lab would be a work area for specifying and experimenting with the interrelated shared agreements (protocols) that make the World Wide Web a happy place. The goal is to produce a central storage for Web protocol evolution, including both existing Web protocols and new ones, that Apache developers can refer to, comment on, prototype alternatives, and provide examples and test cases.

Historically the development of the web has been split between the IETF and the W3C with some mixed results, most notably the confusion over registration of media types developed by the W3C. Is this the start of a unified web standardisation process?

Also, while perusing the Apache Labs page I came across Noggit a fast JSON streaming parser and serializer for Java.

Opera 7.0b2 for Windows, English (US) version

Choose one option:

* With Java 12.6 MB

* Without Java 3.2 MB