Distributed application architectures (was: [Q] In-Browser technology)

[Cameron Laird]

In article <1279557217-15543582 at hypernet.com>,
Gordon McMillan <gmcm at hypernet.com> wrote:
			.
			.
			.
> Despite all the hype, the only things you can do reasonably portably 
>in browsers (NS & IE) is vanilla JScript / JavaScript and vanilla 
>Java applets. Even there you will almost certainly have to detect 
Not that that's to be sneered at,
in general.  Vanilla JavaScript
and vanilla Java applets can do
more than most programmers will
touch in their whole lifetimes.
On the other hand, yes, there's a
LOT that they leave out.  'Depends
on what ones needs are--the maxim
Gordon and I invoke in all situa-
tions, anyway.
>which browser you're in, and code accordingly. You may even have to 
>detect which version of which browser. And things get even worse as 
>soon as you need to deal with the browser's security. And it's very 
>difficult to do anything useful without running up against a security 
>rule.
I confirm Gordon's melancholy
cautions.
>
> If you have long term relationships with your clients (so you can 
>ask them to install something) and if you only have to deal with a 
>limited (the smaller the better) number of browser / versions, you 
>can do some neat things. (But, as Cameron points out, why bother with 
>a 15 meg browser when they could just install an app - HTML forms are 
>easy to write, but don't make particularly good GUIs.)
It varies.  HTML forms are *perfect*
for some situations, and risibly in-
adequate for others.  The anti-anti-
... backlash against HTMLization has
now ascended to an uncountable height,
as near as I can tell.  My personal
bias is to assume vanilla Webification
is enough, and get customers to tell
me for what more they truly are willing
to pay.
>
> This whole noise about browsers-as-thin-clients <choke> was started 
>by the Java folks. Well, at this point, according to the same folks, 
>applets are "out" and server-side is "in". And they're right - Java 
>makes much more sense on the server than on the client. You can 
>blame it on the browsers, but the JVM spec pushes all the hard 
>work into the JVM implementation, so it should be no surprise that 
>the promise was hollow. 
Thin clients--ohboy.  I've been sketching
a whole essay I want to write on that
subject.  Whatever else we say, though,
it's really, really valuable to be able
to assume a Navigator or IE is sitting
"out there", on a client's desktop, pro-
foundly flawed though they are.
>
>On the server, Zope makes even more sense.
Isn't *that* the truth!  (That's Hoosier
for, "I agree with you heartily.")
>
> I found Juice very intriguing when I looked at around 5 yrs ago. 
>It's not encouraging that they're still using the same wire-frame 
>demo they used back then.
I appreciate your understatement.  No,
that is far from encouraging.
			.
			.
			.
-- 

Cameron Laird           http://starbase.neosoft.com/~claird/home.html
claird at NeoSoft.com      +1 281 996 8546 FAX