Joe Stegman - Reacts to "Web is taking it all" statement

The Discussion

• 

  The web is taking over all applications that can be designed with a simple, input-postback state machine. As of this writing, web applications cannot maintain complex state---and I say this in view of the Outlook 2003 Web Client and the tangled conceptual mess that is SharePoint Portal Server.
  
  The web application begins to fail when it begins to feel like a time-consuming, sequential "wizard" (which happens quite a bit in SharePoint interfaces). The rich client is clearly superior where the web application begins to fail.
  
  But history teaches us that organizations can cheat and lower the bar of what a professional, enterprise application is and when this happens the web will take "all" application development.
  

• 

  rasx wrote:

  The web is taking over all applications that can be designed with a simple, input-postback state machine. As of this writing, web applications cannot maintain complex state---and I say this in view of the Outlook 2003 Web Client and the tangled conceptual mess that is SharePoint Portal Server.
  
  The web application begins to fail when it begins to feel like a time-consuming, sequential "wizard" (which happens quite a bit in SharePoint interfaces). The rich client is clearly superior where the web application begins to fail.
  
  But history teaches us that organizations can cheat and lower the bar of what a professional, enterprise application is and when this happens the web will take "all" application development.
  

  
  
  I mostly agree but also somewhat disagree on certain points.
  
  Certainly windows forms has certain advantages, but the design of the sharepoint also helps people to focus on the current task they are completing. So web interfaces might be in fact superior because of their simplicity and sequential wizard style.
  

• 

  Keskos wrote:

  So web interfaces might be in fact superior because of their simplicity and sequential wizard style.
  

  
  
  Before the .NET hype I was a Win32/Desktop Developer, Then along came Java, ASP and now ASP.NET allowing this "Web is taking it all".  My first expirience with the Web was of course ASP.NET which is by the way a terrific platform that outperforms and outclass others by far.
  
  Whoever no matters how advanced it was I always felt like my hands are tied.
  
  I'm very excited with technologies like ClickOnce and the up coming Avalon 'cause it gives to WinForms the only real advantage to WebForms... simple deployment, and thanks to .NET you can kiss the COM/COM+/Registry mess good bye.
  
  By the way Keskos, there is no reason for a WinForms application not to be sequential-wizard like (in fact wizards first appears on the desktop world).

• 

  raptor3676 wrote:

  By the way Keskos, there is no reason for a WinForms application not to be sequential-wizard like (in fact wizards first appears on the desktop world).

  
  
  Exactly, Windows forms or any "smart client" technology has this flexibility. The "wizard" interface is great for the first-time user but they can become time-consuming to the advanced user.
  
  As suggested in my previous post, the application architect can simply say, "F*ck the advanced user" and appeal to larger market of first time users. This was the success of AOL architects. But I think we all (or at least most of us) have a certain opinion of AOL.
  

• 

  I think we've sort of come full circle and reached a better place for it. We had the "everything on the client", Win32 approach and bemoaned the difficulty in deployment and connectivity.
  
  Then we had the WebForm and bemoaned the lack of a rich UI and the artifical restrictions brought about by it.
  
  Now we've got the Web-enabled, ClickOnce deployed smart-client. And for the most part it promises to "fix" the problems of the two previous models.
  
  Doubtless in a few years we'll all be only too aware of it's limitaitons, but by then Web Service based apps will come of age and we'll be ready to move it all off the client again! ;=)

• 

  Well don't intermix the plumbing concepts with the thickness of the client.  Whether you use the thinnest of web clients with most of the heavy lifting done at the server or the thickest of clients on the desktop, choosing between DCOM, OLEDB, MSMQ, Web Services, or ad hoc plumbing is a separate decision altogether.
  
  Much of what I see in Avalon still looks to me like a recycling of the somewhat stillborn concepts behind DHTML.  What screwed DHTML for practical work (beyond typical JavaScript gingerbread) were promises never fullfiled in IE along with the headache that security became.  Because of the vulnerabilities inherent in these powerful tools (scripting, ActiveX, scriptable controls, etc.) we ended up with a mess if we wanted to provide a decent user experience without using dangerous browser security settings.
  
  That said, with proper code signing, IE security zone settings, etc. it was quite possible to provide quite a "rich" experience via DHTML.  Such "web pages" or even HTAs could easily be either thin and rely strongly on mid-tier servers or "thick" and talk directly to back tiers in the manner of conventional 2-tiered applications.  There is really nothing to keep you from doing this today using "Web Services" as the plumbing - though most of the pre-.Net bits you need are out of vogue now.
  
  Avalon just updates the concept and makes use of the .Net technologies under the hood, solving many though not all of the security issues and of course offering a lot of new richness from the developer's perspective.