I think there's a lot hidden behind the "if it pans out". ;-)
I think there's a lot of mist around what a "phat client" is that we should try to ventilate away if we're going to agree on anything ;)
These are the kind of toolkits toolsmiths want to write, but do they
provide the kind of environment workaday hackers want to use? So far,
the answer is a resounding "no".
I beg to differ, but then I think we're not exactly on the same page concerning what phat clients are. What you describe certainly applies to things like XAML, to a lesser degree to XUL, and not that much to SVG, XForms, or Flex clients. See right below.
When I sit down to write an app today, there are four models I can use: web-based, standalone fat client, client/server, or server-based. What do "phat" clients bring to the equation?
This is where there's a terminology disagreement. What I call a phat client is something that's web based but does more than HTML+script. It provides a programming environment more reliable than those found in most browsers (ie it is very likely to be javascript based, but you can pretty much trust that you'll have a proper DOM with proper language-specific extensions available portably) and more powerful and flexbile ways of building UIs and processing typical things such as form input/output than are currently available to browsers.
As such a phat client is something that meets halfways between what you call fat clients and web-based clients. It still uses the basic tenants of web-based clients but addresses their shortcomings, notably in terms of UI quality. Meeting in that precise middle-ground seems like an excellent place to me. I can't speak of the design process that has gone into XUL, XAML, or Flex, but I know that for SVG 1.2 the question was "well, we're seeing a lot of people use SVG to build applications and asking for various features which is all strange and interesting since what we did originally was define a graphics format! Let's look at what they want." It turned out that a lot of the people that were doing that were people that had tried to do the same thing in Flash or DHTML, and been bitten by a number of things. We picked the low hanging fruits (just adding the things that were causing problems) and so far the community feedback has been excellent. If you look at the SVG 1.2 draft and search for the features that are targeted at application writing, you'll see there isn't much that'd added. Mostly it's just RCC (defining rendering and behaviour for foreign namespaces) and a better network interface (still in flux, but the idea is there). I'm biased of course, but feedback seems to say it works.
Case in point: XUL has been around for years (both in development and release), yet it is not widely adopted as a platform for software development. XAML may succeed where XUL left off, but then again, XAML is years away, and what Microsoft announced at the PDC isn't necessarily what they'll ship with Longhorn.
XUL is also perceived as Mozilla only, which a number of people see as just a limiting as MSFT-only.
One of the reasons why web-based apps succeeded is because it tied into
a positive feedback loop. People downloaded web browsers because they
were cool. Once a significant number of users had browsers, it was easy
to see the benefits of writing a web-based app. Which drove browser
adoption, continuing the cycle. Where are we with "phat" clients? Stalled
before the initial ramp-up, and stuck in a negative feedback loop: no one
writes "phat" apps because no one can run them, and no one can run them
because no one is writing them.
Well, to be honest the browsers have stalled as well. I think that a lot of the push behind these phat clients is that people have been dealing with the same browser problems for long enough that there is now a certain amount of maturity and that the needs of that community are known with much higher clarity than they were before. I think that those that will succeed are those that'll provide an incremental transition path, but then again I'm biased.
-- Robin Berjon
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
