My Feedback: ASP.NET AJAX Roadmap

Dave Ward had another great post this past week.  He took the time to not only read the ASP.NET Ajax Road Map document, but he also wrote up a post outlining what he thought about it.  So I thought I would join Dave's efforts and throw in my 2 cents as well.  Of course, most of this post will not make too much sense if you aren't familiar with the Road Map document.  So if that's you, here is what I recommend reading (in order) ...

 

My Comments ...

My goal is to be direct without being rude, lets see if I can do it. 

 

$query

  • Any plans on providing an extensible selector engine?  If you have to go through all of the work to implement CSS 2.1 and 3.0, it would be cool to let developers hook into this engine and extend it.
  • Do you have any idea on what operations will be available on the collection returned from $query?  From the example provided, I can see addHandler, setStyle and create will be there, but I would really love to what else is available.  Also …
    • I would like to see helper functions for each events.  I find it more readable to replace addHandler with $query(‘input’).click(function(){ //do something });  I know this might seem nitpicky, but I think it is this type of thing that makes the jQuery API so easy to work with.
       1: //    I like this ...
       2: $query('input').click(function(){ 
       3:     // do something
       4: });
       5:  
       6: //    better than this
       7: $query('input').addHandler('click', function(){
       8:     // do something
       9: });
    • I like the terseness of the jQuery API.  You don’t see stuff like setStyle().  It would just be style() and all of the following would be possible.  Again, probably trivial, but IMO the stuff that keeps the JS files nice and small and the API a breeze to work with
         1: //     get the width of the first matched input element
         2: var width = $query('input').style('width');
         3:  
         4: //     set the width to zero
         5: $query('input').style('width', 0);               
         6:  
         7: //     set the width and height
         8: $query('input').style({width:0, height:0});
         9:  
        10: //     set  the width and height
        11: $query('input').width(0).height(0);

 

$listen

  • Can we get the same stuff for attaching behaviors to elements?  For example, any TEXTAREA that gets added to the DOM with a class of ‘rich’ should always get the RichTextBox behavior applied to it.  Or do I have to manage this stuff myself?  I would like to attach these behaviors the first time the page loads on the client and then not have to worry about it again.
  • I like how there is a single entry point to the jQuery features -> $.  Any chance $listen could hang off of the wrapped set?  So I could do something like this …
       1: //    again, I would prefer this
       2: $query('input').listen('hover', function(){ 
       3:     // do something 
       4: });
       5:  
       6: //    over this
       7: $listen('hover', 'input', function(){
       8:     //    do something
       9: });
  • Is the parameter order for $listen correct?  Seems like $listen(query, event, fx) would be more consistent

 

Templates and Client Data Sources

  • The templates look interesting.  And the complex template example really does look complex ;)  But I found it hard to provide any real meaningful feedback here because of the complexity of the features.  This stuff seems really promising, any idea when we would be able to see examples of how a sample GridView/ListView could be replaced with a client side template/data source (sorting, paging, editing, etc...).   
  • Will client side templates be able to fire server side events?  Could an input button contained in a client side template trigger a server side event handler?
  • Will the 2 way databinding require the bound JS objects to implement the INotifyPropertyChanged stuff? 

 

Animation

  • Will we have access to the animation queue?
  • This still seems too verbose ....
       1: // isn't this better ...
       2: $query('.sprite')
       3:     .fadeIn(300)
       4:     .animate({backgroundColor:'ff0000', fontSize:'2em'}, 500)
       5:     .fadeOut(300);
       6:  
       7: // than this?
       8: $query('.sprite')
       9:     .animate([ 
      10:         new Sys.Animation.FadeIn(300), 
      11:         {'style.backgroundColor':'#ff0000', 'style.fontSize':'2em'), duration: 500 }, 
      12:         new Sys.Animation.FadeOut(300) 
      13:     ]));

 

