W3C home > Mailing lists > Public > www-html@w3.org > April 1998

RE: Client side : an economic perspective was: Re:...

From: David Norris <kg9ae@geocities.com>
Date: Mon, 13 Apr 1998 23:35:24 -0500
To: <www-html@w3.org>
Message-ID: <001001bd675e$be557420$46d628cf@kg9ae.dyn.ml.org>
I see many possibilities for using client side and server side programming.
What, I believe, will prove to be the best alternative is a balance of the
two.  There are tasks that cannot be performed well by the client and others
that cannot be performed well by the server.

ECMAScript is useful on the client side.  A specialized server language is
needed.  Well designed server languages do exist.  PHP (http://www.php.net/)
is a good example.  It is similar to PERL or C in construct, but,
specialized for web tasks.  The code embeds into a document, rather than the
code creating the document.  Combine this with ECMAScript and you have the
potential to create a balanced web application.

I don't think completely client or completely server will be as useful as a
combination of the two.  You are just shoving your problems on to others
when you go client side only.  Server side only would be an increased burden
on you.  So, balance is in order.

The overhead issue is important.  PHP, for example, has a nearly
undetectable CPU overhead on the server.  And, there need only be one copy
of code for millions to billions of users.  ECMAScript, however, requires
everyone to have an interpreter on their client.  Combine this with the fact
that every user must have a local copy of the code.  You are looking at the
possibility of Terabytes (ECMAScript interpreter and code combined) of
duplicated code over the entire network!  I think we need to be cautious in
using client scripting as an end-all solution.  It is very useful, but, you
have to take a serious look at the overhead on the network as a whole.  Not
focusing on one machine, but, all of them combined.  One machine's reduced
overhead can effect millions of other machine's ability to function on the
network.  Tying up bandwidth and storage space along the way.  CPU is not
really a very big deal on the client side anymore.  Bandwidth and storage
are the big issues.  Server CPU load can easily be controlled with an
efficient language and interpreter.

,David Norris

World Wide Web - http://www.geocities.com/CapeCanaveral/Lab/1652/
Illusionary Web - http://illusionary.dyn.ml.org/ <-- 02:00 - 10:00 GMT
Video/Audio Phone - callto:illusionary.dyn.ml.org
Page via mail - 412039@pager.mirabilis.com
ICQ Universal Internet Number - 412039
E-Mail - kg9ae@geocities.com
Received on Tuesday, 14 April 1998 00:35:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:15:36 GMT