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

[Alex Martelli]

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
>