Other Stuff …

  • In my opinion, the thing jQuery has over ASP.NET AJAX and the Toolkit is its programming model.  It so simple that newcomers can get up and running and author there first plug-ins in nearly no time.  But, the interfaces provide the ultimate in flexibility (hooks for extending the selection engine, access to the animation queue, etc...) for the more experienced developers.  It truly is elegant, simple AND powerful.  Now compare this to the tutorial for creating an ASP.NET AJAX extender control.  This tutorial has me writing server side code, a JavaScript behavior that is nearly 100 LOC, plus all of the plumbing that glues the two together.  That's just too complex ...
  • I think the TargetControlID could use some rethinking.  Again, the extender control tutorial provides a sample for adding highlighting to a control that has focus.  Here is how you can tie the behavior to the TextBox ...

       1: <asp:TextBox ID="TextBox1" runat="server" />
       2: <sample:FocusBehavior runat="server"
       3:     ID="FocusBehavior1" 
       4:     HighlightCssClass="MyHighLight"
       5:     NoHighlightCssClass="MyLowLight"
       6:     TargetControlID="TextBox1" />

I know I can now access the HighlighCssClass and NoHighlightCssClass properties from the codebehind, but this just isn't something I find myself doing very often.  Plus, I often wanted to apply an extender to multiple elements.  Imagine a form where I have 7 textboxes and I want every one to get this highlighting.  Binding the extender control to a class or tag based selector would have been useful.  I would have traded the server side access for that without giving it a second thought.

Also, I prefer to use the DataControlFields of the GridView and DetailsViews.  It would be pretty cool if I could have attached the extender controls to these fields too ...  Seems like class/tag based selection would help here too.

  • I really think the ASP.NET AJAX needs a plug-in programming model.  A good part of the JavaScript code I write does not require a full blown Sys.UI.Behavior.  I just want to run a bit of code when some DOM event occurs.  
    • I know this is just meant as an example, but a good illustration of this is the FocusBehavior you can find in the asp.net ajax documentation.  Here is the source for this behavior ...
         1: // Register the namespace for the control.
         2: Type.registerNamespace('Samples');
         3:  
         4: //
         5: // Define the behavior properties.
         6: //
         7: Samples.FocusBehavior = function(element) { 
         8:     Samples.FocusBehavior.initializeBase(this, [element]);
         9:  
        10:     this._highlightCssClass = null;
        11:     this._nohighlightCssClass = null;
        12: }
        13:  
        14: //
        15: // Create the prototype for the behavior.
        16: //
        17:  
        18: Samples.FocusBehavior.prototype = {
        19:  
        20:     initialize : function() {
        21:         Samples.FocusBehavior.callBaseMethod(this, 'initialize');
        22:         
        23:         $addHandlers(this.get_element(), 
        24:                      { 'focus' : this._onFocus,
        25:                        'blur' : this._onBlur },
        26:                      this);
        27:         
        28:         this.get_element().className = this._nohighlightCssClass;
        29:     },
        30:     
        31:     dispose : function() {
        32:         $clearHandlers(this.get_element());
        33:         
        34:         Samples.FocusBehavior.callBaseMethod(this, 'dispose');
        35:     },
        36:  
        37:     //
        38:     // Event delegates
        39:     //
        40:     
        41:     _onFocus : function(e) {
        42:         if (this.get_element() && !this.get_element().disabled) {
        43:             this.get_element().className = this._highlightCssClass;          
        44:         }
        45:     },
        46:     
        47:     _onBlur : function(e) {
        48:         if (this.get_element() && !this.get_element().disabled) {
        49:             this.get_element().className = this._nohighlightCssClass;          
        50:         }
        51:     },
        52:  
        53:  
        54:     //
        55:     // Behavior properties
        56:     //
        57:     
        58:     get_highlightCssClass : function() {
        59:         return this._highlightCssClass;
        60:     },
        61:  
        62:     set_highlightCssClass : function(value) {
        63:         if (this._highlightCssClass !== value) {
        64:             this._highlightCssClass = value;
        65:             this.raisePropertyChanged('highlightCssClass');
        66:         }
        67:     },
        68:     
        69:     get_nohighlightCssClass : function() {
        70:         return this._nohighlightCssClass;
        71:     },
        72:  
        73:     set_nohighlightCssClass : function(value) {
        74:         if (this._nohighlightCssClass !== value) {
        75:             this._nohighlightCssClass = value;
        76:             this.raisePropertyChanged('nohighlightCssClass');
        77:         }
        78:     }
        79: }
        80:  
        81: // Optional descriptor for JSON serialization.
        82: Samples.FocusBehavior.descriptor = {
        83:     properties: [   {name: 'highlightCssClass', type: String},
        84:                     {name: 'nohighlightCssClass', type: String} ]
        85: }
        86:  
        87: // Register the class as a type that inherits from Sys.UI.Control.
        88: Samples.FocusBehavior.registerClass('Samples.FocusBehavior', Sys.UI.Behavior);
        89:  
        90: if (typeof(Sys) !== 'undefined') Sys.Application.notifyScriptLoaded();

          And the same functionality can easily be written as a jQuery plug-in in a fraction of the lines.

         1: (function($) {
         2:   $.fn.focus = function(options) {
         3:     // build main options before element iteration
         4:     var opts = $.extend({}, $.fn.focus.defaults, options);
         5:     
         6:     return this.each(function() {
         7:         
         8:         //    add/remove the class as the element comes into and out of focus
         9:         $(this).focus(function(){
        10:             if(!this.disabled){
        11:                 $(this).addClass(opts.highlight);
        12:             }
        13:         }).blur(function(){
        14:             if(!this.disabled){
        15:                 $(this).removeClass(opts.highlight);
        16:             }        
        17:         });
        18:     });
        19:   };
        20:  
        21:   $.fn.focus.defaults = {
        22:     highlight: 'highlight'
        23:   };
        24:  
        25: })(jQuery);

