[ale] OT: Google releases new OS browser - CHROME

[Michael B. Trausch]

On Thu, Sep 04, 2008 at 12:48:50PM -0400, Mike Harrison wrote:
> > It's about time JavaScript interpreters become more reasonably speedy.
> 
> It's about time web programmers learn to do more with less JavaScript.
> I see JavaScript junkies do things all the time that should be done
> on the server in .shtml/.php/.asp/.pl/..
> 

In some cases, sure.  But every little thing that you can push to the
client-side that will save the server some work, probably ought to be
done on the client side.  The server should verify things, to be sure,
but that doesn't mean that it should be doing certain things for
_everyone_.  Why have the server generating UUIDs for new database
entries, for example, when the client can do it just fine?  It takes
0.0041 seconds to generate a UUID using a command-line utility.  It is
approximately the same from an interpreted language like PHP that has to
make several library calls to accomplish that task, if not a little
longer.

If you have 200,000 new objects in a database being created daily,
that's 820 seconds of time a day, generating UUIDs.  You can offset that
to another machine by pushing the generation around a bit, but why not
do so?  If it saves 820 seconds of time on the server, that's more work
that can be done.  Likewise, if the client can do a little bit of
preprocessing on the data, that saves the server time, too.  If you do
it right, you can have a verification routine on the server-side that
runs very quickly (far more quickly than actually doing the processing
server-side) and shuttle the data to storage.

While "rich" applications are (mostly) about the user interface
experience, and defining API entry-points on the server for the rich
client to interface with and lower the turnaround time for requests by
making them smaller, there's a very large upside to the client/server
programming model being brought to the Web in the way that modern
JavaScript makes possible.

It's worlds better than doing client/server processing the old way, I
think, wherein every client application was a compiled program running
without a sandbox on each client system... at least with JavaScript
clients, you're running in a sandbox that is managed by the browser
process.  The faster client programming that is possible that way, I
think, the better.  While not all applications could or should be
written to be rich Web applications, zero-install apps via the Web
browser are a decent thing to be able to do (and do speedily).

   --- Mike

-- 
My sigfile ran away and is on hiatus.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mail.ale.org/pipermail/ale/attachments/20080904/9fa9f926/attachment.bin