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

[David Lovering]

Typically, those scripts which access things resident on the server (like
database information, files in shared distribution libraries, etc.) are done
with server-side scripting -- even when (by some highly questionable and
tortuous methods) client-side Javascript could be finagled into doing the
same thing.  Remember -- anything on a client machine must and should be
regarded as suspect, tampered with, eavesdropped upon, and generally nasty.
Piping it directly into the server application without vetting it first is
not a recommended process.

Also, it is important to split the validation process so that everything
which MUST be validated on a form submission is done on the server-side.
This is done in the instance that the client has disabled Javascript on the
browser, either accidently or deliberately.

My litmus test is that any or all information which may still yet be edited
by the user PRIOR to submission is handled by client-side scripting, and
anything else is handled by server-side scripting -- including final
validation for fields.

At least that's my take on the subject.

-- Dave Lovering

----- Original Message ----- 
From: "Innerlab" <innerlab at hotmail.com>
To: "[JavaScript List]" <javascript at LaTech.edu>
Sent: Sunday, March 21, 2004 1:31 PM
Subject: Re: [Javascript] server-side:client-side workload ratio


> 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
> >
> _______________________________________________
> Javascript mailing list
> Javascript at LaTech.edu
> https://lists.LaTech.edu/mailman/listinfo/javascript
>
>