Re: Netscape Support for XSL - client vs server rant

[Dan Morrison <dman at es dot co dot nz>]

Heather Lindsay wrote:
> 
>         If it's not too much trouble could you elaborate on this speed
> penalty you speak of?  How much of a speed penalty is it?


To butt in before Matt gets a chance...

The difference between sending off a network request to a server vs
processing changes on the client is more than significant. It can make
or break the effectiveness of the user experience.

Without wishing to downplay the power of Cocoon et al, the dynamics that
are unleashed by sending the /data/ to an IE client, which can then be
manipulated by client-side scripting, is astounding.

In so many ways this is a better model of information transfer and
management. Send the data, send some instructions on how to display it
/and/ send instructions on other things you can do with it. 
Server-based solutions (servlets or not) always require the overhead of
the network transfer, and mean that at any time you are looking at only
a cooked interpretation of the information. It's not true EDI in my
book, it's just database-driven HTML, and the fact there's some XML
thrown in there behind the scenes has no perceivable advantage to the
user.

I'll go out on a limb here, and (to mix my metaphors) will probably be
shot down in flames, but it could be said that the concentration we see
on server-based solutions is not just making up for the dodgy support
currently available in client browsers, but actually reactionary against
the fact that the MS integrated model is actually a Good Thing [TM] and
some folk are loathe to admit it.
Yes they got 5% of the implimentation wrong, but the concept is correct.
This is why NS is playing catch-up with XML support. This is why I for
one am looking forward to the day they get there.
This is why in any of the online applications I design, I push as much
data down to the client as possible and minimise server dependancies.


As a developer I _like_ server-based solutions. I have control. I have
to worry less about browser sh*t. I can pull clever tricks in the
language of my choice. I can upgrade my platform whenver I need to to
take advantage of new features.

As a thinking person however, giving the client control is "morally"
better. And logistically correct. And, in sub-cable conditions, usually
much quicker, when done right.

One of the theories I understood (or misunderstood maybe) from the early
days of Java was that the language was to enable a move towards "thin
clients" which would send instructions, not results down the wire. To
use Java (servlets) to bolster the legacy position of mainframe-like
servers seems almost a betrayal of that ideal.

I imagine this will raise a few hackles, but I believe the attitude to
the client-server relationship is an important aspect of XML, XSL, and
the success of the movement as a whole.

</rant>

.dan.

:=====================:====================:
: Dan Morrison        : The Web Limited    :
:  http://here.is/dan :  http://web.co.nz  :
:  dman@es.co.nz      :  danm@web.co.nz    :
:  04 384 1472        :  04 495 8250       :
:  025 207 1140       :                    :
:.....................:....................:
: If ignorance is bliss, why aren't more people happy?
:.........................................:


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list