Google maps and the future of HTTP

By now you’ve probably seen Google Maps – I’m not sure when it debuted but I’ve seen multiple blog references in the past week or so. The service is certainly slicker than what I’ve seen on MapQuest or MapBlast, and I’m sure it will remain popular even after Google figures out how to monetize it. What really excites me about gmaps is not the map technology per se but how it’s delivered. I won’t go into the details here (jgwebber’s blog has a pretty good dissection) but it’s based on loading only the parts of the page that have changed. As Webber points out, the technique differs from Gmail’s mechanism, but the effect is the same. Instead of reloading the entire web page to perform an action, client-side logic retrieves data from the server and inserts it into the appropriate place in the page structure. This results in a much smoother user experience, not to mention reduced network traffic. This idea may not be original to Gmail but I don’t know of another mass-market app that uses it.
The approach isn’t without its drawbacks; it complicates the presentation layer and (potentially) introduces yet another stripe of browser-dependent code. But I think it’s a step in the right direction for web apps, especially those that deal with lots of complex relationships in persistent objects. I’m eager to apply the concept to a project so I can get more comfortable with the design implications.