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

Fri Aug 21 16:44:18 CEST 2009

Of course, if you're considering Java and GWT, I'd suggest Python and  
Pyjamas (http://pyjs.org/) ;-)

On Fri, 21 Aug 2009 01:37:50 -0700, Bill Katz <billkatz at gmail.com> wrote:

> I agree with Alex's comment.  If you have sufficiently complex use
> cases, it makes sense to build a rich javascript client-side "app"
> that communicates via JSON with well-defined server-side resources.
> First, you have the option of untethering it from the server using
> Google Gears, Adobe Air, or some other framework that makes your
> browser-based javascript act more like a local application.  This
> could be a big win for users on planes, deadspots, etc.  Second, you
> can handle server-side timeouts and other issues more robustly from a
> user perspective.
>
> If you do go the rich client-side app approach, there are a number of
> frameworks that specialize in building apps compared to just
> sprinkling AJAX into HTML.  I think Extjs has the best looking
> widgets, especially their grids, and that's what I'm using for my
> stuff.  There are Template classes that let you manipulate DOM in a
> more elegant way than just writing strings to innerHTML.
>
> GWT looks really solid, if you're OK with coding Java for the most
> part, and you can drop down to javascript when necessary.  The Google
> Wave client shows how sharp programmers can make GWT really shine.
> Cappuccino (http://cappuccino.org/) is an interesting framework that's
> like Cocoa for browsers but uses Objective-J.  In the near future,
> both Extjs and Cappuccino will release very slick GUI builders that
> generate code.
>
> -Bill
>
> 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 -- 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;-).
>>
>> 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.
>>
>> 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.
>>
>> BTW, don't bother serving dojo itself (or jquery etc) -- use Google's
>> URLs for the JS framework you use (or AOL's, whatever!-). Yeah, that
>> limits you to reasonably popular frameworks, but, like the syllable
>> and scansion limits in haikus or sonnets, that's GOOD for you!-). You
>> save bandwidth &c that's giving you zero added value: great ROI!-)
>>
>> 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!!!-). 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.
>>
>> Get THAT going with your Django, Rails, &c server-heavy views peppered
>> with just enough Javascript to be dangerous, will you...;-)
>>
>>
>> Alex
>>
>>
>> On Thu, Aug 20, 2009 at 9:59 PM, Shannon -jj Behrens<jjinux at gmail.com>  
>> wrote:
>>> I've written a blog post here:
>>> http://jjinux.blogspot.com/2009/08/javascript-dom-vs-innerhtml-server.html.
>>>  The first paragraph is below:
>>>
>>> "What's the best approach to architecting JavaScript, and which
>>> frameworks best support that approach? Is it best to build the app
>>> mostly on the client like Gmail and Google Maps, or is it better to
>>> provide a normal HTML page, but with lots of Ajax mixed in like
>>> YouTube? Which approach leads to the fewest bugs when the client and
>>> server get out of sync? How does your server respond to Ajax requests?
>>> Does it serve up JavaScript code to run, JSON or XML data to digest,
>>> or pre-rendered HTML?"
>>>
>>> I know this is a bit off topic, but it's a crucial decision I'm making
>>> right now for my app.  I've talked to some of you about it before.
>>> I'm completely fascinated by this subject.  If you are too, read the
>>> rest of the post above and leave a comment :)
>>>
>>> Happy Hacking!
>>> -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
>>>
>> _______________________________________________
>> Baypiggies mailing list
>> Baypiggies at python.org
>> To change your subscription options or unsubscribe:
>> http://mail.python.org/mailman/listinfo/baypiggies
>>
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies


-- 
Rami Chowdhury
"Never attribute to malice that which can be attributed to stupidity" --  
Hanlon's Razor
408-597-7068 (US) / 07875-841-046 (UK) / 0189-245544 (BD)