Results for Ajax usage among .NET developers

Simone Chiaretta recently posted the results to his Ajax usage survey

Check out the: .NET Ajax Survey results

Simone has a great write up, including the raw data, I encourage you to check it out...  But A couple of things that popped out to me:

image 1. Simone concludes that 84% of ASP.NET developers are using ASP.NET AJAX... That is an amazingly high percentage... I am excited that we could help that large a percentage of developers!

2. I am a bit surprised that only about ~50% of developers are using the AJAX Control Toolkit.  I'd love to hear your thoughts on using the toolkit?  Do you think it is a naming thing (people don't get the difference between ASP.NET AJAX and the AJAX toolkit?) or maybe it has to do with the heavy update panel usage, or are the factors that prevent developers from using the toolkit?  Any theories?

3. Apparently, UpdatePanel kicks butt!  91.8% of ASP.NET AJAX users are using UpdatePanel.  Personally, I love this feature as well.  It gives you Ajax style of interactivity for your application without writing client side Ajax code!

4. Last but not least, I am absolutely amazed at the high early uptake of the ASP.NET MVC Framework.  We are just a couple of weeks into our first public CTP and already 2.3% of folks said they are using it!  That is way higher than i'd expect so early on.  What is more, is that his a much higher percentage than any of the other, much more mature, MVC frameworks.

