Re: Client-side XSLT. Re: Bad News on IE6 XML Support

[XML Everywhere <host@xmleverywhere.com>]

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.