Has Web Development lost its proposition?

Web development is popular because it’s fast, versatile, and relatively inexpensive. But that doesn’t mean the alternatives don’t have advantages and merit of their own, and in some cases the Web’s weaknesses might outweigh its strengths.

With the advances of hardware processing power & software functionality, it is viable to re-visit the original reasoning behind developing applications for the web. In addition, it is viable to also re-visit the definition of web application, especially in the light of increased popularity around Rich Internet Application (RIA) models like Microsoft Silverlight, Adobe Air, and AJAX technologies – that seek to blend thin & thick client application deployment. For the sake of healthy discussion lets look at some areas where web-based applications stack up against system based programming.

With the traditional web-application model there is a front-end thin Client UI that functions in the framework of browser. This UI handles rudimentary user input, generic input validation, graphics rendering, display of the output. The real processing happens in the middle-tier integration layer and back-end database. With the advent of cheaper processors and memory, even the bare-bones computers of today, can put an enterprise grade machine of a decade ago, to shame. Thus, we want to ask, is it time we reassessed such traditional model. Is it viable for us to shift some of the over-burdened processing load towards the front-end. With increased demand of information consumption, more and more load is being put on the integration & back-end layers, to a point where scaling data-centers to meet the demands is becoming challenging. The middle-tier also suffers from security vulnerabilities both in integration & demand load.

Increasingly, the evolution of Web standards is being driven by a select few major browser vendors, with Microsoft’s Internet Explorer on one side and Apple’s Safari, Google’s Chrome and Firefox on the other. The vendors implement new features first and standardize them later with shaky agreements at best. Independent developers have little genuine input into the future direction of the Web. Does it make sense to rely on client-side software that’s such a moving target? Does it make sense to constantly require re-work to the front-end while relying upon such shifty browser software

The Web based applications are stateless, they are typically form based UI that take user input, and serve back the result wrapped in sometimes fancy graphical wrapper. Is this necessarily the right model for every application? Is the sacrifice of full range of real-time interactivity offered in OS-based apps, worth today’s almost negligible processing speeds of client-side computers?

While system programming lead to building apps with consistent UI toolkits such as the Windows APIs, or Apple’s Cocoa, building a Web UI is too often an exercise in reinventing the wheel. Buttons, controls, and widgets vary from app to app. Menus are along the top, other times they’re off to the side. Sometimes they pop down when you roll over them, and sometimes you have to click. This is compounded with the variety of coding frameworks that all promise better performance only to lead to minor efficiencies, yet quite not matching that of system based programs. All this inconsistency hurts the development budget, but hurts usability even more.

We might want to ask if sacrificing the full range of languages, tools, and methodologies that systems programming has to offer worth the pains in support & processing we experience while we shoehorn interactivity on an otherwise simplistic input-ouput based platform like the web-browser? Yes, JavaScript has evolved into a respectable general-purpose language, but it could be expected to be all things to all people. User interface code written in such languages as C++, Objective C, or Python can often be both more efficient and more maintainable than code written for the Web paradigm.

In today’s usability and higher demands on information, HTML and CSS are clearly deficient when it comes to rich interactivity and are often augmented with yet more layers of associative technologies to deliver on expectations. As evident with the proliferation of multimedia plug-ins such as Flash, QuickTime, and Silverlight. Relying on these outside dependencies increases the complexity and support cost of your applications. Why bother? These tricks wouldn’t be necessary if we weren’t trying to shoehorn interactivity into the browser instead of sticking to the desktop.

The traditional argument that web-based applications lead to portability and cut the need for tethered access to desktop or office system, is also a suspect, in our world today. With the advent of cheaper laptops, employees are increasingly able work from satellite locations using enterprise VPN, secure access tokens, and corporate firewall access. Organizations are increasing portable laptops, which are at times more powerful than desktops, due to ease of maintainability. Thus, these corporate issued laptops provides portability and at the same time, the horse-power to run system based programs. Does this trend make us re-evaluate the argument that application portability can be achieved by web-application alone?

The current trend setters in mobile access like iPhone, and Windows Mobile have moved away from browser based applications. iPhone relies on Apple’s COCOA with a iPhone SDK wrapper, Windows Mobile relies on .NET wrapped with Win Mo SDK wrapper. In essence these mobile devices have implemented system application with additional wrappers. This is yet another testament how miniaturization in technology has evolved and how even devices like our mobile phones prefer to handle system applications vs. web-based applications.

The debate between Web based application vs. System based applications is not simple. For many applications, Web-based development and deployment remains the cheapest, fastest route to market. But in the midst of our zeal to cut costs by sticking to Web standards and technologies, it’s important to understand the trade-offs, too.

Bookmark this article