Re: Browser as Platform (was DesignBais - Impressive)


Luke Webber wrote:
dawn wrote:

[snip]
AJAX also holds the promise of letting us write UI's that give the user
the benefits of our character interfaces with its responsiveness plus
the ease of use, no training necessary, of the 90's GUI's because of
the asynch services architecture. It isn't yet _easy_ to write
really-satisfying applications that run in a browser, but the
popularity is going to explode, not go away any time soon.

Of course I could be wrong. But you wouldn't believe how much effort
it was to convince my colleagues that the internet was going to be huge
after I saw Cello, followed by lynx and Mosaic. I did a talk in 1993
about database-backed web sites (using Mosaic, predating both Netscape
and IE). I'm doing AJAX talks now. My track record might have a
little dent in it by picking Java, which might be hugely successful but
is still not easy for software development IMO. So, time will tell.

I think that the biggest obstacle to the success of the "browser as
platform" model is Microsoft Impotent Exploder.

Currently IE is a significant obstacle, but it was also a big boon. It
is the ActiveX object along with JScript that is at the heart of AJAX,
even if in an ECMA standards sort of way as XMLHttpRequest and
ECMAScript (There are few places where Microsoft did something first,
so it seems worth noting.)

The biggest issue with IE is trying to support it and other browsers.
There are some companies who actually write software that works only
with IE. They do not experience quite as many issues as most web
developers do. It would likely be easier to support only FF, but I
think that the biggest issue is that we are developing software
deployed to multiple vendors' run-time environments (browsers). That
necessarily has complexities and there will always be differences to
accomodate, sometimes painfully.

It takes simply forever
for new features to be adopted,

I don't mind stability, but sure would like bug fixes.

and many highly useful features just
never make it in there at all. Hence the endless, tortured stylesheets,
made more and more complex just to support simple features in a
cross-browser way.

Yes -- this was quite a learning experience for me. I have even told
folks that learning to do xhtml without tables for layout, with css,
with cross-browser support, might be the most challenging "coding" that
I have done in my career. It was at least among the most frustrating.

Like tying to place a <div> at the bottom of the
screen - dead easy using standard CSS, but insanely difficult (and
incompatible) in IE. Phooey!

It's this sort of obstructionism and foot-dragging that is going to kill
off the BAP model, IMO.

I don't think so. We are still in the early part of the bell curve
with this approach to software development. The current problems are
sure to improve (while others will no doubt find their way in).

While I do think that there could be Flash and other plug-in products
that arise that might do one thing or another better, I feel pretty
confident about the xhtml, javascript, css, browser as run-time
container strategy for the future. There are many challenges, such as
security issue and the variety of options, none great it seems, for
storing state on the client -- will sessions be managed on the client,
for example. (If someone really likes their approach for saving state
on the client, let me know -- I have not done enough experimenting in
this area yet).

I have more questions about the services used by the browser-based app
(by way of asynch calls to URLs that access data, for example) -- the
middle and back tiers. I'm in an uncomfortable
I-have-no-preferred-server-side-language state right now, since I am
trying to work without a Java app-server, like tomcat, on the server.
I still dislike PHP, but it seems the only one convenient for all web
developers.

Cheers! --dawn

.