[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Client-side XSLT. Re: Bad News on IE6 XML Support
I believe Paul Spencer wrote: > Why is this a disadvantage? We now round-trip to the server for every new > page and have to hold our instance data across pages. We can't validate on > the client, so this is done on the server. Many technologies have been devised to avoid round trips back to the server, such a DHTML, which is rarely used outside the firewall. DHTML is basically a highly successful Win32 GDI replacment instead of a widely used Internet technology. I'm talking about Microsoft's version, of course, because there still isn't a "conformant" implementation of DHTML (Netscape gave it a good try), just like there won't be a conformant version of XSLT, because the specs are too complicated for more than one vendor to agree on them. Need I say more about CSS. Simple and slow beats complex and fast. Every time. Now why is that. It's because software is hard to write. Even XML and SGML documents are hard to get right. There are more people who understand HTML compared to XSLT, and that will never change, no matter how many excellent books Mike Kay puts out. "But," you say, "a round trip is too expensive. There's network latency and all those hits can bring the sever to its knees." First of all, if network latency really is a problem, you probably didn't design your application properly. Or perhaps the Internet is not the right platform for your application. Because I use apps all the time that validate on the server and it works just fine. Back-end scalability is always a problem. But thanks to Moore's law, it will always be easier to add more hardware on the back-end then try to push code out to clients. Pushing code on clients is attractive ("it's their fault, not mine"), but in reality it's a nightmare. Java on the browser failed because not even Netscape could keep up with whatever it was Sun was up to in any given month. Disk, memory, and CPU is cheap nowadays and I mean for real businesses, not for hobbyists who don't need to build a highly scalable web application to display their family portraits. If you have money to spend, which is rare these days, hardware is mind-boggling cheap. Scaling up the back-end is really the only solution and XSLT and XML won't change that. Even in the example of data validation, you simply can't rely on the client to validate data for you. You have to put the validation logic on your server anyway. So maybe you put it in two places but once it's one on the server, which is where it has to be, you still have a scaling problem. So pushing code, whether it's a Java VM or an XSLT processor, on the client doesn't help you. It's a lot of trouble for little in return. It would be simply fabulous if Marc Andressen and friends had the foresight to put XML (with namespaces) and XSLT support into Mosaic. That would mean that we could send XML and XSLT down to the browser instead of highly redundant HTML, and therefore (theoretically at least) pages would display faster. It would also mean that Marc had a time machine. Those guys worked with what they had, and HTML proliferated like fire whether we XML lovers like it or not. Today, reliable XML support is virtually non-existent in installed browsers and it won't be there for years, and even then you'll be disappointed by the conformance to the latest and greatest XML and XSLT specs. You can say that's because of the evil and slow browser vendors who would like nothing more than to "lock in" content authors into proprietary technology. Or you can say it's because content authors don't know how to use XML and XSLT and are too lazy to learn. And I say exactly! That's the customer by a wide margin. It's questionable whether the world needs XML on the client. When I go to Amazon.com to buy something, I couldn't care less whether the browser uses whiz-bang technology like XML or dumb and slow technology like HTML. All I care about is that the price is right and Amazon can deliver. HTML works today, and it will work tomorrow. XML adds nothing to my shopping experience. It might make the back-end developer happy because he's using interesting technology, but dumb and slow HTML is keeping the other guys in business longer. And who knows? Maybe the back-end is fully XML enabled and merely emits HTML at the last minute. "But that's slow," you say. And I say, "add more hardware." If XSLT transformation is really the only cause of your application's poor performance, you should go have a beer because you did a darn good job! And as a developer who's struggling to keep his employer in business, I darn sure would rather use technology that works on 100% of browsers rather than less than 10%. The losers can spend their time writing diatribes against IE 6, IE 7, IE 8, ad infinitum. The winners will flow with the river. I commend those of you who are fighting Microsoft for the good of XML. Perhaps you'll win some day. You're fortunate in that you have lots of time to wait.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|