7 Years of ASP.NET Innovations with Infragistics
The Story
It is now 2007, which means I've been doing ASP.NET component development for almost 7 years now. I know you’re doing the math in your head right now and saying, wait! ASP.NET isn’t even 7 years old yet! Well, as with most of Microsoft’s platforms, Infragistics started developing components for .NET (ASP.NET and Windows Forms) as soon as we got the first alpha bits. As I’m sure you can imagine, in 7 years I've had the pleasure of being part of some amazingly innovative ideas here at Infragistics. I can still remember the first days of development on the .NET platform. Taking years of component development knowledge (VBX, OCX) and bringing it to a new platform to build controls for ASP.NET and Windows Forms.. a new frontier. Knowing how to create a usable component is knowledge that can be used no matter what platform you're on, and something that you can only gain through experience. The architects at Infragistics have been building components longer than many of us have been programming. The experiential knowledge coming from our architects gave us a huge advantage. The smaller task turned out to be learning the ins and outs of the new platform. Of course since we were dealing with a brand new platform, everyone was at the same level – just starting. With no books or resources available yet, it was all trial and error. So off we went.
The Beginning (2000-2)
My first control was the UltraWebListbar. Keep in mind that we were developing these controls while Microsoft was still finalizing the framework, so the first few months were pretty shaky. Eventually, the framework started to solidify, as did the WebBars and WebNavigator packages from Infragistics – released only weeks after Microsoft’s RTM of the .NET Framework 1.0. The competitive landscape looked a lot different back then. Many component vendors wanted to wait and see if this whole .NET thing turned out to be anything substantial before investing resources. Having already worked with the .NET Framework for a year in various alpha and beta builds, we knew it was something. If you recall, Visual Studio .NET (7.0) didn't come with much in terms of UI Components. We were there to fill the gap, breaking down barriers for developers who wanted to make the move from VB6 to Visual Studio .NET. Ok, back to the WebListbar. We held true to our component designs of the past, and knew that we must offer a fine level of granularity to the developer. The tradeoff of course is that with total control, comes responsibility! The more control we give the developer, the more chances they have to 'shoot themselves in the foot'. We chose a nice blend of control over safety, and added Style objects to our component framework. Each UIElement would be style-able via a CSS Style that could be programmatically set.
Now what fun is a webcontrol that just displays static text/images, with no behavioral functionality? Selections must be represented, and what about hot tracking? The solution was to give those states their own style objects as well. Applying a style after an item is selected was easy right? You simply change the html during the postback, to render down the selected style. But what about hover styles? And do you really need to postback each time an item is clicked? That's when we turned to our friend Javascript. And finally the pieces started coming together to form our Web Presentation Layer Framework or WPLF. The WPLF was the core framework we would use for every WebControl built. They would all have UIElements that can be styled, and would have default/selected/hover states that also had their own styles. We used javascript to perform behaviors on the client side, so that a postback wasn't required. We also introduced the "TargetUrl" property on an item which could be used to navigate to a specific url, or execute a javascript action upon clicking an item. With all of the javascript being written, we now had the beginning of what we now call the Client-Side Object Model or CSOM (see-som). Because we had provided so much behavior on the client-side through Javascript, we ended up with a very robust javascript framework. We found out early on that in order to write maintainable javascript, we would need to emulate OO concepts in a prototypical language. In doing so, we not only created our framework that was responsible for providing internal behaviors on the client, but we also had a framework of api’s that could be exposed to developers who wanted to keep their logic on the client in order to prevent postbacks, and improve the user experience. Client-Side Events were exposed with an easy to use design-time interface to attach javascript functions to be used as event handlers. All of this work enabled our customers to create more client-centric applications, and avoid postbacks. This technique is now a core concept in creating applications for the “Web 2.0”.
Ahead of its Time (2004)
By 2004, we had done everything we could on the client-side. We had a full client-side object model with eventing built-in, we even tracked client-side state changes so that if you changed a property through javascript, it persisted through viewstate. Like many other things we did, this soon became a standard for ASP.NET components. But we had finally hit the limits of performance, based on a javascript only implementation, and knew we must once again innovate in order to get to the next level. In October of 2004, we released the LoadOnDemandXML feature for WebGrid. You could load rows with out posting back! You could make changes to your data live, and update your database without posting back! It was amazing. It was unbelievable! It was AJAX. Of course at that time this technology didn't have a name, so we came up with our own. Looking back on it, I guess AJAX is a little catchier than LoadOnDemandXML. At that time, in order to talk about the technology that would soon be given a name, you had to demo it - there was no other way. So off we went - PDC, customer visits, on-line videos, pod casts, we covered it all. It wasn't until 2006 that we were finally able to explain this feature in a single word – “AJAX” - demo no longer required.
Been There, Done That (2006-7)
Of course, now in 2006, after we've already demoed our AJAX behavior to the world, we still get the question - do you do AJAX? Talk about showing up too early.. We were part of a very small group of component vendors to do AJAX before it was put on the map. We got to watch as others caught the AJAX bug, and entered the component market. What was old hat to us became the basis of new startups, and a lifesaver for other existing vendors. We also saw the emergence of “Atlas”, now just about to be formally released as Microsoft ASP.NET 2.0 AJAX Extensions. Too bad this framework wasn’t around 7 years ago.. Working on the bleeding edge means you must also be a pioneer. When there’s no path to follow, you’re only choice is to carve out your own. And that’s exactly what we have done. Through the years, we now have created our very own client-side framework that provides us with many of the same capabilities that “Atlas” now provides. It’s exciting watching ideas and concepts that you helped work on, become instantly validated by showing up in other mainstream frameworks. Many of the concepts and ideas that we bet on years ago are now key aspects of ASP.NET AJAX Extensions. So what does this all mean? ASP.NET AJAX is an amazing framework to build on, but it’s not a functional requirement. You can do the same things with or without ASP.NET AJAX, it’s just going to be a heck of a lot harder with out it. But for us, we’ve been there – done that. We invested the time in the past to build our own framework, and have used it to do some absolutely amazing things. Should we dump our framework tomorrow and rebuild on top of Microsoft’s AJAX Extensions? I think we can all agree that would be silly. But of course over time you can expect Infragistics to hang up our trusty old framework in favor of the shiny new one.
So here's to 7 years of innovation. And here's to those of you who followed us and believed in us. And for those of you who are just joining us, you should know that you're in for a fun ride, as we blaze a path to the future of web development. What sorts of things can you expect from Infragistics this year? I’ll give you a hint… Application Styling for ASP.NET 