AJAX - Markets Abhor a Vacuum

If you have only recently heard of greatness of AJAX, then you have not been paying attention for the last 5 years. Not that there's anything wrong with that. Lot's of people are quite excited by the new hype over HTML + JavaScript (+ XML + SVG), myself included. The reason for this post? Just to put down in words some of my reactions to things I've seen written in regard to the new hype.

CNET has an article discussing the renaissance and how AJAX may be used in the future, leading to a possible destruction of desktop applications. I love the media. Anyway, Charles Fitzgerald of Microsoft is quoted:

"It's a little depressing that developers are just now wrapping their heads around these things we shipped in the late 20th century,"

I can agree with that. None of this stuff is brand new. In the same article, David Mendels of Macromedia is quoted:

"It is really, really, really hard to build something like Gmail and Google Maps,"

"Google hired rocket scientists--they hired Adam Bosworth, who invented DHTML when he was at Microsoft. Most companies can't go and repeat what Google has done."

I think this is total crap. The article ends with a quote from David Temkin of Laszlo:

"The successors to Word and Excel and Powerpoint are not going to be written this way. It's just not going to happen."

This seems like a strange thing for a rich Internet application framework vendor like Laszlo to say. Even assuming that David was not quoted out of context, the statement is wrong.

Software products are mainly driven by markets. Users in those markets have needs and software is created to meet those needs. If your company makes a desktop OS, you'll probably make software that runs on the OS. At least until the users' needs change and the market forces you to re-evaluate how you build your software. How quickly you change the way you build your software depends on many factors, including the strength of the market forces and the cost of rewriting your existing codebase.

By the way, writing any kind of software application can be really, really, really hard. There is a difference between building a web-site and writing a web-application. And yes, I do have an aerospace engineering degree. Desktop or web, it's still hard.

My point is that if there was enough of a user need for presentation software that could be run from anywhere, the next version of PowerPoint would be built using an AJAX-like framework. It probably would not be Microsoft that builds it. They have an existing codebase that makes it costly to do such a thing. If PowerPoint was a product of the MSN division, things might be different. IMO, that group is doing some of the best new work at Microsoft.

John Gossman has a couple posts that also stirred me up. In general, John is definitely worth reading. He agrees with Temkin that Office will not be rewritten using AJAX, but attributes some of that to browser limitations. Many of those limitations are gone, including the advanced graphics issue he brings up. SVG and VML (in IE) do some pretty cool things. More than enough to drive a decent PowerPoint/Excel replacement.

Robert Scoble brings up offline usage in a recent post. Again, this limitation can be overcome. Since IE 5, web applications could use the userData behavior to store data locally. Together with client-side XML/XSLT, its pretty effective. I am sure Mozilla/Firefox has something similar.

The replacement does not need to have all the features of the desktop version. Successful web-based applications (like email, bug-tracking, ERP systems, RSS aggregators and blogging tools) have shown that users are willing to give up some of the "niceties" of a desktop version for the benefits of web-based deployment.

Markets (and users) abhor vacuums. If a web-based PowerPoint vacuum exists, some software vendor will fill it.

XML vs Serialization

In this XML vs Serialization post, the author lists reasons why XML is not a good serialization format. I would turn the list around and say those are the exact reasons why XML is a good way to develop a serialization format. Even if its just an XML dump of your object model (I think we could do better than that), it's still better than a binary dump. If my object model changes, and it surely will, I can always transform the older XML dump to the newer structure. Even if its by a hand-written script. You can't easily do that with binary.

Also, I don't believe serialization implies the object model is more important than the data. I prefer to think it means the object model holds the data.

Via mnot

Object/Relational Mapping - No Thanks

I have already posted some of my current feelings on using object hierarchies to hold state. It should come as no surprise then, that I am also questioning value of object-to-relational mapping systems. Why in the world would I want some system to create a multitude of objects just so I could manage state (not behavior) using those objects.

I still end up with a brittle object model that is difficult to navigate and breaks when my state changes and exposes the rest of my code to that breakage. SQL and XML both provide simple ways to query and navigate using loosely coupled techniques.

Fewer objects, not more. It does not matter if they are auto-generated or not. I still have to use them in my code.

Holding State as Objects is Painful

As a developer, I write code. Code is good. I like code. But the people who use the applications I write could care less about the precious code. They care about.. wait for it... the data. Shocking, isn't it. I could have written the most elegant, wonderful code possible, but if I can't move their SuperApp version 1 files to SuperApp version 2, it's worthless.

Coding usually involves either holding state or executing behavior on the state. Holding state as an object hierarchy is really painful. First, someone has to write all those damn classes that map to the state. Then, changes to the state structure break the object model and any code using the object model. Besides brittleness, object models are a pain to walk (or navigate) and difficult to query or filter. Developers usually have to write other framework objects to support parent/child object relationships. Persisting from an object model can also be a pain and increases the likelihood of problems when the state structure (and therefore object model, and therefore persistence format) changes.

I say it's time to let it go. Focus on the data. Protect it. Ensure it's stored in a way that's robust enough to handle future changes. Think about this: MS Word 97 can open an MS Word 2003 file. Somebody was thinking about the data.

Use code to execute behavior on the data. Separate code from data, just like we're told to separate UI from business logic. If you've been reading my stuff, it should come as no surprise that I favor separating code from data by using XML to hold state. It's a means to an end. XML supports the kind of structure my state needs. It also supports standard ways to quickly walk or query for a piece of data from my state.