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

[Jeff Enderwick]

a few application-dependent things to consider:
- security: what can be left on the endpoint, and how can
browser-resident code be trusted?
- support & test: can you debug your app when things are going wrong
at the endpoint, and what is the test impact for N browsers?
- "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.

$.02

On Tue, Aug 25, 2009 at 11:20 AM, Alex Martelli<aleax at google.com> wrote:
> "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/
>>
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>