Recently, a prospective customer contacted us regarding some miserable performance in their asp.net application...
The issue was directly attributed to a component being used in their solution. Needless to say, they were not happy and after seeing the application, I don't blame them.
This experience got me to thinking and I thought it might be valuable to explain in a blog post why we re-wrote our ASP.NET grid and ask for your thoughts/feedback on ways in which we can help you transition from other controls to ours.
First - up until late 2006- our focus here at Developer Express was components for Windows Forms. Though we developed ASP.NET controls, Windows Forms was always first in line within the organization. As you can imagine, this meant 2 things. Our Windows Forms products kicked butt (and still do) and our ASP.NET controls did not. Late last year, we decided it was time to change the equation and pay far more attention to ASP.NET and take the steps needed to deliver the very best tools we possibly could for this platform.
Our ASP.NET Grid Problem
In December 2006, we had numerous discussions about our then shipping ASP.NET grid, the ASPxGrid. Though many of us felt the grid compared well with others available in the market, some of us felt it was time to rewrite the product for ASP.NET 2 and deliver features that clearly distinguished it from the competition. Like our competition, the ASPxGrid was a product that had evolved with ASP.NET. As ASP.NET moved forward, our engineers plugged in new features that were not considered when the product was first engineered. This meant that over time, it became a big fat ugly cow. Yes it worked, yes it did what we said it did...but once pushed hard, it began to show its weight. Fact is, many of our competitors face this reality and proof of this lies in the products available in the market and the necessity to rewrite old products to take advantage of new technologies in full - without overloading a product.
Topmost in our minds for our new ASP.NET grid was performance and memory footprint. As we've tried to describe throughout our website, we concluded that its useless to build an advanced grid control with features such as data grouping, sorting, and summary computation if it cannot effectively and accurately display data in a timely manner to end-users.
Ultimately, you are the sole judge as to whether our goal to build the most performant ASP.NET grid control was realized. If you have not yet seen our online demo describing its features, be sure to checkout
http://demos.devexpress.com/ASPxGridViewDemos/DataBinding/XPOLargeDB.aspx?Section=1
...and compare our product to those you are currently using.
As you can imagine, writing a new control is not a trivial undertaking...but what is perhaps much harder is convincing people to take the next step and actually replace existing products.
We know that one of the toughest decisions a developer or company must make when choosing to replace existing controls is the time required to remove poorly performing products and replace them with those that meet the customer's requirements. Part of our responsibility is to help minimize both the cost and risk associated with conversion and I want to make certain that we take the steps necessary to accomplish this.
A few ways in which we can help you with your transition are obvious:
Better Documentation
Real-World Tutorials
Practical Application Samples
Training Screencasts
Other ways might include project converters that convert one control for another. This is not a trivial task, but something we've done in the past.
If you have other suggestions or desires I want to hear from you - feel free to send me an email with any feedback.