Are Rich Clients Taking Off or Tanking?
Edited by chromatic
November 2002
In the late 1990s, Netscape had an idea. Instead of writing applications for a particular operating system, write them to a Web browser. Given ubiquitous Internet availability and the presence of a known reliable middleware platform, people could work whenever and wherever they had a Web browser.
History reveals that the plan didn't quite work, as incompatibilities, monopolies, and other intangibles interfered. However, the idea never went away. The W3C eventually standardized a set of technologies that made dynamic HTML possible. Mozilla finally released an amazingly powerful and mutable browser suite. A few client-side plug-ins evolved into quick and easy UI components from annoying toys.
What follows is an email discussion between some of O'Reilly's editors.
From Simon St. Laurent:
I have to admit that I'm worried about the web client space and what looks
to me like its ongoing fragmentation. As complicated and annoying as the
browser wars were, there was excitement in that space and continuous
change. Right now, I see both stagnation (XHTML 2 is FINALLY making some
useful changes after years of nothing) and fragmentation ('rich clients' in
.NET, Java, Flash MX, etc. while the browser is de-emphasized.)
Much as I hate to say it, the Web seems to be in decline right now, damaged
by too much ambition (and long delays) at the W3C, too little genuine
interest at Microsoft or Netscape/AOL/whoever, and a lot of programmers who
can grasp RPC easily enough but have little interest in working on a
machine-readable Web.
So far as I can tell, Microsoft's dispersed the IE team(s) and withdrawn
from participation on a lot of W3C activities, focusing only on the bits it
wants for other projects. Mozilla may yet prove useful, and I've heard
Opera's in the midst of a major architectural renovation.
From Tim O'Reilly:
This is interesting news, Simon. I hadn't heard bits of it. On the other
hand, I see the fragmentation perhaps leading to a new renaissance. Things
I find *very* interesting:
* You can make really nice UIs in Flash. I'm very taken with the whole
"Rich Internet Application" story. I'm not sure it's easy enough yet to
develop for, but it's sure as heck a pleasure to use a site that is
designed for single screen operation with regional updates, rather than
constant page refresh for every new step. Is this "the web" as we knew it?
No. But is it interesting, and will it lead to new opportunities? Yes.
* I'm also interested to see, in Watson and Sherlock on OS X, the idea of
specialized UI apps that are really oriented at the *data* from web sites
(i.e. Web services) rather than the document/page model. Again, I see this
as the early sign of some rich innovation.
* I also think it's great that we're getting beyond the "everything looks
like a nail" stage in which every net application is a browser application.
Napster broke the mold. Now lots of people are doing it. Fragmentation,
yes. But the bigger picture is that network programming is entering the
next phase. P2P is over as a buzzword, but there's lots of that happening.
It was amazing to be able to sit in the audience at Mac OS X Con, pop up
iChat, and see, via Rendezvous, all the other folks in the audience, and,
if I wanted, to chat with any of them.
The whole digital hub thing is happening. Digital Photography is pushing
personal web publishing again. Weblogs. Massively Multiplayer Gaming. In
short, there are oodles of interesting opportunities.
This is like the web in 1992, when we published the Whole Internet User's
Guide, and there were only 200 web sites.
The web is dead. Long live the web, or at least the impulse behind the
web, which was to take advantage of the network to share information.
Nat Torkington replied to the "Rich Internet Application" quote:
It seems like a profoundly retrograde step to me.
Simon agreed:
It feels profoundly retrograde to me as well. I'd hoped to see better
approaches for extensible browsers and information models rather than the
slow death of the browser combined with everyone building new apps.
Tim's response:
I'm curious to understand why DHTML is OK, but flash is "retrograde."
Flash runs in the browser, just like DHTML and JavaScript, and in fact,
ActionScript is just another form of ECMAscript. Have you guys looked very
hard at this, or are you just expressing bias?
And as to "everyone building new apps" -- that's a natural consequence of
the web services story, so that seems OK to me too. What are web services
for but to make it easier to make apps that don't use the browser? The
browser as universal client lead us to WAP (a dead end--let's just make a
smaller, more limited browser), where web services say, "let's assume that
the code to drive the browser is a kind of middleware; what kind of
middleware might we write if we were able to get directly at the data for
other purposes?"
In short, I see things like the Flash RIA vision *extending* the browser to
make it a more functional client, at the same time as web services (and
specialized web services clients like Sherlock and Watson on OS X) are
deconstructing the browser-server paradigm. But both are saying the same
thing: the browser was designed for text, not apps. CGI and its sequels
took us a certain distance, but not far enough. Let's go the rest of the
way to a general programming paradigm for distributed applications.
I don't think any of these things are the be-all and the end-all. In fact,
they are very clearly intermediate steps. But they are interesting steps,
and in a useful direction.
Bruce Epstein also replied to the "retrograde" comments:
I've asked Tim the same question frankly. I don't know enough about Java to
know the answer. Maybe Flash is just easier to use. I don't think it is
"retrograde" so much as Tim catching up with something that has been around
a long time. FWIW, Flash and Director can easily create desktop clients
that do NOT live in the browser. You've been able to build really
interesting desktop apps that access a back-end server in Director for,
like, 5 years. But this was at a time when all the money was going into the
Web.
From Tim:
Well, if you want to talk stuff that's been around a long time, the prior
art on dynamic, distributed objects actually goes back at least as far as
Viola, which Dale was championing in 1992 (and which has been used as prior
art in at least one patent case involving Microsoft as a defendant.) [ The Viola homepage contains a detailed history of the first web browser. ] So
it's not a matter of "Tim catching up with something that has been around a
long time" so much as Tim seeing that something that has been around a long
time (and a long time interest at O'Reilly) is finally, *perhaps* going to
get a crack at the mainstream.
What excites me about RIA is that it represents a change in metaphor for
application development. Java applets and Flash animations were
fundamentally trivial. For whatever reason (security fears in the case of
Java, a focus on multimedia in the case of Flash), this type of technology
was never seen as the stuff of real business applications. But the Flash
RIA story is about functional, business-like front ends, with easy back end
connectivity. All the pieces of the puzzle seem to have arrived. [ The Broadmoor hotel's web site is a good example of RIA in action. ]
Flash has wide penetration, so flash interfaces are almost completely
portable, if a bit slow on first load over a dialup line. The back end
story is good too, with both .Net and Java (as well as Cold Fusion)
supported. It's not clear if this run at the richer front end will work,
but it has a better chance at it than anything I've seen in a long time, if
Flash can shake the preconceptions that it is a toy. (Macromedia has to
stop doing gratuitous animation in their demos. It completely hides the
real power.)
From Jonathan Gennick:
Let me say upfront that I don't follow Flash all that closely, but I am
aware of Macromedia's efforts to promote Flash for what Tim refers to as
"rich Internet applications".
What I find interesting about all this is that when Java first came out it
was touted as the holy-grail for rich Internet apps (that's what I recall).
Yet Java completely flopped at what it was originally designed to do. Now,
along comes Macromedia with Flash, and they've put all the pieces together
when no one was looking.
I should probably stop with the above, which is the main point I wanted to
make, but I'll add the following thoughts, which I've really not spent a
whole lot of time thinking about.
Who cares whether Flash is a de-jure "standard" or not? It certainly seems
to be a viable de-facto standard. (Imagine what a mess an ANSI-Flash would
be.) Flash works. It works on different platforms. It's lightweight enough
that it doesn't seem to bother anyone, and Macromedia has managed to get it
out there to huge numbers of people.
I watch what my kids do. The sites they go to are almost all Flash. My son
Jeff plays what I believe to be Flash games every day after school. He's
happy with it, which tells me that Flash works.
Is Flash a step backwards because you can't bookmark pages? Well, I admit
that I like bookmarking pages, but again, look at my kids. They are happy
with Flash. They are growing up with Flash. Neither one is ever going to
clamor to return to plain old HTML. If we're going to have interesting web
applications, and by "interesting" I mean engaging and interactive, and
responsive, we're going to need some sort of unified, client-side toolset
to work with. This business of using HTML, XHTML, DHTML, CSS, and all sorts
of other acronyms just won't work.
From Simon:
Are your kids actually using Flash to create applications, or are they just
consumers?
From a strictly consumer point of view, I don't think most people care at
all about what technology provides their Web experience. Whether or not
Flash is part of the browser is not something that would likely occur to my
mother to ask, unless she encountered a situation where that separation
mattered (an upgrade, incompatibility, etc.)
From a developer's perspective, though, there are a lot of different
issues. I tend to divide them into short-term and long-term, as different
technologies have different advantages.
In the short term, ease of development matters, especially for Web-based
tools where lots of people still expect things to get done in "Internet
time," whatever that was. Quick development cycles (typically aided by
GUIs) and consistent results are key features here, and Flash can certainly
provide those. XHTML+CSS+ECMAScript+XML+XSLT may not do that as
consistently, thanks to browser variations and GUIs that tend to obscure as
much as they help.
In the longer term, ease of maintenance is a much more important set of
issues. Can generations of different development teams reuse the code
they've been handed while writing in additional updates? How tightly bound
are the data and the processes for working with that data? Can I collect
information from different sources or send it out to different places?
This was a Web application, but now we want to be able to access it from
cell phones, PDAs, and CB radios.
Those longer-term issues are a lot more difficult to address, and they
typically require a combination of technology capabilities and best
practices. Spaghetti DHTML isn't going to have any maintenance advantages
over spaghetti Flash, but a setup that uses XML as a foundation for XSLT
transformations into a variety of different target media, including
XHTML+CSS+ECMAScript (and possibly different versions of that) may well
have an advantage over the long term over an application that uses XML or
SOAP to communicate with a monolithic client.
There's a lot of interesting stuff going on, but I think we're a long way
from a shakeout that presents us with a single winner.
From Jonathan:
I went out and checked. The games my kids are playing are done as Java
applets. Flash seems to be part of the UI, but the actual games are Java.
Ok. Go ahead. Laugh. Obviously I can't tell my Java from my Flash. I saw
things moving on the screen and just assumed it was Flash.
My point below, however, isn't so much related to Flash as it is to the
whole rich Internet application thing. My son is used to highly interactive
sites like bonus.com (his favorite). He isn't interested at all in plain
old HTML sites. To capture people like him (and my daughter, and the kids I
see using the web at school), site designers are going to have to design
highly interactive (so called rich) web applications. In fact, the games my
kids play wouldn't be possible without some underlying rich Internet
application technology.
And I really don't think I'm going to say more, because this just isn't a
space I've been watching closely. I've probably blurted out enough
half-baked thoughts for one day.
From Bruce:
At 10:31 AM -0400 10/15/02, Simon St.Laurent wrote:
Flash runs in the browser but as a separate and (still) proprietary
layer. That's my fundamental objection, and I don't see it going away.
Well, that is a political/religious objection, and as such, you're right, I
don't see it going away. That said, I'd wish you'd admit that there are
open source players that implement the SWF file format. [ Macromedia's SWF file format is freely documented. ]
Did you see the
news in New Architect about someone claiming a patent on JPG images? Are
you going to refuse to use JPGs now? What about GIFs? The web grew up on
these proprietary file formats. SWF is no different.
In the longer term, ease of maintenance is a much more important set of
issues. Can generations of different development teams reuse the code
they've been handed while writing in additional updates?
Of course. Macromedia pays a LOT of attention to backward compatibility.
For that matter, you can't even need to upgrade legacy swf files.
Macromedia makes sure that files from Flash versions 3, 4, and 5 also play
in the Flash 6 plugin.
How tightly bound are the data and the processes for working with that
data?
They were fairly tightly bound in Flash 5. They are not tightly bound at
all (by comparison) in Flash MX/6. Yes, they are more tightly bound than
they would be in XML, but Macromedia has struck a very effective balance
given the installed base of users who PREFER it to be tightly bound and the
needs of the applications for which it was designed.
Can I collect information from different sources or send it out to
different places?
Sure.
This was a Web application, but now we want to be able to access it
from cell phones, PDAs, and CB radios.
Well, not CB Radios, but Flash has players in place for handhelds and PDAs.
I think they have them for cell phones too. Portability in theory is great,
but if XML is too slow and bloated for some devices, the portability
becomes moot.
Please note, I'm usually very careful not to characterize stuff I'm not
familiar with, and I don't mean to mischaracterize XML. That said,
Macromedia is doing stuff today, so yes, their time horizon is different
than yours. As Tim once complained about me, it is meaningless to discuss
ad nauseam what might transpire in the future if it is unpredictable. XML
is more like basic research into physics, like the Manhattan project,
whereas Macromedia is more like a chemistry lab trying to refine gun powder
or invent TNT.
At 10:40 AM -0400 10/15/02, Jonathan Gennick wrote:
Is Flash a step backwards because you can't bookmark pages?
I repeat. You can bookmark pages that contain Flash. You can bookmark
"pages" (if you want to call them that) within properly written Flash
documents. This was true in Flash 5, but it is easier to develop this way
in Flash MX/6. FWIW, there are dozens of pages that I visit every day where
bookmarking doesn't work, and these have nothing to do with Flash. These
are usually database-driven pages using, say, ASP or ColdFusion. It is
easier to bookmark Flash than a frameset in most cases, and Flash can
eliminate the need for framesets.
From Simon:
At 01:24 PM 10/15/2002 -0400, Bruce Epstein - Zeus Productions wrote:
That said, I'd wish you'd admit that there are open source players that
implement the SWF file format.
I'll happily admit it. I don't think they matter very much overall,
however - more fringe than Mozilla, and hardly worth comparison to the
piles of open source XML and XML application tools out there.
Did you see the news in New Architect about someone claiming a patent on
JPG images? Are you going to refuse to use JPGs now? What about GIFs? The
web grew up on these proprietary file formats. SWF is no different.
JPG and GIF at least started out as theoretically multi-vendor standards
long before patents appeared to tangle them. I'm transitioning from GIF to
PNG myself, but I don't think the comparison is all that apt. Putting a
graphic in GIF/JPG/PNG is a matter of choosing a value in the 'Save As' box
of a graphics app. Choosing between SWF and other technologies (Java,
Curl, Web, whatever) is a much bigger choice.
Of course. Macromedia pays a LOT of attention to backward
compatibility. For that matter, you can't even need to upgrade legacy
swf files. Macromedia makes sure that files from Flash versions 3, 4,
and 5 also play in the Flash 6 plugin.
Backward compatibility is a good story for vendors. That's not what I'm
asking here, however. I'm asking how difficult it is to reuse the existing
code base in new versions of an RIA moving forward. Macromedia may have a
good story on that, but it's not something I've seen them selling hard.
They were fairly tightly bound in Flash 5. They are not tightly bound
at all (by comparison) in Flash MX/6. Yes, they are more tightly bound
than they would be in XML, but Macromedia has struck a very effective
balance given the installed base of users who PREFER it to be tightly
bound and the needs of the applications for which it was designed.
Sure thing. I guess that's another religious war, since tight binding seems
suicidal to me in Internet contexts, but they're certainly welcome to it.
...
CB radios was kind of a joke, but the VoiceXML people had some fun
with a story like that. Is Flash available for cell phones?
I think they have them for cell phones too. Portability in theory is
great, but if XML is too slow and bloated for some devices, the
portability becomes moot.
XML itself isn't slow - it's just a data format. Bloated, sure, but easily
compressed if that's the issue. Whether the applications (HTML browsers /
SVG viewers / Web Services clients and servers) are slow and bloated is
another issue, of course.
Please note, I'm usually very careful not to characterize stuff I'm not
familiar with, and I don't mean to mischaracterize XML. That said,
Macromedia is doing stuff today, so yes, their time horizon is
different than yours. As Tim once complained about me, it is
meaningless to discuss ad nauseam what might transpire in the future if
it is unpredictable.
Predicting the future is ridiculous. Designing systems with an eye to
flexibility in order to preserve future evolvability is pretty sane.
XML is more like basic research into physics, like the Manhattan
project, whereas Macromedia is more like a chemistry lab trying to
refine gun powder or invent TNT.
Wow. That feels like a grotesque mischaracterization to me. How about I
try one?
XML is more like contractors who take care to ensure that the foundation
and building are up to code and will last a long time for their homeowners,
while Macromedia is a company that builds feature-filled homes quick
without much concern for the building code and rents them out to whoever
needs a house in a hurry...
Maybe some TNT is in order?
Jonathan replied:
On Tuesday, October 15, 2002, 2:10:55 PM, Simon St.Laurent
wrote:
XML is more like contractors who take care to ensure that the
foundation and building are up to code and will last a long time for
their homeowners, while Macromedia is a company that builds
feature-filled homes quick without much concern for the building code
and rents them out to whoever needs a house in a hurry...
LOL! I don't want to agree or disagree with this analogy. I only want to
say that I'm still laughing over it. It's not one that I'll soon forget.
I need a few laughs today too.
Nat Torkington:
Simon St.Laurent writes:
Wow. That feels like a grotesque mischaracterization to me. How about I
try one?
Ooh ooh! My turn!
XML is like a VW Jetta: environmentally sensitive, slow, dependable,
and terminally uncool. Lasts a lifetime.
Flash is like a mid-80s Corvette: impressive but environmentally
destructive. Oh sure, it gets you the chicks for a while, but ultimately
most people sharing the road with you are thinking "what's *he*
compensating for?" It only lasts a lifetime by decreasing your lifetime.
Nat
(grotesque mischaracterizations R us!)
Simon again:
Just remember that I prefaced it as a "grotesque mischaracterization"...
Return to: From the Editors List
Showing messages 1 through 7 of 7.
-
Borky Bork Bork Bork
2003-05-22 14:25:24
anonymous2
[View]
-
Have your cake and eat it
2003-05-20 05:39:48
anonymous2
[View]
-
Flash not consistent on main platforms
2003-05-19 23:19:55
anonymous2
[View]
-
Ubiquitous Rich Clients
2003-05-16 10:38:52
anonymous2
[View]
-
Why not Java?
2003-03-26 16:08:43
clancymalcolm
[View]
-
Java vs Flash
2003-03-26 16:06:55
clancymalcolm
[View]
-
Java vs Flash
2003-08-04 08:35:34
anonymous2
[View]
|
(Flash MX has a very nice, fairly fast XML parser built into it)
Heres an analogy: Technology is a toolbox and it's nice to have more than one tool to use. (Key is being open and experienced enough to know what tools to use for each project)