News Stay informed about the latest enterprise technology news and product updates.

ASP.NET Ajax components: Vendor roundtable -- Part 1

With the AJAX tool market flourishing, enlisted the help of thought leaders in the ecosystem of Microsoft-related Ajax component providers to participate in a virtual roundtable.

With the Ajax tool market flourishing, enlisted the help of thought leaders in the ecosystem of Microsoft-related Ajax component providers to participate in a virtual roundtable discussing key trends in this space as Ajax moves from cool to commonplace.

In this first part of our series, participants talk about the challenges of providing Ajax components, such as browser compatibility issues, the difficulties of JavaScript, the impact on performance and user experience. They also highlight some common mistakes they see their customers making with Ajax. And finally, they discuss the impact of Microsoft's ASP.NET Ajax framework on their market.

Participating are: Miljan Braticevic, president, ComponentArt Inc., Toronto; John Ayers, director of development, and John Juback, technology evangelist, ComponentOne; Joost Lubach, technical evangelist, Dundas Data Visualization Inc., Toronto; Ivo Nedkov, unit manager of the ASP.NET division at Telerik, Sofia Bulgaria (Newton, Mass. in the U.S.); and Anthony Lombardo, lead evangelist and Microsoft MVP, Infragistics Inc., Princeton, N.J. What are some challenges you face as a provider of Ajax components?

Joost Lubach, Dundas: The use of Ajax is currently surrounded by some controversy. While it offers an end-user experience, which is generally considered more "enhanced" than non-Ajax solutions, it provides a great deal of technical challenges. For example, most users will enjoy the fact that they don't see the page 'flicker page reload' when they click a link, but they may not appreciate the possible side-effect that they cannot properly use their browser's Back button anymore. Creating a solution that offers both and satisfies every type of user requires a significantly greater effort.

Furthermore, using Ajax imposes strict technical requirements on users' browsers. Sure, most people will use modern-day browsers such as IE6 or higher, but where a public website is concerned, this assumption can be quite perilous. Since JavaScript is based on different standards imposed by different browser manufacturers, creating a solid platform-independent Ajax application can be quite difficult.

John Ayers, ComponentOne: Honestly, the biggest challenge is browser compatibility. Browser compatibility is something we have to spend a lot of time on.

Ivo Nedkov, Telerik: The greatest challenge for us as a component vendor is to provide rich UI functionality without compromising on performance and end-user experience. Our tools are used by many customers in a variety of projects and scenarios. We need to maintain a broad range of features and support them across all browsers -- IE, FireFox, Opera, Safari, etc. We are continuously working to improve performance.

Anthony Lombardo, Infragistics: One challenge for us has always been the JavaScript side of things -- working with JavaScript, doing JavaScript development. It is difficult to develop in this language; it is very powerful but also very easy to have a bug that goes undetected. A simple line of code that is not typed correctly might not show until it is executed because there is no compiler.

Miljan Braticevic, ComponentArt: Until the Visual Studio 2008 release the technology challenge revolved around IDE support, not so much for our own development as for our customers. The ability to provide high-end features such as IntelliSense with JavaScript and client-side controls was not there. It was introduced with Visual Studio 2008 to some extent but there are still a number of features to add and details to be ironed out; so tooling support is a challenge. This is natural as we extend technology —- tools cannot go before the technology. What is Microsoft's role in Ajax component frameworks versus yours?

Ivo Nedkov, Telerik: Our RadControls for ASP.NET Ajax are built on top of Microsoft's Ajax framework. We are using a very good foundation provided by Microsoft in the System.Web.Extensions and we are enriching it with a lot of additional UI functionality. ASP.NET Ajax provides a standard in the .NET development, not only for Ajax features but for client-side functionality in general. Before ASP.NET Ajax , all developers had to learn and use very different proprietary client-side libraries which were differing in terms of conventions.

