rami.chowdhury at gmail.com
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
> 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
> 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
> 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.
> 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
>> 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"
>> 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?
>> 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
>> On Thu, Aug 20, 2009 at 9:59 PM, Shannon -jj Behrens<jjinux at gmail.com>
>>> I've written a blog post here:
>>> The first paragraph is below:
>>> 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?
>>> 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!
>>> In this life we cannot do great things. We can only do small things
>>> with great love. -- Mother Teresa
>>> Baypiggies mailing list
>>> Baypiggies at python.org
>>> To change your subscription options or unsubscribe:
>> Baypiggies mailing list
>> Baypiggies at python.org
>> To change your subscription options or unsubscribe:
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
"Never attribute to malice that which can be attributed to stupidity" --
408-597-7068 (US) / 07875-841-046 (UK) / 0189-245544 (BD)
More information about the Baypiggies