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

[Shannon -jj Behrens]

On Thu, Aug 20, 2009 at 11:05 PM, Alex Martelli<aleax at google.com> wrote:
> I do suggest you get a broader range of opinions

I am.  A bunch of people read my blog, and I asked the SF Ruby mailing
list too :)

> -- baypiggies' a
> self-selected sample of rabid fans of Python, after all. So for
> example I'd expect strong support for dojo, by far the most Pythonic
> of the best-known Javascript frameworks (Alex Russell enthused about
> it when I went to have my copy of "Dojo, the definitive guide" signed
> by him -- he's a Python in a Nutshell fan and very deliberately took
> dojo design principles as his guideline, wherever feasible, to design
> Dojo. So: modular, explicit, no altering builtins, no black magic
> behind the scenes, etc, etc.
>
> Ask Ruby people, PHP people, etc, etc, and you'll get samples with
> different biases; jQuery will be very popular, I suspect. Ask
> self-selected early adopters of not (yet?) very popular technology,
> and you'll get the Ext guys, the mochikit ones, the mootools ones,
> etc, etc. Ask a Cobol crowd, they'll probably say Prototype;-).

So far the consensus is 75% for jQuery and 25% for YUI.  Three of the
UIs I like the best are written in YUI, which is a strong testament.

> Now to the core issue, this is one argument  I made (improvised, but
> the more I think about it the more it looks like my off-the-cuff
> intuition was sound this time) at OSCON's "open source web languages"
> panel... which had nobody defending Javascript (Python, Ruby, PHP,
> Java and Perl were the 5 "debaters"), so I took that mantle on myself
> (double-timing Python;-).
>
> Everybody dreams of Scalability... the dream problem to have: millions
> are hitting your website, how are you going to cope?
>
> Well if all of your processing was in Javascript on the user's
> browser, scalability would be automatic, wouldn't it? A million hits
> give you a million PCs in which (through the browser) your web app is
> running; two million hits, you get 2 million PCs; and so forth. Poof
> -- scalability's a given now.

The problem is, unless you're writing a Web app that doesn't store any
data, you still have to talk to a central server--the DB is still the
bottleneck.  A lot of JS people are complaining that by putting too
much responsibility on the browser, the browser can't keep up.  The
browser was falling over when Freebase took this approach.  I can
always buy more servers, but I can't do anything if the user's machine
is overloaded.  This, apparently, is a big problem with animations
these days.

> You can't get 100%, but clearly the closer you get the better off you
> are. So, anything that CAN sensibly be done in JS in users' browsers,
> SHOULD be done there! The less you have to keep running on your
> server, the better.
>
> So, making your server a REST / CRUD webservice (or something close to
> that but with a bit less hypertext navigation and a bit more URIs
> being put together client-side, actually;-), and putting all logic on
> the client (in JS + Dojo) save what's needed to guarantee data
> integrity server-side (as clients could turn malicious!-), is the
> right general approach to the architecture.

I 100% agree with you in theory, and 85% disagree with you in practice
based on the experience of everyone I keep talking to about that
approach.  Browsers just aren't as awesome as we'd like them to be.

> BTW, don't bother serving dojo itself (or jquery etc) -- use Google's
> URLs for the JS framework you use (or AOL's, whatever!-).

Agreed.

> Yeah, that
> limits you to reasonably popular frameworks, but, like the syllable
> and scansion limits in haikus or sonnets, that's GOOD for you!-).

Agreed.

> You
> save bandwidth &c that's giving you zero added value: great ROI!-)

Best of all, that stuff is probably already cached in the user's browser.

> So that's one argument for "thin server architecture" (TSA: except
> that some heretics consider that implies XML payloads, while I think
> that anybody not using JSON payloads ought to get their heads
> examined, but that's a different jihad!!!-).

Couldn't agree more.  When XML first became popular (aka overhyped), I
kept saying, "Yeah, but I can do the same thing with Python data
structures", which as you know is almost exactly the same as JSON.

> There are others, and
> you've heard most of them, JJ.
>
> The incredible huge payoff of "thin server" comes when suddenly the
> business side people spring up the need for a new client optimized for
> X (where X in (iPhone, Pre, Android, Nokia S60, Xbox, netbooks, wii,
> commodore 64, whatever!)) -- zero server-side rework, *ALL* the work
> to support a new and wondrous client is client-side, EXACTLY as logic
> dictates it SHOULD be.

That is a very good argument.

> Get THAT going with your Django, Rails, &c server-heavy views peppered
> with just enough Javascript to be dangerous, will you...;-)

I'm cool with building a RESTful service.  It's just that the
consensus on my blog has very strongly been that it's better to
generate most of your HTML on the server because the browser really
can't cope with extremely heavy usage of building the UI via DOM calls
or innerHTML calls.  My favorite example of a RIA is Gmail, and even
it is remarkably simple compared to something like YouTube :-/

Thanks for your comments, by the way :-D

-jj

--
In this life we cannot do great things. We can only do small things
with great love. -- Mother Teresa
http://jjinux.blogspot.com/