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

[Alex Martelli]

"The browser just can't hack it" may be true if you do have to care
intensely for a certain kind of demographics -- the "if IE6 was good
enough for my gramps it's good enough for me" folks (some
ridiculously-late-adopters, some trapped in Dilbertian enterprises
where IT's key role is denying services and making every employee
miserable).

If your main audience is folks smart enough to use Chrome, FF 3.5,
Safari 4, etc, or even I suspect IE8 (have not benchmarked the latter
myself), the argument loses validity.

"The database is the bottleneck": maybe, if you're stuck in the
slowsand of relational DBs (especially inferior ones, and/or with the
"Vietnam of CS", ORMs, rather than well-tuned and hand-optimized SQL
on a serious engine, such as PostgreSQL, Oracle, MS Server, IBM DB2,
..., with a real DBA, not a programmer-making-believe-they're-a-DBA,
overseeing it). Much as I love relational, I suspect (and wish it
wasn't so, believe me) that the future of scalability is with
key/value stores such as Google's bigtable, CouchDB, etc, etc. AND
those are especially suited to dirt-simple, cruddy operations --
definitely NOT the place to site any business logic (beyond "as
minimal as you can get away with" indispensable data integrity checks
to avoid DB pollution).

Modern browsers (including any with Gears on them;-) let you store
data locally -- so your DB load should also get lighter that way (you
probably do eventually want a central copy of lots of stuff, as a
backup and to enable users to switch browsers and computers with ease,
but that can mostly happen asynchronously, if and when feasible, on a
best-effort basis)... as long as you do have as much as feasible of
the logic _close to the data_. If you insist on keeping most all logic
centralized, if you're deliberately choosing an inferior architecture
to support IE6 folks, you're doing so at the detriment of the smart
users to which you could offer a vastly superior UX. And remember,
with frameworks such as Dojo or jQuery, you won't be completely
cutting off the dinosaurs -- the site or app will just be slow and
clunky for them (and if they're on IE6, they're _used_ to slow and
clunky anyway;-).


Alex


On Fri, Aug 21, 2009 at 3:54 PM, Shannon -jj Behrens<jjinux at gmail.com> wrote:
> 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/
>