Comments (13)

  1. Keith Patrick says:

    Count me in that group that doesn’t like the control toolkit. For starters, it just doesn’t feel like an MS product (was it written by community contributions?), has pretty terrible documentation, IMO (MSDN is pretty good with its own faults, but control toolkit stuff is more of a "Look at this example and figure the rest out yourself", mixes too much client-side stuff in with the AJAX (outside recording drop position, what does dragging a window around need async callbacks for? If you have some great javascript-based controls to write, release a separate toolkit…or better yet make the former an extension of the latter). And (finally?) when those controls don’t act right (typical for a 1.0), they are EXTREMELY difficult to debug…I’m talking going through every window in the Script Explorer to drop breakpoints all over JS and cross fingers that the call stack doesn’t lead to you a delegate call.

  2. Keith Patrick says:

    OK, I was wrong about the "finally" part, as it hit me what the control toolkit reminds me of: the MS P&P "Enterprise" Library. I see that thing used way too much with the idea that because MS puts it out, it has to be good for .Net, when in reality, it’s not quite ready for primetime and is almost as much of a disappointment to integrate with as 3rd party libraries (although if I was on an island and I had to pick either to stare at for the rest of my life, it’d be the AJAX control toolkit)(

  3. Al Pascual says:

    The numbers seem a little high, the ain’t many websites using AJAX out there, yet …

  4. Damien Guard says:

    Like all surveys this isn’t truely representitive of the entire market but simple of those that came across his blog.

    The sort of people who read his blog (and DotNetKicks where it got exposure) are those people actively seeking information and new ways of doing things.  If you managed to survey those people who don’t read DNK I think you’d find those figures much much lower.


  5. Mark Thomas says:

    I jumped on the Ajax bandwagon (professionally) 9 months ago and haven’t looked back.

    I started using the control toolkit and was really excited about it (the videos where a great help), but then I chose to use telerik RadControls, which at the time did not work with the toolkit. Now "upgrading" to the Prometheus versions I expect to start using the toolkit again, as this is based on MS ASP.NET Ajax 🙂

    Great stuff!

    Really helps impress the bigwigs in my company!


  6. Simone says:

    Actually half of the people came also from this blog.

    Again, something that Brad didn’t mention is that Ajax is used by 69% of the devs in a production environment, 61% in devs and 23% in a prototype product.

    In response to Al, I bet these 69% is mainly in private, intranet-only web applications, not public websites.

  7. Malcolm says:

    I like the concept of the toolkit and want to use the controls, but it feels "half-baked" and I have had many issues with implementations.  I wish this was a MSFT feature and that it was more integrated with VS, etc.

  8. Somalian says:

    Hello all,

    I am a new .net developer, to be honest I don’t even think I should use the title "developer" yet but  I have put together small .net website and added some Ajax functionality using the Ajax Control Toolkit. I have no formal education in but after reading few books I wanted to see if I can do it. I don’t have much on the website but it looks good. Listed below are the controls I have used so far.

    1) Collapsable Panel Extender on the login box.

    2) Accordion control on the Poll area.

    3) UpdateProgress control on the  BrowseArticles page.

    4) ValidatorCallout Extender on the contact us page.

    5) Tabs Control on the main page.

    6) SlideShow Extender on this”> page.

    7) UpdatePanel on the polls section.

    Here is the website none of this would have been possible with out the help of "How Do I Videos" so thanks Joe Stagner.

    Thank you all.

  9. Greg says:

    I agree with Malcolm and others concerning the toolkit about just not feeling right.  I have tried 3-4 controls from the toolkit initially and never could get them to work "just right".  After standing back and looking at the time I spent trying to get them to work, I opted to remove them all together and will wait for the next "version" that will be a bit more optimized hopefully.  They seemed to have a slow response time on the final product and had several people comment on that they would just rather go back to the old way of postbacks.  Granted it was only a couple of people but I noticed it as well.

    I took the survey and I usually don’t post comments about anything but felt compelled to add my .02.  I do use AJAX in certain parts of our applications but only in certain places where it seems beneficial.  Over time I do see using it more but right now, it’s a slow integration process to see what reaction we get from our customers.


  10. laimis says:

    I am floored by the percentage of people using the UpdatePanel control. (Although we don’t know who replied to the survey, etc.) We used it all the time in the ajax pages until we realized what kind of beast it is and how it works. It is like shoving ajax down the page model throat. So now it is all ajax calls to web service with update panel removed. Works great.

  11. Alexey says:

    The name of the Ajax Toolkit library itself could be misleading, BUT it’s too heavy and not robust. GridView support is not perfect. Now it looks nice to play but hard to use.

  12. Hi,

    I work on the AJAX Control Toolkit and I would like to respond to some of the comments/questions posted here.

    – Regarding the Toolkit in general: The Toolkit is a Community Project that allows participation by non-Microsoft employees. It still adheres to high quality standards. However, it aims to serving customer pain-points using an agile release process that allows it improve and evolve incrementally which means that it may not necessarily be feature complete at any time because it can always have more in the next release. The Toolkit is an experiment that Microsoft is trying out that provides a different delivery mechanism and development paradigm that encourages community involvement and fosters Toolkit adoption in an organic way. We are very strict about maintaining backward compatibility so although we release frequently we try our best to introduce breaking changes unless absolutely necessary which in most cases has been absent in most recent Toolkit releases.

    o The Toolkit CodePlex Wiki has more information:

    o Shawn’s blog post also details it:

    – VS Integration: The Toolkit offering provides templates to create extenders and Toolkit enabled websites. These templates are part of the standard Toolkit solution and available in both the Source and No-Source downloads. See this walkthrough:

    – Documentation: We document all public APIs on the sample website( that demonstrate basic control usage. We also have two test projects part of the Toolkit solution that exploit various different features of the Toolkit controls and they can be used as samples as well. The walkthroughs on the Sample Website also discuss further finer points. We agree that it is not the same as msdn but if you think it is missing specific information please let us know and we can try to fill the gaps. We do have a work item tracking requests for formal  Toolkit documentation:

    – Debugging: We have a walkthrough that discusses this. See client resource script attribute discussion here:  We also use Firebug which helps a lot in debugging javascript in the scope of the browser.

    – Integration with other frameworks and client-only: We do not have an end-to-end support story for this and do not plan to at this point in time unless we get sound community contributions. Most Toolkit controls can be declared as client-side behaviors however the declaration may be tedious. We recommend that you look at the spewed javascript declaration from a server control by “View Source” in the browser and use that to model your client-side declaration. Caveat: It is possible that this may not work for some behaviors. If you run into issues please report bugs:

    – DataGrid: It is a huge project by itself and it got stalled due to lack of support for client-side data-templates and data-binding. We are encouraging the community to participate and contribute. See this wiki:

    We very much appreciate your feedback and  look forward to more. You can contact me directly from my blog at, or send us an email at or post questions on the Toolkit forums at



Skip to main content