Anthony Lombardo, Infragistics: Microsoft is forging the way for the development of Ajax controls and Ajax functionality inside the application. We do a great job inside the component of packaging up Ajax so the developer does not need to know about Ajax -- the grid will automatically do this asynchronous thing. Microsoft is enabling people to write code quicker, to have more functionality using an Ajax mechanism. For instance, we started with Ajax in 2004. With Visual Studio 2008 we rewrote our core Ajax layer to work on the Microsoft layer. Now we have a framework we can build on top of; they are building tooling as well. So we are aiding not only the developers in the world writing code, but helping component developers in building better components quicker, better, and easier to maintain with the tooling available.

Miljan Braticevic, ComponentArt: Microsoft's role is the same as it has been in all other development platforms. They ship ASP.NET and a number of controls in the box, but the main product is the framework itself. There are controls there to help with the development of applications to build something useful out of the box; but the most significant thing is the framework itself and the blueprint for how the controls and tools should be written. They build a rich ecosystem around the platform, keeping component vendors informed so we can add value to the platform by building more feature-rich or better-performing controls. I don't see any part of the Microsoft offering as competition with our products. On the contrary, the more marketshare the Ajax framework gets, the bigger and better story we have.

Perhaps some of our competitors offer different perspectives. Some have released their own Ajax frameworks then discontinued them. We never intended to compete head-to-head with Microsoft in the core framework part of the stack.

John Ayers, ComponentOne: Our current generation of controls have an internal framework, but in the future we plan to release something built on the Microsoft Ajax stack. Our current controls can interact with the Microsoft framework today. Are there common mistakes you see customers making with Ajax?

Joost Lubach, Dundas: Yes. When it comes to a relatively young concept such as Ajax, which relies on a scripting language most people probably find unfamiliar (JavaScript is often misunderstood by developers), it is easy for technical mistakes to be made.

The biggest mistake I see people making, however, is not necessarily a technical one. Ajax , which is essentially a "hack," using an obscure browser feature that was never intended to be used for Ajax -like purposes, requires developers to do proper requirements and risk analyses. As mentioned above, using Ajax may have unforeseen ramifications, such as a browser's Back button not working or the loss of built-in browser feedback features -- a progress bar, an animated browser logo, etc.). Failing to prevent these side effects is possibly the biggest mistake one can make with Ajax.

Ivo Nedkov, Telerik: One of the most common mistakes is that people do not optimize their Ajax configurations. Ajax is really powerful when you have only the needed callbacks to the server without any unnecessary trips and HTML updates. One of our tools provides a really efficient visual way of configuring all Ajax calls on the page, which controls start the Ajax requests and which are being updated. This is a great productivity tool with which developers can optimize their Ajax functionality. Most importantly, it does not require you to write any code, everything is done codeless through a Visual Studio configuration wizard.

Anthony Lombardo, Infragistics: One common mistake early on was trying to fit in an Ajax behavior or mechanism where it didn't belong. A prime example is the time for connection [over the network] from one place in the world to another. If there are a lot of asynchronous requests opening up, each one carries a lot overhead, so you are giving a worse experience to the person on other end. If you are building a site and you are not expecting wide geographic use that is not a concern. But there is a time and place for Ajax. You have to ask, would the experience be better using Ajax or trying something else?

Miljan Braticevic, ComponentArt: The ASP.NET Ajax framework itself is quite developer friendly. If you use the update panel control it is almost hard to use incorrectly. There are maybe some misconceptions around performance that should be noted; for example, customers think they will always get better performance if they use the update panel. The update panel control itself is just the beginning; it is not the best performing way to get Ajax functionality onto a page. There are other techniques that produce better performance but require additional work by the developer.

In Part 2, our participants talk about the resurgence of JavaScript, XML-based Ajax vs. Ajax without XML, and the future of Ajax.

Part 3 focuses on the fate of the open-source community over the next few years.

For Aditional Information: View the Ajax Learning Guide

Dig Deeper on ASP.NET, Ajax and Web application development

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.