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:
- It wasn’t true, back in 2000.
- There’s some evidence that it’s true now.
Are people doing this? Am I missing something big or obvious?
yes and no
I've thought about doing it, even built a small pilot back in 2001 in an empty moment between projects.
While you do decrease the workload of the application server you increase network traffic as the amount of data transferred goes up (the XSL has to be sent every time together with the XML) and XSL processing was slow.
Performance was a lot higher (10-100 times depending on the XSL and network performance) performing the transformation on the server and caching the compiled XSL for reuse on future requests.
By now XSL precompilers have gotten faster so the difference may be less, might be worth giving it another go maybe but the serverside code is working well and consumes few resources so why bother?
sure they do
isn't that exactly what blogger does when you look directly at an Atom feed? http://adriancuthbert.blogspot.com/atom.xml
sure they do (with a link)
http://adriancuthbert.blogspot.com/atom.xml
XSLT, and (s)XBL too!
William,
I agree that XML+XSLT+CSS is an interesting combination to be sent to the client today. Apart from transferring documents with hopefully the best semantics available, the XML grammar often being custom specified for a given document type, this solution can also save on bandwidth usage, as the raw XML will most likely result in a smaller document than the post-processed XHTML, the XSLT (and CSS) probably being cached.
Another solution that sounds incredibly appealing to me is the delivery of XML with information on how to bind this XML with a rendering expressed in host grammar(s). For instance, you could send arbitrary XML with some sXBL specifying how your simple XML-based representation of a complex UI widget gets translated to a rich SVG rendering that can handle all the interactivity on the client with no required help from server. XSLT isn't really fit at dealing with mutations of the original XML and maintaining the representation of that XML in sync. sXBL is a great solution for writing XML-based UI, you should check it out too.
Antoine Quint
XML + XSL
I'm in the process of converting a web site that has ~2000 pages from just HTML to XML+XSL. It's quite a chore. I'm writing a program to do the converting. Coming up with the correct schema and then extracting out the data from the original files is not that easy, especially if not all of the files are conforming to what you think is the right schema.
BTW, the site is www.encyclopaedia-wot.org.
Dying on the vine.
Offloading some of the workload of the server is basically never important enough to learn how to use XSLT. I think a programmer's time is better spent getting to know what you can do with the rich client stuff on the browser - specifically, Flash.
It is easy to kill the client
In one app - the XML and XSL were less than 10K - however, after all the bells and whistles - the HTML was over 2Mb - Just the transform was enough to kill any reasonable response times. And this was just a "simple" spreadsheet interface with dropdowns etc. We did clean up and whittle down the interface.
One could argue that downloading a MB for a page was a bad idea anyways - however, the point is that need to apply standard discretion when choosing to do the transforms on the client.