Rich clients, network wealth

      1 Comment on Rich clients, network wealth

Phil Wainewright, after having drifted too far into the "the web is good enough" camp, now gets back to a point of view I find much more easy to agree with:

"Jon Udell’s recent column on The Google PC generation made a very strong case for deploying PC horsepower to marshaling data rather than enhancing the user interface: "If you join massive horsepower to vast data, amazing things will happen." The mistake that Microsoft is making by pouring resources into Avalon is to focus on perfecting the user experience for solitary creative endeavours at the expense of enhancing good-enough access to the tremendously powerful collaborative resources of the Internet (low-cost photo touch-up service providers, for example)."

While I’m not sure Avalon is so much of a focus that it would hurt Longhorn’s strengths as a rich internet client, at least we agree on the premise: the challenge is to get the best of both worlds, rather than keep opposing reach and richness. We want both, and there’s no doubt in my mind we’ll get them. What platform will get there first, and in what timeframe, is what remains to be seen.
07/15/04 update: Phil got back to this topic here, and addresses the counterpoints I and others raised in this entry (where he underlines the synchronicity between the sale of Oddpost to Yahoo and the acquisition of Alphablox by IBM). I have witnessed firsthand the resistance of resource-starved small and medium businesses to feature-rich but high-maintenance solutions such as the Exchance/Outlook combination, so I certainly can relate to the idea that lighter products such as browser-based apps can be valuable.
Whether Microsoft will be pushed ever further into the upper market by the web and eventually seriously challenged by bottom feeders (Phil’s thesis) or whether it will succeed in co-opting the internet remains to be seen. I’m not saying Phil’s perspective "couldn’t possibly happen," but I don’t think it’s the most likely outcome. Desktop applications show signs of web-ifying themselves quicker than the web is desktop-ifying itself. And isn’t the former way easier to do technically? Yahoo wouldn’t have paid what’s rumored to be significant money to buy Oddpost, were the javascript code they had created trivial to emulate. In contrast, tapping and feeding SQL databases put on the internet, XML streams, or web APIs, with a desktop application is ever easier to do with modern languages and development tools.

07/16/04 update: see also IBM’s Koranteng Ofosu-Amaah’s answer. His last paragraph:

"The major missing infrastructure piece in rich web applications is going offline and synchronizing with good security. But that’s a story for another day."

leads me to come back to two thoughts I’ve had in the past: on the Microsoft side, Groove (whose 3.0 release didn’t seem to generate much buzz) should interact more with the web, while on the opposite corner IBM might want to buy BEA not just to consolidate the app server market. BEA is even more affordable than three years ago (almost to the exact day) when I first pondered how they might be snatched by a bigger player. BEA is again at a 52-week low (they lost half their market cap a few months ago after a disappointing quarter), with a much more reasonable P/E ratio though.

1 thought on “Rich clients, network wealth

  1. Julian Gall

    I am not convinced this is an either/or. It seems unlikely that the client-side processing being proposed would be held back because of the CPU time spent on the UI. When did you last look in Task Manager and see many cycles being used on the UI? Is this really going to be different with Avalon on a machine of suitable spec?
    And if the first generation Avalon machines do struggle, it’ll only be 18 months before they’re racing along with twice the power.
    Finally, the reason we have Seti@home, Genome@home etc. is because even current generation PCs are so underused. There is nothing to stop those cycles being put to use for data marshalling now.


Leave a Reply

Your email address will not be published. Required fields are marked *