Related link: http://www.simonstl.com/articles/xbrowse/xbrowse13.html
I was talking with George Feil the other day and he said something I thought was very interesting.
“You know,” he said, “when you’re dealing with Enterprise Apps, there’s no reason to generate HTML on the server. You should generate XML, and then use XSLT or CSS in the browser, right? Surely browsers are close enough to standards, anbd far enough along that, at this point, if you insist on a recent browser, it should work.”
“Huh?” I thought. “That might be true. It’s certainly not something I’ve thought about recently.”
From an architectural perspective, it’s interesting. In the Java universe, there have been a lot of new UI frameworks, like Tapestry which look very nice. But which, at the end of the day, are more about better ways to generate HTML and to design server-side apps, than they are about ways to generate XML.
And there’s been a lot of work done on richer client interfaces. From Flash to Avalon to General Interface and all points between, a lot of people have been noticing that the client machines are incredibly fast and trying to figure out what to do with all that memory and all those CPUs.
George’s point is an elegant one. Suppose instead of using those client CPUs to deliver enhanced functionality, you simply wanted to offload some of the server’s workload. Could you use XML to do that? Stay in XML and stay closer to logical layout on the server, and then generate the HTML in the client browser.
So here’s the data points:
Are people doing this? Am I missing something big or obvious?