On Tue, Nov 18, 2003 at 06:40:26PM -0800, Kip Hampton wrote: > There's been a lot of buzz and other noise going on about how the next > generation of Web-based applications will be implemented. [...] > More than just browser-embedded > applets, the trend seems to be toward client-side "runtime engines" that > get both their UI definitions and data via XML over HTTP and "web > services" interfaces. Examples include Mozilla's XUL, MSFT's XAML, and > Macromedia's Flex. > > IMO, this trend (if it pans out in reality) puts AxKit in a positive > position for faster and wider adoption. [...]
I think there's a lot hidden behind the "if it pans out". ;-) The "phat" clients you describe are something of a holy grail for technologists. Technically, they're better solutions than rewriting everything in Java, relying on Qt or Wx for cross-platform products, working within the contraints of [X]HTML/HTTP, porting to C# (and hoping Rotor/Mono work out if you need cross-platform support) or cracking open that copy of Petzold's Win32 programming that's sitting under your monitor. 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". The reason why webapps made it big is because they solved many of the nasty problems of client-server software created, and solved those problems by breaking all the rules. There's a *huge* class of applications that shouldn't be done with fat clients, and the web solves that problem 9 times out of 10 -- with CGI, PHP, J2EE or mod_perl and AxKit. 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? A better way to write standalone and networked clients? And precisely *how* is it better? Because I can use different (read: less mature) tools to get my job done, or because my Windows-based app can be used on some platform my customers have never heard of and certainly don't use? 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. 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. So I'm down on the whole "phat" client meme. But I'm not down on AxKit or increasing returns from XML. One trend I *do* see from my Mac OS X desktop is towards more network-aware apps. Things like Sherlock, Watson, Netflix Fanatic, NetNewsWire, and even cutesy little hacks like OmniDictionary. There's an increasing trend for desktop apps (developed however you want) to provide a rich interface to information on the web, either through screen scraping, specialized protocols or web services. Maybe XForms, XUL, XAML, Flex, Wx, Qt, Perl, Cocoa or your FORTH will help you get the client side written. Maybe that client will be cross platform. It doesn't much matter, because what matters is the ability to write a dozen such clients to consume that feed off of the web. (I'm waiting for someone to create a desktop app called AmazonShopper or something that de-clutters the shopping experience at Amazon. Or not, depending on what their license permits.) Z. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
