Update 28 Sept 2008: checkout the working code at github repository, and a short video demo on vimeo.

I've been swimming in jQuery-bliss for a few months now - thanks Divya & Tien Dung for introducing me to it! I'm yearning to do it on the server-side.

But to enjoy the jQuery-bliss (aka "no special case pattern"), I'd need to be in a problem where I have a document to sculpt. My recent toys (cleartz and tryanslator.. and actually most Javascript apps?) for example, are built the via sculpting way: a very basic HTML structure, then Javascript comes in to flesh out its form and introduce function. A very pleasant development experience overall.

Aside: Back in Java days, I remember I used to hate XML DOM parsing a lot. NodeList? hasChildNodes? But XPath came and suddenly pain became pleasure.

On the server-side, Model (of MVC) stuff seems to fit (maybe sqlQuery( "people[gender='Male']" ).update({ salutation: "mister" }) ?) but ActiveRecord (& Ambition?) is already nice to work with, and I have no major problems there.

My gripe is with the View (and consequently the Controller). Views are generally powered by some templating system. These gnarly things are just a pile of bastardized HTML files good for neither designers nor developers. The best templating systems are only best because you'll choke yourself slower by using them. Anyways, pretend you agree that templates == bad.

Wouldn't it be nice if your web framework 1) loads up pure HTML as a document object, 2) you modify them in the jQuery-bliss way in your Controller, then finally 3) the resulting HTML is spit back to the client browser?

No nasty <? %> } or custom syntax for dynamic content, or loops, or if-else. Just pure HTML with dummy data baked in. 

# display_user.html
<span class="tel">
 <span class="type">home</span>:
 <span class="value">+1.415.555.1212</span>
</span>

Then modify them before serving:

# inside controller
def display_user(doc)
  user = User.find( params[:user_id] ) 
  (doc/".tel .value").inner_html = user.phone_number
  return doc.to_html
end 

And because it is an in-memory tree instead of some opaque String, you can do everything programatically around the document: looping, if-else, removing nodes, replacing sub menus, partials? Furthermore, when you need to do dynamic behaviors on the client-side, the programming paradigm is exactly the same!

Designers can be happy churning out the HTML/CSS in whatever tool they like (be it Dreamweaver or notepad.exe), and developers just poke their DOM.

What say you?

PS: Oh well, I guess what I'm trying to say is maybe we should not waste time finding better ways of constructing webpages (i.e. templating systems) when we could approach the problem as "modifying a document" - which is much cleaner and (with the right API) much easier.