The example above really just ties a very small bit of JavaScript to a couple of event handlers.  It would be great to have plug-in plumbing in the next rev to make doing stuff like this easier.

  • On sort of a related note, I think the existing existing ASP.NET AJAX and Toolkit components are too verbose and too OO (yes it feels weird saying that).  Some of the things that bother me are ...
    • The uber long namespaces.  Stuff like Sys.UI.DomElement.containsCssClass is just too long.  Is requiring so many namespaces to organize the library a sign that it has become too large?
    • Having multiple entry points.  I like how everything in jQuery starts with $().  Its simple.
    • All of the code required for the property getters and setters.  Where am I seeing the value from calling raisePropertyChanged?

And I just have to wonder if having such a rigid and verbose programming model is the right choice for a client side AJAX library.

  • I don’t want to pay for features I don’t plan on using
    • I have never use the RoundedCorners and DropShadow features of the ModalPopup control, but there is no way (that I know of) for me not to pull these scripts down to the client.  I like how jQuery is progressive.  If the metadata plug-in is available, it will go ahead and use it.  But if you decide not to pull it down, nothing will break and the widget/plugin is still usable.  And for animations, just the real low-level plumbing and most often used parts of animation components are bundled in with jQuery's core.  If you choose to animate colors, you can add the color animation extensions.
    • I like how jQuery doesn't pull down any extensions to the String/Number/Date prototypes. 
  • The Toolkit got stale.  It seemed like developing new controls was too difficult for the community to do, but the ASP.NET team was moving on to other things (possibly ASP.NET MVC and Silverlight?).  So it seemed like nothing was really happening.  jQuery plug-ins on the other hand are spreading like wildfire.  They are simple to write AND distribute (its just a text file).  The toolkit is the opposite.  The controls are challenging to write and you end up distributing a DLL which may or may not correspond to the version of .Net the consumer is running with in production (I know that first hand because I received plenty of emails about people wanting to use the 3.5 version of the toolkit control with .Net 2.0).   
  • I am curious if the ASP.NET AJAX team has written an application using jQuery.  And I do not mean this as an insult or anything, I am really serious.  In my mind that is the bar ASP.NET AJAX vNext needs to get to.  I have no idea when ASP.NET AJAX vNext is coming out, but from now until then I am using jQuery.  And it will be tough to persuade me to go back to ASP.NET AJAX if it is missing some of the stuff I mentioned here. 

 

Conclusion

Well, I tried to be blunt without being rude - I truly hope that I succeeded.  I hope I don't come off as angry or anything, I just have spent a lot of time with ASP.NET AJAX and the Toolkit and think that these are the things that I would want changed for vNext.  And just like Dave said, I am not an MVP, or an Insider, I am just a regular dev that really wants Microsoft to nail the next version of ASP.NET AJAX.  Good luck guys!

That's it.  Enjoy!


TrackBack

TrackBack URL for this entry:
http://mattberseth.com/blog-mt/mt-tb.fcgi/139

Listed below are links to weblogs that reference My Feedback: ASP.NET AJAX Roadmap:

» Matt'sFeedback on ASP.NET AJAX Roadmap from DotNetKicks.com
You've been kicked (a good thing) - Trackback from DotNetKicks.com [Read More]

