This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: xslt on server-side vs. client-side
- From: Nate Austin <naustin at idsgrp dot com>
- To: "'xsl-list at lists dot mulberrytech dot com'" <xsl-list at lists dot mulberrytech dot com>
- Date: Fri, 16 Nov 2001 12:28:23 -0600
- Subject: Re: [xsl] xslt on server-side vs. client-side
- Reply-to: xsl-list at lists dot mulberrytech dot com
Jim-
> this is a sad thread, hehe
Yes.
>
> but i will say that clientside processing should actually increase
> electrical usage
>
> a) as the most power consumption on any electrical device
> occurs at startup
> b) more clients equal more starting up
> c) clients are usually turned on and off more then servers
This would be an issue only if the clients started up just to do the
transformation. This is very unlikely. :)
Let's bring in all (most) angles here.
- Server-side you could cache the transformation. This is only valid if the
xml data never (or rarely) changes.
- A server is a controlled environment. You know how much processing power
and RAM you have (as well as software - every client must have msxml3+ to do
client-side), so a very large transformation is probably safer here.
- The server is also centralized, so many high-processing transformations
will more likely bog down if server-side is used.
- Client-side almost definitely saves processing time (possibility of
avoiding multiple transformations), electricity (network traffic all
requires electricity all along the way), help desk headaches (less of a lag
on the client so less angry people calling up to demand that it get faster)
IF in addition to client-side transformation, there's smart use of
JavaScript(DOM, DHTML, etc.) to keep as much on the client as possible.
- Your point goes here (only $49.95!*)
Now that we have all of that laid out, we can reach our glorious
conclusion...
"Which one is better" depends on your circumstances! (pause for gasps)
-Nate
* - This value is in US Dollars. Other currencies will be accepted based on
the exchange rates at 12:25PM US Central Daylight Time, 11/16/2001.**
** - Date is in standard US (everyone but the whole world) MM/DD/YYYY
format.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list