LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST

 

Events calendar tab
EclipseCon
3/22/2010 to 3/25/2010
Santa Clara, Calif.
The Eclipse Foundation

DevConnections
4/12/2010 to 4/14/2010
Las Vegas
Penton Media

MySQL Conf. and Expo
4/12/2010 to 4/15/2010
Santa Clara, Calif.
O'Reilly Media

High Performance Computing Linux Financial Markets
4/19/2010
New York City
Flagg Management

Informix User Conf.
4/25/2010 to 4/28/2010
Overland Park, Kans.
IIUG


 
print Printable version 
Most Read Latest News Blog Resources
Mono brings .NET to Android
At Microsoft MIX, Mono will unveil the ability to port .NET applications to the Android op...

IBM brings Rational tools into the cloud
Fifteen Rational products for managing, developing and testing on clouds are now available...

Going 'all in' on .NET as default runtime
Programmers for Windows Phone 7 will need to use Silverlight and XNA for development

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

'Til the Fat Client Sings


By Larry O'Brien
July 15, 2004 — 
Web-based deployment comes in and out of favor but often founders because of the conflation of HTML-using, browser-based and Web-deployment concerns. Additionally, many discussions of "fat client," Web-deployed software get derailed by concerns about server-based "rental" fees or server-side resource consumption.

Web-based deployment comes in and out of favor but often founders because of the conflation of HTML-using, browser-based and Web-deployment concerns. Additionally, many discussions of "fat client," Web-deployed software get derailed by concerns about server-based "rental" fees or server-side resource consumption.

Joel Spolsky, the insightful proprietor of Fog Creek Software, dropped a cherry bomb in this particular anthill by writing "How Microsoft Lost the API War", in which he concludes that "the new winners in the application development marketplace will be the people who can make HTML sing." In other words, he says that only the thinnest-client model is viable.

Spolsky does a good job differentiating two competing camps within Microsoft: one dedicated to backward compatibility (he labels this the "Raymond Chen" camp, after the Microsoft developer who diligently blogs about the issue), and another dedicated to furthering the use of every conceivable combination of Microsoft technologies (the "MSDN Magazine" camp).

Naturally, the Microsoft argument is that these two camps are totally cooperative, that users might want to build apps that rely upon integrating BizTalk with Flight Simulator via SharePoint. Nevertheless, Spolsky's construction identifies a real tension that exists, not just at Microsoft, but at any company evolving complex software.

However, it's putting the cart before the horse to claim that lack of backward compatibility can drive the choice of thick or thin clients. The choice of client "thickness" is based on the UI and deployment.

Although the UI often drives the choice, the deployment model, which consists of updating directories on the production server and having them load in clients over the network, is a more compelling point. You can't do everything you want with a hyperlink and a stylesheet, but you can prevent nightmares by having a single source for critical binaries.

"Web applications don't require Windows," says Spolsky, which is true only in two very specific senses: Web applications don't require UI APIs, and Web applications don't necessarily need to use APIs developed in Redmond. But Web apps do need database access, networking and threading; initialization and configuration customization; error handling and recovery; logging; file system access; e-mail; messaging; globalization; security and encryption...

Not every app needs all of these features. But for a given number of nontrivial capabilities, API complexity is linear, if not constant. Even if you believe that every Java API is superior to every .NET API, that every Python library is more powerful than every C library, you still need essentially the same order of APIs to fulfill an application's worth of use cases.

This isn't saying that one shouldn't know about and use the strengths of different languages and libraries: If you're doing hypermedia, you might use a Web browser, or an HTML widget on a thick-client's form, or spend a gazillion hours programming your own. All of those count as one API.

Similarly, for parsing XML documents, you can choose between a platform-specific API (such as .NET's XPathDocument), a standards-conformant API (DOM), or roll your own with regular expressions. Does a standards-based approach have advantages? Absolutely. Even if you don't have a starry-eyed belief in the quality and good faith of standards, it's nice to have knowledge that's portable. But an API is an API, whether it comes from Redmond, SourceForge or the United Nations.

Certainly the market has spoken in favor of improving interoperability, and you could write an essay called "Microsoft Lost the API Wars" based on the premise that where the market used to accept Redmond-based APIs fairly readily, the phrase "lock in" is now quick to the lips. Spolsky comes close when he concludes that moving to ASP.NET would bog him down without return on his investment.

I'm not going to advocate embracing Microsoft lock-in or chasing its latest APIs, but you can't get away from external dependencies by writing HTML.

Web-based deployment of fat clients that can work in an "occasionally connected" manner goes a long way toward controlling brittleness. The cost is potentially hefty downloads of the associated binary dependencies, including everything from the .NET runtime to specific assemblies. Compared with the married-to-the-Web choice of HTML-based applications, it seems an easy decision.

Larry O'Brien is a technology consultant and analyst, and the founding editor of Software Development Magazine.


Share this link: http://www.sdtimes.com/link/28001
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading