About two months ago, John Resig and I met at Café Algiers in Harvard square to discuss how Microsoft can contribute to the jQuery project. Today, Scott Guthrie announced in his second-day MIX keynote that Microsoft is throwing its weight behind jQuery and making it the primary way to develop client-side Ajax applications using Microsoft technologies.
What does this announcement mean?
It means that Microsoft is shifting its resources to invest in jQuery. Developers on the ASP.NET team are now working full-time to contribute features to the core jQuery library. Furthermore, we are working with other teams at Microsoft to ensure that our technologies work great with jQuery.
We are contributing to the open-source jQuery project in the exact same way that any other company or individual from the community can contribute to jQuery. We are writing proposals, submitting the proposals to the jQuery forums, and revising the proposals in response to community feedback. The jQuery team can decide to reject or accept any feature that we propose.
Any feature that Microsoft contributes to jQuery will be platform neutral. In other words, Microsoft contributions will benefit PHP and RAILS developers just as much as they benefit ASP.NET developers. Microsoft contributions to jQuery will improve the web for everyone.
Contributing Support for Templates to jQuery Core
Our first proposal concerns templating. We want to contribute support for templates to jQuery so that JavaScript developers can use jQuery to easily display a set of database records. You can read our templating proposal here:
You can download and play with our prototype for templating here:
The following code illustrates how you can use a template to display a set of products in a bulleted list:
<script type="text/javascript">
jQuery(function(){
var products = [
{ name: "Product 1", price: 12.99},
{ name: "Product 2", price: 9.99},
{ name: "Product 3", price: 35.59}
];
$("ul").append("#template", products);
});
</script>
<script id="template" type="text/html">
<li>{%= name %} - {%= price %}</li>
</script>
<ul></ul>
The template is contained in a SCRIPT element that has a TYPE=”text/html” attribute. Browsers ignore the contents of a SCRIPT element when they don’t understand the content type.
Notice that the placeholder {%=…%} is used within the template to indicate where the name and price of a product should appear. The delimiters {%=…%} are used for expressions and the delimiters {%…%} are used for code.
Finally, the products are rendered using the template with the call to $(“ul”).append(“#template”, products). The standard jQuery DOM manipulation methods have been modified to support templates. When the page above is rendered, you get the bulleted list displayed in the following figure.
Our goal is to keep our proposal for templates as simple as possible. After support for templating has been added to jQuery, plug-in authors can take advantage of templating when building complex data-driven plug-ins such as a DataGrid plug-in.
The Ajax Control Toolkit
Over 100,000 developers download the Ajax Control Toolkit every month. That’s a mind-boggling number of downloads. We realize that the Ajax Control Toolkit is extremely popular among ASP.NET Web Forms developers and we want to continue to invest in the Ajax Control Toolkit.
If you are adding JavaScript interactivity to an ASP.NET Web Forms application, and you don’t want to write JavaScript, then we recommend that you use the server controls in the Ajax Control Toolkit. Using the Ajax Control Toolkit does not require knowledge of JavaScript and the toolkit enables you to build applications with the concepts familiar to ASP.NET Web Forms applications developers.
If, however, you are interested in creating client-side interactivity without server controls then we recommend that you use jQuery.
We plan to continue to release new versions of the Ajax Control Toolkit every few months. Our goal is to continue to improve the quality of the Ajax Control Toolkit and to make it easier for the community to contribute code, bug fixes, and documentation.
The ASP.NET Ajax Library
We are moving the ASP.NET Ajax Library into the Ajax Control Toolkit. If you currently use ASP.NET Ajax Library client templates, client data-binding, or the client script loader then you can continue to use these features by downloading the Ajax Control Toolkit.
Be aware that our focus with the Ajax Control Toolkit is server-side Ajax. For client-side Ajax, we are shifting our focus to jQuery. For example, if you have been using ASP.NET Ajax Library client templates then we recommend that you shift to using jQuery instead.
Conclusion
Our plan is to focus on jQuery as the primary technology for building client-side Ajax applications moving forward. We want to adapt Microsoft technologies to work great with jQuery and we want to contribute features to jQuery that will make the web better for everyone. We are very excited to be working with the jQuery core team.
Hey great news, looking forward to the developments. Some feedback on the script tag usage combined with text/html.
Just because it’s ignored, doesn’t make it the best place to do it. Maybe from a performance point of view it’s better than an element with display: none? But I think we should ‘just’ put the HTML templates right there (in the UL in this case, and then the templating should replace it.
The script tag, I think ASP.NET Ajax has been there before the 1.0 release with XML script.
“Browsers ignore the contents of a SCRIPT element when they don’t understand the content type.”
Oh, and what about the templating that’s already in Microsoft Ajax library? It doesn’t use special syntax which according to Betrand was optimal for performance reasons. Will that templating be deprecated on arrival with this new proposal? If not, why this new proposal?
And lastly, what about jQuery UI? How does that and the Microsoft Ajax controls idea fit together?
Man, it sounds really great, but it’s also confusing, what’s happening to the exisiting MS javascript library?
@Mike — Great questions! The ASP.NET Ajax team has now acquired substantial experience with both approaches to templating: (1) Using a SCRIPT type="text/html" tag and (2) Using display:none with real DOM elements.
The ASP.NET Ajax Library followed approach (2). We discovered that we needed to write a lot of code to handle browser side effects. For example, if you use display:none and attempt to do IMG src="{%= imagePath %}" then a browser will attempt to actually load an image at the path {%= imagePath %} which is bad 🙂 There are lots of other side effects like this one that you need to write code to work around.
Because we want to follow the jQuery philosophy of keeping our templating code simple, we decided to go with option (1) for the jQuery templating proposal. As you point out, Microsoft followed this approach in the past with XML Script.
The current ASP.NET Ajax Library templates are being moved into the Ajax Control Toolkit. Our recommendation moving forward is to use jQuery for client-side Ajax. However, we are not removing anything.
Hope this helps!
— Stephen
It is interesting how companies can do 180 degree turns all in the name of profit.
This is just Great news! I just want to thank Microsoft so much for doing this! What is just as welcoming is that you keep AjaxControlToolkit and move existing Asp.net Ajax lib to it. I think that WebForm + AjaxControlToolkit + UpdatePanel type of development definitely has its place. Not every site needs to be like Facebook or Twitter where you have so many visitors that efficiency counts so much. A lot of sites may only serve a small amount of users, but time to market or development time are just as important. I’m currently developing a site where the public facing portion we use Asp.net MVC and jQuery, we want it to be as pure and as efficient as possible. And, the Admin Console of the site is done in Asp.net WebForm and AjaxControlToolkit and UpdatePanels, because there are only a limited number of administrators that need to access this portion of the site.
What will happen to components like DataContext/adoNetDataContext? Will they become jQuery plugins or are they considered server-side ajax (ACT)?
@Maro – Great question. Short term, you can continue to use the DataContext/OpenDataContext from the Ajax Control Toolkit. Long term, we plan to create jQuery plug-ins that provide similiar functionality.
Hope this helps!
— Stephen
Hi Stephen,
I think that this is a great decision and as I just wrote in my pingback (softwarearchitectblog.wordpress.com/…/microso…), I absolutely support this switch, although I put some effort into learning the nuts and bolts of the ASP.NET Ajax Library. I like the new spirit that found its way into the ASP.NET Team since MVC started out and I want you to know that you have a lot of support in the enterprise sector as well. WebForms have its place and I would even suggest to invest some more time to improve it, but ASP.NET MVC and “real” Ajax applications are definitely the future.
As you know, I support this move overall but there is one thing that I’m sure is a mistake. You need to HTML-encode by default and make it opt-out. That I’m 100% positively sure of.
Overall, I hope the invaluable and unparalleled experience the Ajax team has acquired over the last two years is applied to this.
For example, before I look into the implementation, can you tell me whether it uses the DOM reconstruction through code generation approach that was used in the Ajax library? That had the nice benefit that encoding explicitly was not needed.
Great step in the right direction Microsoft! Can’t wait for the jQuery OData plugin..
What about our investements in MS Ajax Library? It wasn’t easy to learn all its conventions 🙂
The end of MS Ajax Library resembles the case of LINQ TO SQL, except that I dont regret about learning and using L2S, it is great product.
It is great that MS is moving asp.net ajax -> jquery. Also great to see quality templating added to jquery. The existing template plugins are terrible.
It doesn’t mean that I dont like jquery.
I just a bit worried about the ability of ASP.NET team to choose the right strategy. Why did you start developing your own js library in the first place when jquery was the leader?
Why SqlDataSource and its buddies when every child knows that sql on a page is a bad bad practice? What with peb parts frozen with their bugs? Application services?
Have you ever tried to build big, complex, long lasting applications and to use all those techs that you are constanly bringing to the ASP.NET?
Stop poisoning ASP.NET.
You guys should fire the team’s chief strategist and planner.
I do like jQuery! But I DON’T like ASP.NET team lead and PM! They are mad and haven’t got any strategy!
Stop poisoning ASP.NET. UpdatePanel SUCKS, WebParts SUCKS, SqlDataSource SUCKS! Continue?
Fire the team’s strategist and PM!!!
What is the reason to abandon {{ name }}, instead to use {%= name %}?
This has been bothering me for a while. I kind of have to agree with @Grrr here. Microsoft is not developing a great track record in regards to sticking with its own technologies.
Code Access Security – Dead at V2
Linq to Sql – Dead at V1, but we already know the miserable track record with data access (DAO/ODBC/ADO/ADO.NET/L2S/EF), if I chose NHibernate 4 years ago I’d be much better off
ASP.NET AJAX – Dead, I mean “Server-Side Client-Side Technology (?!)”, just say “deprecated/not supported”
Workflow Foundation – Dead at V2 but “resurrected” as V4
WinForms – Dead at V2, use WPF
This is pretty much why I have ignored WPF until recently — anytime Microsoft introduces something, I have to give it the 3 years test (aka “wait till the next VS release”) before investing effort. That they’re using it in Visual Studio 2010 (and, coincidentally, the astigmatism blurry text problem magically gets fixed) tells me that It Might Make It.
This is not why I pay for Microsoft tools.
I understand that this is a fast-moving industry. But a go-live license is no longer good enough. MS licenses need to start coming with continued-development commitments, “not removing it” is not good enough, otherwise it really is no better than open source, where at least *I* can attempt a judgment call based on the health of the community and the robustness of the code.
Just pick something and stick with it already.
@yysun — That is the current syntax in the templating proposal. However, nothing is written in stone yet. If you have a recommendation for a better syntax then I suggest that you post your feedback to the jQuery forums: forum.jquery.com/topic/jquery-templates-proposal
This is a giant shift for sure. The other day, I came across the book “ASP.NET Ajax in Action” that exposes, among other things, the core of the ASP.NET Ajax Libray. I though to myself that it might be valuable if I were able to use it in addition to jQuery.
Regarding to the new strategy exposed here, I think that standing by is the best option for now. What I fear about is the paint we might encounter to adapt our current applications to use the new stuff onward. Please, spend as much time as you develop to propose a way to adapt easily our application. We spent (too much) time trying to follow you guys 😉
A few days ago, I read the road map for MVC 3. We could reasonably expect to have something to play with around 2011. The core Ajax.dll and Ajax.mvc.dll will probably be updated. Make the transition as smooth as possible please.
I applause you guys, but pay attention to the pain that WE developers encounter to embrace your new huge transition hardly every years.
Regards Stephen,
Roland
This seems great, hope microsoft will help for completing your project. All the best and Thanks
The templating proposal seems simlar to the JTemplates
http://jtemplates.tpython.com/
So I spent quite a bit of time with the Ajax 4.0 libraries, the client templates and especially the two-way databinding, observable array features.
What’s my strategy now? When should I expect this functionality to appear in a new form? Is the functionality as it current stands in Ajax 4.0 beta not going to be taken any further?
Personally I was really impressed with the 4.0 feature set in the client libraries and after switching almost solely to jQuery I really started to seriously look at and use the new Microsoft ajax features again so I’m a little disapointed to see this anouncement and can only hope we see the functionality in a new form as soon as possible.
@Stephen.Walther, thanks for answering my question. Here is another one.
You can change the ASP.NET Ajax Library client templates to use script type="text/javascript", why it has to start from scratch and become a jQuery plug-in?