[Javascript] server-side:client-side workload ratio

[Innerlab]

Interesting thread. I look forward to read more.
I am not an expert, so I don't think I can contribute much.


----- Original Message -----
From: "Paul Novitski" <paul at dandemutande.org>
To: "[JavaScript List]" <javascript at LaTech.edu>
Sent: Sunday, March 21, 2004 1:51 PM
Subject: [Javascript] server-side:client-side workload ratio


> Friends,
>
> As my client-side scripts become capable of performing more complex tasks,
> I'm left wondering how I should split the workload between my server-side
> scripts and my client-side scripts.  What fundamental characteristics of
> the page-rendering process naturally argue for placement above or
> below?  If you've given this some thought and have come up with some
> conclusions that work for you, please share them.
>
> (For this musing I'm considering "hand-crafted" scripts such as VBscript,
> PHP, and Javascript, bypassing the .Net programming environment that can
> handle most of the server/client side issues as one integrated process.)
>
> My initial inclination is to give server-side scripts most of the
> application-specific work and give client-side scripts more generic tasks
> that I can re-use more often, although I don't have a rigorous argument
for
> that yet.
>
> One area that seems clear concerns download time.  Especially in a era
when
> so many users are on slow connections, it would behoove us to minimize the
> size of downloaded pages without sacrificing the complexity of the user
> interface.
>
> Consider an application that reads a dataset and downloads it to the
> browser for display or editing.  The data need to be massaged before
> presentation in the browser: some fields made into hyperlinks, others
> reformatted, concatenated, or converted for user friendliness.
>
> Because it's the server-side script's responsibility to read the dataset
in
> the first place, I'm inclined to give it the job of initial reformatting:
> - selected the desired columns;
> - performing the initial record sort;
> - performing data conversions (enforcing date & time formats, replacing
> code values with human language words, concatenating fields, etc.);
>
> ... and give the client-side script the work that pertains to the details
> of the user interface:
> - assigning CSS classes & styles;
> - assigning GUI events & hyperlinks;
> - inserting the data grid in the page and organizing its structure, e.g.
> separating the field name row from the data rows to enable a scrolling
> dataset with fixed heads.
>
> For fast response time, I'm inclined to keep the size of the downloaded
> page small and add any necessary redundant bulk with the client-side
> script.  For instance, the server-side script could dictate the CSS
classes
> of each data column in a single row, and the client-side script could
> assign these to every data row in body onLoad(), resulting in a slim
> download and a fat result.
>
> The server-side script could generate Javascript such as:
>
> var aFieldNames = new Array("Date","Contact","Email");
> var aRowClasses = new Array("cssFldDate","cssFldContact","cssFldEmail");
> var aRowLinkTypes = new Array("","","mailto");
> var aDataset = new Array();
> aDataset[0] = new Array("03/01/2004","Jo Blo","joblo at thingie.com");
> aDataset[1] = new Array("03/04/2004","Sam Sham","samsham at froggie.org");
> ...
>
> Javascript could build the actual data grid structure (using table or
> layers) and assign classes, link structures, and mouse events to each cell
> of the dataset as it builds them, ultimately generating a structure much
> wordier than the essential information that's been downloaded.
>
> Any further thoughts anyone has on this topic would be appreciated.
>
> Paul
>
>
> _______________________________________________
> Javascript mailing list
> Javascript at LaTech.edu
> https://lists.LaTech.edu/mailman/listinfo/javascript
>