Comments


You make some very strong points. Even the little things count, like style() instead of setStyle(). Who wants to capitalize that freakin "S"?!

Im starting to love jQuery because it has an evident goal of keeping your code as concise as possible. In fact, Ive already caught myself refactoring my jQuery code two or three times and significantly reducing the overall size and efficiency each time, while still keeping it understandable. Its amazing, really.

And it doesnt require 4 script tags pointed to a WebResource.axd handler. I hope Microsoft can come out with a totally revamped toolkit, although its gonna be difficult to beat jQuery. This code runs on the users machine; exercise responsibility, less is more.

Good post, Matt.

You essentially wrote that ASP.NET AJAX isnt enough like jQuery, but I agree. ASP.NET AJAX is too complex and I dont see how the complexity can be removed if backwards compatibility is maintained.

Fantastic feedback Matt. Im in complete agreement.

Ive worked the asp.net ajax and created some toolkit items. Later on I started into jQuery (for asp.net mvc).

I also like the terseness of jQuery :)

Thanks again - and nice feedback, I hope some MS guys read it and not get defensive about it, but really take it in.

Actually, I think if they were forced to use nothing but jQuery for 3-6 months then go back to their library, theyd glean much from it :)

Posted by: Deepak Chawla on July 18, 2008 12:00 AM

My biggest problem with all these is one.

In order to create a user friendly web page with loads of new elements and methods and functions.

1) You cant create many objects at client end. Browser runs out of memory.
2) The integration of creating controls in ASP.NET with Ajax is only for demo purposes. It only works if you have very few controls. I create a control which had around 10 text boxes in a Ajax tab and all the textboxes having mask edit control.
Create 4-5 controls on a page you are fine( This is what I call book example) In real life when you create 50 -100 such controls you get memory out/ Slow page load/ script needs running messaging alert.

Matt, You can try this by the examples you post on your blog. All work well in demo create 5000 of them and see the fun.


Thank God, I went for create your own elements via string and then add to innerHTML and join the objects to the controls as needed.

Id personally question the design of a single page with 50-100 textboxes on it... :)

As with any framework/library, etc... they can be abused. Its expected that the developer take these items into consideration when they use a framework.

@Josh -
Thanks Josh. And I agree on both points: it is almost impossible to write jQuery code that isnt readable and I would love to see a revamped toolkit.

@Dan Goldstein -
Thats a perfect summary: ASP.NET AJAX is not enough like jQuery. And from the road map document it looks like MSFT is trying to close the gap. I just want to make sure I stressed that its not just the features that make jQuery so easy to learn and work with, but it is also the small things like having a single entry-point, keeping the function names terse (css instead of setCss), having plug-in model, etc ...

@Steve Gentile -
I am hoping the same thing, because its not like my company hasnt got a ton of mileage out of the existing ASP.NET AJAX and Toolkit components. I just wanted to make sure when the jQuery features are rolled into ASP.NET AJAX vNext the team understands why jQuery is so popular.

It would be an interesting exercise to build the existing toolkit controls as jQuery plug-ins and widgets. I know it would be tough to get exact feature parity, but I think you would learn a lot about what the relative trade-offs are between the frameworks.

Really good points.

It can be kind of hard, at least for me, to quantify just what it is that makes jQuery so compelling. But I think youve done a great job of highlighting some of the aspects of jQuery that attract so many of us (javascript newbies and other-framework converts alike).

Perhaps MSFT can address those points. But rather than seeing MSFT continue to pour resources into ASP.NET AJAX, I think Id rather see them focus on improvements to the support for 3rd party javascript libraries, with truly seamless javascript intellisense and javascript code-collapse in VS.NET, for starters.

Its hard to imagine how ASP.NET AJAX can be migrated towards a more jQuery-like library without either forgoing all backwards compatibility or growing even larger. So perhaps instead, MSFT can produce a new set of very small javascript utility libraries that enable users of other javascript libraries (jQuery, Moo Tools, Prototype, etc.) to more easily integrate with the ASP.NET server-control model or ASP.NET MVC. Not a whole client-side programming model; just some glue that makes things easier without adding kilobytes of overhead to the rendered page.

Maybe, in the long run, that approach would serve MSFT better than any attempt to lure developers away from their favorite 3rd party javascript libraries.

Matt,

