Something we've been debating at Ignia recently has been the value of server wrappers for AJAX controls. Ever since the first version of ASP.NET, the textbook approach for web controls was to wrap them in a server control. This provides a number of key benefits:
- Support for data binding to server-side data sources, including control themes.
- Participation in the ASP.NET page event life cycle, including handling of client-side post backs.
- Abstraction of backend technologies for UI developers via a familiar declarative interface.
- Abstraction of client technologies for backend developers via encapsulati client logic.
These benefits have created an entire niche industry of control developers (such as ComponentArt, Telerik and Infragistics) who provide all-inclusive frameworks complete with their own (usually proprietary) AJAX, JavaScript-enabled controls and server-side wrappers. These control suites usually retail somewhere in the $1,000/developer range, although their licensing terms vary significantly. Some, for example, license the designer tools where as others license the output, which can impact distribution rights. Of equal diversity is the quality and sophistication of their architecture; while purchasing a third-party control may save development time up-front, this can often be outweighed by the cost of integration and customization.
Five years ago, these tradeoffs were easy to justify for a comprehensive set of AJAX-enabled controls that were immediately ready for market. Today, however, with so many JavaScript frameworks available, it's harder to justify. There are four reasons for this.
First, the quality and sophistication of these client-side frameworks has improved significantly. Functionality that was difficult to accomplish across browsers on the client a short while ago is easily accomplished today with minimal effort via mature libraries such as jQuery, MooTools, Dojo and Prototype. And if the functionality isn't available, it's often easy to write plug-ins or extensions to add the functionality on top of an existing framework without recreating the wheel. For instance, extending or customizing the functionality of, say, a ComponentArt server control beyond the out-of-the-box parameters is far more involved - and not just because it's source is either closed or obfuscated, but also because the architecture is optimized for configuration over customization. This can be contrasted with ExtJS, for example, which has an architecture built for extensibility from the ground up.
Second, the cost and licensing are far more flexible on the client-side frameworks. Many are available under the permissive MIT license which makes redistribution easy. Paying a one-time $1,000 fee per developer for a control suite is hardly a concern, but if the license isn't redistributable then this can be economically infeasible when applied to small projects or product licensing fees. Even ExtJS, which has a per-developer cost for its MIT license, is far more friendly toward redistribution than some of the all-in-one control packages.
Third, the benefits of server-side integration is quickly dwindling due to the direction of technology. The most obvious example of this is AJAX, which separates the data and processing from the view. The second is Microsoft's implementation of the Model View Controller pattern in their MVC framework, which provides a similar separation. With these, the benefit of being able to respond to events, bind data or even programmatically configure options via an integrated, object-oriented server-side API becomes notably less critical in most (albeit not all) cases. This is especially true when you look at Microsoft's ASP.NET WebMethods which make wiring up client-side events to server-side functions a trivial task.
Fourth, the integration layer no longer necessitates generalists. Five years ago, server controls mitigated a skills gap in the integration layer. This allowed a backend developer to implement sophisticated client-side controls without being versed in JavaScript, the DOM or browser distinctions. Similarly, it allowed UI developers to integrate with server-side functionality using familiar and friendly declarative markup, since it abstracted them from the backend details. Today, however, the role of the integration layer has changed significantly. On one hand, JavaScript frameworks now provide object-oriented functionality and buffer the developer from arbitrary distinctions in browser applications; as such, it's fairly easy for a C# developer, for instance, to jump between .NET and JavaScript. Conversely, from a completely different perspective, the ability of AJAX, Web Services and MVP to separate presentation, processing (business logic) and data also makes it easier to have specialists without introducing a skill gap at the integration level.
That said, there's nothing intrinsic preventing server-side control developers from addressing all of these issues and, thus, remaining competitive with their client-side counter parts. In fact, there are cases where this is true. An obvious example is the ASP.NET Control Toolkit which, recently, has begun to show maturity and stability as a free, open-source and tightly-integrated suite of wrapped controls. A commercial example is Obout which provides very competitive pricing, including options for source code, redistribution and even ala carte licensing alongside a very solid architecture and API.
Of course, even if all things were equal, there remain benefits to using an exclusively client-side framework. First, it's arguable that due to their broader audience client frameworks can afford an economy of scale which will continue to provide competitive benefits to the consumer in terms of licensing, sophistication and cost. Second, on top of being unnecessary, abstracting the integration layer is arguably a setback now as it requires both backend and client developers to be aware of ASP.NET specifically. Third, and related, this awareness of ASP.NET also translates to the platform and, thus, provides more environmental restrictions - particularly in terms of remoting and distributed applications; using a client-side framework is an easy way to make your presentation layer, at least, platform agnostic.