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

[Bill Katz]

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
>