This reminds me very much of MFC vs ATL vs WTL story. M$ made MFC. It was BAD. Then ATL poped up. It was better. And then WTL, which is/was much like jQuery: simple, powerfull, using the prog. language in a best way. The outcome: MFC ... M$ absorbed ATL into MFC. ATL team was dispersed, and WTL has been pushed into the wild (aka SourceForge ), today without no M$ backing whatosever.

Further, if I may?

0. Can one actually compare jQuery and AJAX.NET ?
1. if ( 0 == true } {jQuery is better (easier etc.) than AJAX.NET }
2. If (1 == true) { alert("Why using AJAX.NET?") ;

Starting a new web app project today, I would certainly go the jQuery, way ..

For M$ there is an commercial reality. AJAX.NET is not free product. Even if they would want to base future versions on jQuery, and adopt it 100%, they can not do that because jQuery is moveable target: it is free and open source, and thus uncontrollable.

M$ in this situation usually buys the troublemakers, and slowly digests them into the "collective". Much like Borg do.

Although there are few famous indivuduals who resisted the "Borg" (example: Bjarne Stroustrup)) They are very famous indeed and not rich at all. If that matters.

I am affraid that Mr Ressing, will have very tough decision to make very soon: money or fame?

Regards: Dusan

@Dusan:

I dont think theres any reasonable chance that Microsoft would try to "buy" John or jQuery. Johns already set up at Mozilla, working on jQuery, FireFox, and now FireBug.

More importantly, its not feasible to buy or control something like jQuery, where the source cannot be controlled.

Aside, I think Microsoft has demonstrated its willingness to work with open source instead of against it. Between CodePlex and their handling of Rob and Phils products, I dont think were dealing with that Microsoft of the 90s anymore.

Posted by: redsquare on July 19, 2008 12:00 AM

Nice summary, even if they included all you ask I bet you will not turn your back on jQuery, jq will always be 5 steps ahead even if MS ploughed phil haacked and hansleman onto the project. I wish they would just embrace and use jQuery instead of trying to copy it, why re-invent the wheel just seems such a waste of time and effort, must be deflating coming into work to try and replicate jQuery but know your not going to do it as well!

Matt this is excellent feedback. I admire people like you who are willing to use their time to sit down and write such a post.

A bit unrelated but I am surprised that you are not an MVP considering how much you have contributed to the ASP.NET community

keep up the good work
Dejan

Posted by: Robert on July 19, 2008 12:00 AM

Totally agree too. In the past ive always seen colleagues want to pack in the latest goodies from MS into their applications, whereas before moving to .NET/C# i come from a php environment (tho id hate to go back!) and am more adept to the KISS principle.

Also i often work with web designers that are great when working with standard html components, but things get tricky when adding stuff like

Personally i like pure html in my pages when possible (which it is, 99% of the time). If you need a button, image or whatever to be server side, just do

jQuery really fits in there perfectly. Small, concise, and extensible! Now my web projects are mainly plain html/css on the client, and pure c# code on the server side, with a few html elements (not

ASP.NET Ajax has great potential, but for the next year of so (aside for fast thrown together intranet backoffices), i will only be using the [scriptservice] and serialization options it offers ..because for now i find it way too bloated and complicated, which is unfortunate because the potential is there, and it is always better to have tools integrated with the framework, than having to rely on third party code [ajax.pro, jayrock, trimpath, prototype, etc ..goodness anyone?:)].-
Robert

Posted by: Igor Loginov on July 19, 2008 12:00 AM

Matt, Dave (as soon as the discussion from encosia moved to this blog),

The major advantage of jQuery for me that this is a new PARADIGM in javascript programming. And very attractive one: intuitive CSS-like DOM selectors, convenient terseness, clear visibility of variables to solve binding problem, excellent readability of code.

So, when I looked at MS Ajax roadmap, I clearly understood, that Bertrand and his team decided just "mimic" jQuery, but keep the whole approach unchanged (ViewState overhead will never die!).

IMHO, what MS Ajax really lacks of, is the own CONCEPT, which is equal to own image. Probably, this is an implicit message of all the "last mile" developers in blogs above.

What do you think?

