[Baypiggies] off topic: JavaScript: DOM vs. innerHTML, Server-driven vs. Client-driven

[Keith Dart]

=== On Tue, 08/25, Jeff Enderwick wrote: ===
> a few application-dependent things to consider:
> - security: what can be left on the endpoint, and how can
> browser-resident code be trusted?

The framework that I had mentioned previously does take security into
consideration. It allows you to serve subtrees of the URL path from
different FCGI servers, each running as a different process with
possibly different user accounts and privileges. 

Browser code cannot be trusted, of course. But it is mostly the UI
code. That also enhances security since you are running less code on
the server side. The server just has to validate the JSON-serialized
data. 

> - support & test: can you debug your app when things are going wrong
> at the endpoint, and what is the test impact for N browsers?

It's more robust since an occasional crash of the client code in the
browser affects one user, a server crash effects many users. That model
does require a lot of testing. Fortunately, modern browsers are finally
converging on more standardized technologies which makes support easier.


> - "The browser just can't hack it": when writing and debugging JS, it
> is not unusual for me to see FF or Safari lockup or crash 5-10 times
> in a day. Yeah, I'm makin' bugs, but the browser is not likely as
> robust an execution environment as that which you're using on the
> server.

Again, better to have the client crash than the server, anyway. Pushing
more functionality out to the client also scales better. 

This is one major reason that Google developed Chrome, it is a faster,
more rubust browser for exactly these types of applications.



-- Keith Dart

-- 
-- --------------------
Keith Dart
<keith at dartworks.biz>
=======================