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

[Paul Carduner]

I'm really enjoying reading this discussion.  People are raising good
points for both sides and it seems like everyone agrees that client
side apps using new technologies like Google gears are highly
scalable, have a good user experience, and are generally really cool.
And if everyone is using the latest web browsers, reliability and
compatibility are less of an issue.

If you're a publicly traded web technology company, you should
probably be focusing your efforts on pushing the boundaries of rich
client side applications, and doing whatever it takes to get there,
including building new web browsers from scratch and developing Java
to JavaScript compilers.  But what about the small guys that don't
have a ton of money and man power to invest in changing the web
landscape?

>From a bang for the buck perspective does it make sense for small
startups to jump onto the RIA bandwagon?  Developing web apps in RoR
or Django with ORMs is a good way to get something that works out the
door quickly (learning time included).  Can someone convince me that
the same is true for a JavaScript framework like Dojo?  Are there any
good examples of client heavy applications out there that were built
quickly and cheaply?

On Tue, Aug 25, 2009 at 4:38 PM, <baypiggies-request at python.org> wrote:
> From: Jeff Enderwick <jeff.enderwick at gmail.com>
> To: Alex Martelli <aleax at google.com>
> Cc: Baypiggies <baypiggies at python.org>
> Subject: Re: [Baypiggies] off topic: JavaScript: DOM vs. innerHTML,
>        Server-driven vs. Client-driven
> Message-ID:
>        <bb6059c00908251523w183e1e8dx68d1bbb24ca7937d at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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/
>>>


-- 
Paul Carduner
http://www.carduner.net