Say Goodbye to BBAs

Browser-based applications suck, one reader puts it simply. A properly architected and developed Win Forms application (or other smart client) can do anything a BBA can, and more.

• By Readers of Visual Studio Magazine
• 12/01/2005

Letters to Visual Studio Magazine are welcome. Letters must include your name, address, and daytime phone number to be considered for publication. Letters might be edited for form, fit, and style. Please send them to Letters to the Editor, c/o Visual Studio Magazine, 2600 El Camino Real, Suite 300, San Mateo, CA 94403; fax them to 650-570-6307; or e-mail them to [email protected].

Say Goodbye to BBAs
My hat goes off to Billy Hollis for daring to speak badly of the browser-based application (BBA) [Good Riddance to Browser-Based Apps," July 2005]. As he puts it simply, "... the browser sucks as an application platform."

The BBA aimed to cut implementation and support costs and to improve the user experience. How many times have you run a Web app, hit the back button, and been thrown into Never Never Land, only to lose data and become frustrated? The BBA is a great idea, but all too many architects and developers implement the idea poorly. If hitting the back button causes this behavior, then take it away from the user or develop different functionality for it. It's that simple.

For small companies to implement a BBA, they must run and support IIS and deal with all the trouble that goes with it, not to mention the risks of hackers, worms, and more. It costs dearly to train staff in IIS administration, ASP, HTML, XML, and so on. A properly architected and developed Win Forms application (or other smart client) can do anything a BBA can, and more.

By the way, I am a programmer of five years using Access 97, VBA, VB6, and SQL Server. But that's another story—see Karl E. Peterson's Guest Opinion, "Support Classic VB" [May 2005].

Tim Wicktor, Tampa, Fla.

VB Deserves Professional Features, Too
It is quite irritating to watch Microsoft plan new "professional" development features for C# and not Visual Basic. It seems that because VB is so easy to use and understand, Microsoft is convinced that laymen are all who use it. In fact, there are plenty of professional developers who use VB over C# for their primary development language.

VB supports design-time compiling, better code completion, and code that is simply easier to read over many other languages. These features are not in C# because the developer community hasn't asked for them.

With Visual Studio 2005 on the horizon, Microsoft has developed a number of new technologies into the framework and languages. Generics is a great new feature, but it was planned originally for C# alone. Only after the VB community complained was it added to the VB feature list.

Refactoring was another feature targeted for C#. Again, VB users complained, but it was too late, and Visual Basic 2005 will ship without this important tool.

I'm a professional developer. I'm tired of fighting with Microsoft to make sure it includes the tools I need in my language of choice. Microsoft worked hard to make VB the most popular computer language—now it needs to treat it with the respect it deserves.

Robert Beaubien, Glendale, Ariz.

CTP Affects Client Callbacks
With the release of the August Community Technology Preview, Microsoft changed the implementation of client callbacks in a small but significant way, affecting part of my ASP.NET column, "Integrate the Client and Server" [July 2005].

To better support asynchronous processing, Microsoft split the RaiseCallback function in the original implementation into two parts. The original RaiseCallback accepted a string parameter and returned a string parameter. The new version consists of a subroutine (still called RaiseCallback) that accepts a string parameter and a function (called GetCallbackResult) that returns a string value. RaiseCallback is still called from the client-side code and is passed the client-side value, but immediately after it runs, the GetCallbackResult function executes. You can do your server-side processing in either routine as long as the result of your processing is returned by GetCallbackResult.

Please take a look my July ASP.NET column, as the text and code have been updated to reflect these changes.

Peter Vogel, Goderich, Ontario, Canada