[Sigia-l] The future of WWW...

[Michal Migurski]

I was going to send this off-list, but what-the-heck.

> HTTP is not extendable to RIA's the advantage of RIAs is that it by
> passes the asynchronous flaws of get/post of HTTP. RIAs can be
> synchronous which is one of the best things about them.

This is a good point - there are ways around this limitation in HTTP,
including Flash's support for XML sockets, or using cookies to maintain
state. But it is definitely a bright red line that contains what HTTP can
be expected to do.

> > I'd say that simplicity is HTML's great virtue.
>
> But why hold onto a technology just to be simple. Why not just do simple
> things w/ a more complex language. Just b/c I can do something complex
> w/ C# doesn't mean I can't as well make a simple desktop calculator
> either.

Because I think simplicity is one of the web's major survival
characteristics - it's easy to learn, there are thousands of
implementations out there, and you don't need much background to get
started. C# is your basic platform lock-in situation, and it's a whole lot
more difficult to debug.

I realize that I'm arguing for the legions of terrible programmers out
there, but having a simple education and implementation vector for people
with great ideas and too little time to learn C# or Java is valuable. Clay
Shirky wrote a great article not too long about situated software (the URL
is http://www.shirky.com/writings/situated_software.html though it seems
to be unreachable at the moment), in which he describes the ease of
developing simple database-backed web applications, and predicts that
tiny, purpose-built apps for limited audiences are a sort of new wave of
programming. None of this would be possible without a simple,
easy-to-approach development environment like the web.

Proprietary toolsets like Flash or complex ones like Java just can't beat
that, no matter how many OS-integrated bells & whistles they provide.

> This argument that HTML is simple is just not worth it b/c in
> the end you are talking about what to do w/ the technology not what the
> technology can do. I can be very simple and very usable in most
> technologies that have a GUI component to them. This is the point of
> DESIGN!

It's profoundly liberating to not have to worry about what a technology
can do. The protocol provides a baseline, innovation occurs at a higher
level.

> say putting the cart b4 the horse. Why have we so willingly accepted
> this bastard child of a technology? I just don't get what people are
> holding onto. The only issue I see w/ HTML is unparalleled ubiquity.

Don't sell ubiquity short! I do see a distinction between ubiquity of the
HTML variety, and ubiquity of the windows variety - the latter is vendor
lock-in, the former is the kind of lingua franca that allows real
communication to happen.

> The whole point of this thread this that MS and Flash are pulling out
> of the browser and the web w/ XAML and Central.

I don't believe that Central is going anywhere - it's a solution
desperately in search of a problem. I am pretty close to a lot of hardcore
flash developers, and I have yet to talk to anyone who can honestly think
of a reason to bother with it. Same goes for XAML- it's a warning shot
across XUL's bow that is only taken seriously because it has the MS
marketing juggernaut standing behind it. No one's going to use either
technology anytime soon, except in the kind of corporate environments
where IT can require IE or Mozilla usage, as appropriate.

> My problem w/ XUL is that no one has done a "pet store" in it. If
> someone wants to make the pet store in such a way as to compete w/ the
> Flash/.NET versions that are out there I'd be compelled to consider it.

I see your point, though I think pet store is an unfortunate example.
Flash and Java both have a lot of momentum behind them, and a host of toys
and apps (Sodaplay, Secret Lives Of Numbers, etc.) that would only make
sense implemented in those technologies. They have a place, but I see
nothing in the pet store genre that actually requires more than HTML
currently offers.

> Well, for one it is integrated into the OS directly. Well, you can say
> that's MS for ya, but hey! that's MS for ya. They do that, that's why it
> is a monopoly after all. XAML and .NET can run directly from the OS
> (yes, security hell, but UX dream). When I work in an application, why
> would I open a web browser to do it? B/c of addressing? Bah humbug that
> is so 1999. Aren't we past that yet w/ networked apps? G-d I hope so.

I dunno. Personally, I like the limitations imposed by the web browser.
As a user, I like immediately being able to grok what's happening on my
screen, what kinds of behaviors I can expect from an interface, where the
potential for screwups lies. As a developer or designer, it's nice to have
a clear set of boundaries within which to work.

> The problem I'm trying to solve or at least describe is chaos.

I'm having a hard time thinking of a development medium less chaotic than
the web. Limited grammar, fairly tight restrictions on what's
technologically feasible, and still it has demonstrated potential for
extreme creativity.

---------------------------------------------------------------------
michal migurski- contact info and pgp key:
sf/ca            http://mike.teczno.com/contact.html