@Igor -I agree. The jQuery style of JavaScript programming is becoming so popular that I would be surprised if it doesnt become the defacto standard.I dont really have a problem with MSFT mimicing jQuery and rolling that into vNext. But I think it would be if MSFT seperated their client side application framework (all of the Sys.WhatEver stuff) from the more general purpose DOM selection/modification stuff. So if MSFT happens to build a better jQuery (ala $query) then I will use that. But if it isnt exactly what I am looking for, or if I have other jQuery plug-ins that I use I can just keep using jQuery. But the last thing I would want is for $query in vNext to not meet my needs but because it is so ingrained with the rest of the client side framework that I have no other option.I hope ViewState doesnt ever die. Because if it does, I am screwed ;). But I dont see how ViewState is linked to the ASP.NET Ajax futures discussion? If you arent a ViewState fan, MVC is available. Would you mind expanding on this?

Sorry Igor, I dont understand your last point. Would you mind rephrasing it?

BTW great comments!

Posted by: Igor Loginov on July 19, 2008 12:00 AM

Matt,

Thanks for sharing your opinion.

Sorry, I was not clear with some of my points.
- ViewState: Youre right, it is not linked to the topic directly. I mentioned ViewState just because the majority of MS Ajax problems relate to it. (Also, it was my biggest surprise when I tried UpdatePanel for the first time. I expected to see only delta in data roundtrip.)
- Saying the last phrase in other words, I expected something bigger from world leading company. Now we cannot say "JavaScript framework from Microsoft" :(

Thanks for the feedback. We *are* listening. :)

@redsquare -
Hmm ... I dont know though. If vNext ASP.NET AJAX has the jQuery stuff (DOM selectors, DOM manipualtion, plug-ins, etc...) plus it understands how to work with ASP.NET WebForms/MVC it might be really hard to not convert.

@Dejan -
Thanks Dejan.

@Bertrand Le Roy -
Awesome.

Posted by: John (jonx) on July 26, 2008 04:33 PM

Thank you Matt for taking the time to share you own experience likethat even if you are going to use only jQuery from now :(

I already said it on that blog but I prefer a full MS solution when I develop something as most of the time I cannot depend on third party solutions. On one side it is very nice to see jQuery evolve that fast but I think this is also its biggest drawback... I cannot depend from something that evolves that fast. This is too fast for me. On the other side MS Ajax, doesn't evolve at all (nearly). This is good but also again, not that good... It should evolve faster. Like you said the team probably got stuck into newer other things... I do not expect from MS that they develop all and every possible AJAX component, for that you have third party developpers but I would like to see much more articles and documentation that exhibit real life situations or full samples (a whole web site) not just very small part that I get a hard time to make stick together.

I learned more from your blog about ajax toolkit in only a couple of weeks than in the last two years with what can be found on the web.

You demonstrated that it was possible to do with ms ajax anything that can be done with the other libraries, only it's more complicated... or more verbose.

By the way Matt, have you seen that ASP.NET AJAX 4.0 CodePlex Preview 1 went live? Obviously they may not have been able to take your points into account ;)

One last note for the MS guys reading this. Maybe my english is too bad but your document is not what I call a roadmap. A roadmap has release dates. This is more a peak preview on the possible featuers included (or not) in the next version of MS AJAX.

Also last, Matt, an easy way for MS to help you return to MS AJAX, would be to hire you ;)

Any open position in you team Bertrand?

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Consulting Services

Yep - I also offer consulting services. And heck, I'll do just about anything. If you enjoy my blog just drop me an email describing the work you need done.

Recent Comments

  • John (jonx) wrote: Thank you Matt for taking the time to share you own experience likethat even if you are going to use...
  • Bertrand Le Roy wrote: Thanks for the feedback. We *are* listening. :) ...
  • Matt Berseth wrote: @redsquare - Hmm ... I dont know though. If vNext ASP.NET AJAX has the jQuery stuff (DOM selectors...
  • redsquare wrote: Nice summary, even if they included all you ask I bet you will not turn your back on jQuery, jq will...
  • Dejan wrote: Matt this is excellent feedback. I admire people like you who are willing to use their time to sit d...
  • Robert wrote: Totally agree too. In the past ive always seen colleagues want to pack in the latest goodies from MS...
  • Igor Loginov wrote: Matt, Dave (as soon as the discussion from encosia moved to this blog), The major advantage of jQue...
  • Matt Berseth wrote: @Igor -I agree. The jQuery style of JavaScript programming is becoming so popular that I would be s...