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

[Alex Martelli]

On Fri, Aug 21, 2009 at 1:37 AM, 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

Dojo is particularly good at offering a transparent way to use
whatever resources are available for such things as local storage
(also similarly for graphics &c, I think, but I don't do much graphics
so I don't know for sure - also that doesn't matter to offline work;-)
-- whether it's some small browser-specific local store, HTML5, Gears,
whatever. (It can even fall back to the server as the last resort iff
no way at all is available locally -- all more or less transparently /
declaratively, without needing to contort your application level code
for the purpose).

Not sure if other frameworks have caught up to dojo on this
"transparency" issue by now, back when I researched this it was really
a killer feature for dojo from my POV;-).

> 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.

I guess "best looking" is a subjective call and I don't claim
expertise on "looks" -- dojox.grid,
http://www.dojotoolkit.org/book/dojo-book-0-9/docx-documentation-under-development/grid
, seems fine to me;-).

> 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.

I have my issues with code generation -- ORMs that generate SQL on my
behalf, GWT, Pyjamas, Visual Studio's long-standing GUI builders, etc.
They never make code as good as I'd write by hand, and they always add
limitations. And editing the generated code is a sure road to
disaster.

I like GUI builders (since I'm no good at graphic design anyway, the
looks they generate won't be worse than the ones I'd make by hand;-),
but I'd rather have them generate _data_ -- and then a simple engine
can paint the GUI based on the data -- the approach XCode and Qt
Builder take, on the desktop. I don't know if anything like that is in
the offing for any JS GUI/toolkit framework, though.


Alex