Hi all,

We just published our roadmap for ASP.NET Ajax.

It's great to see that there's the plan moving forward is open for discussion. The Futures library has some great stuff, but there hasn't been much mention of when or how that functionality will be transitioned into the framework. Here are the things I'd love to see:

• DOM API Improvements
• Animations
• Drag & Drop
• High Level Controls - Async validator, upload, layout, and rich text box

Thanks for listening!

The JavaScript improvement and DOM API sounds great. Not sure about ClientDataSource. Validators, GridView, TreeView, great.

But, Do you guys have a plan to improve the performance of the UpdatePanel? My opinion, improving the UpdatePanel is more important than anything else.

Another thing, the ClientID hell. Everytime, when I want to reference a control at the Client side, I have to use something like <%= Control.ClientID %>, it really sucks. Is it possible to reference the control without clientID within JavaScript? This is especially important when you put your JavaScript into a separate js file as you cann't use ClientID any more.

Can we have a decent Navigation Menu control as well?

@harveyliu168: it would be interesting to see in what scenario you're seeing bad UpdatePanel performance. Feel free to contact me at bleroy at microsoft. ClientID hell is something we're also working on. We also realize the markup for some controls such as Menu is not aligned with today's good web practices and there is a wider work item to have more CSS-friendly controls.

I kind-of agree with the client id problem but in a different way - the rendered IDs are WAY too long and increase the filesize of my page too much.  :) 

But my real beef is that I'd like to see the file size of the rendered JavaScript squeezed down a lot too.  The real purpose of AJAX is to speed up rendering and page response times and if the JS files are too big it hurts performance. I know you have to make it easy to use for most developers to code with but think of all those poor users on dial-up yet.  And even if the user is on a fast connection - the smaller the files the faster the rendering - the better the user experience - the happier the customers - the more we developers get paid!  So you can shorten variable names, minify the JavaScript, use JSON as much as possible for transfer, etc.

Thanks for the great product!  You've made my life a LOT easier.  The TOOLKIT ROCKS!

Very nice. The roadmap sounds great to me. Things I read that I really liked and would like to see come to fruition (in no particular order):

• "asynchronous custom validator that enables client-side code to validate fields against a custom server rule"
• "bidirectional, live bindings that are declared with a syntax that is reminiscent of WPF bindings"
• Drag & Drop
• improved JS intellisense

 Most of all, I'd like to see the stuff work cross-browser. IE, FireFox, and yes even Safari. If the stuff doesn't work in all browser's no matter how good it is, I simply can't use it.

 Keep up the great work!

-Brent

It's great that you guys posted this...

Here are some things I'd like to see:

1. Drag & Drop
2. Much improved Intellisense
3. Some sort of jslint like tool that validates js files.  This is a must if you have Minify.  Right now I'm using a codeproject JSLintVS visual studio add-in. (http://jslint.com/, http://www.codeproject.com/KB/macros/JSLintVS.aspx)
4. Making the control toolkit more usable on the client would be great also.  Most of our UI is dynamically created on the client.

Thanks for listening!

 MS getting into the Controls space is a very good move. Will benefit us developers a lot as Control  vendors will come out with new and innovative controls to stay competitive.

That was some interesting reading; thanks for posting it.

We have a very mature web app where we've already rolled our own CSS-friendly controls, auto minify/validation/merge on all JS and CSS, etc. We also subscribe to multiple third party control libraries, and those guys will always be years ahead of you if you do decide to write your own higher-level controls (like TreeView). For us, then, a great deal of your proposals wouldn't really help. (But I can see how they'd be very nice for most developers who are just starting out on an application.)

Here are the priorities as they would fit us best:

1. JavaScript intellisense improvements (it is 99% unusable in it's current form -- VS08 SP0)
   
2. DOM improvements -- specifically, the $query and $listen features looked great -- assuming you can get them to work in all browsers (yes, even IE6)
3. Drag and drop
4. Animation

I'm ambivalent about the client-side databinding. In it's present form, it still looks too complicated to really be useful. I prefer a more procedural approach to UI generation on the client: when the data comes in, do some direct work to utilize it -- don't rely on indirect bindings, event handlers, and other "magic" to get it done. In that vein, improvements to the DOM ($query) are by far the most important thing to improve that scenario.

I'd also like to echo what others have said, and mention that the top priorities are always performance, script size, and cross-browser support. If something can't be done within those constraints, it shouldn't be done at all. Finally, the ClientID "hell" would be a great thing to solve in some way.

@Dirq: The work on IDs will also help reducing their size. Also, the release version of our scripts is already minified, aggressively cached and gzipped. New features will be in new files so that you can not use them if you don't need them. Of course, you can use script combining (a 3.5 SP1 feature) to reduce the number of script files downloaded.

@Brent: The supported browsers are IE (from 6), Firefox, Safari and Opera. All new features work on all those browsers.

Thanks all for your support

The new $query stuff looks promosing but is still not going to work for me in every scenario.  What i really need is something like $find for the toolkit extenders but that will work within a repeater.  The templating and the animation stuff also looks good, but i'm sure i share this with everyone in that improving the performance is the most important.  Especially when jquery is so lightweight and alot of the new features look to be making jquery redundant for us asp.net developers (which is a good thing because 2 javascript libraries is too many).

Hi, Bertrand.

The roadmap looks fantastic. Great job!

I would definitely vote for the data-related items (Grid, DataView, DataSource) as well as the Validators. I would love to see "an easy pattern for creating reusable pieces of UI", and a good progress bar. As for a file upload without full page postback and with progress monitoring...well...read on...

I have been fighting for a week to develop a reusable partial-postback file upload control. I am using methodology commonly found on the internet, that of an aspx page inside an iframe. But you try putting that inside an ascx user control and then placing it more than once on an aspx Page and you will be tearing your hair out :). About the closest I have come to "reusable" is to put most of the server code in a Master Page and the client code in individual stateless external functions. A real nightmare. If you guys solve this, you'll be miracle workers!

I, too, would love to see a cleaner way to deal with the messy ID references. That's another issue I haven't solved yet in my upload control. I have code like this:

  uploadIFrame = $get('<%= uploadIFrame.ClientID %>');
  uploadDocument = uploadIFrame.contentWindow.document;

and it works fine until you try to reference something like this:

   $get('<%= fileUploadForm.ClientID %>', uploadDocument).submit();

 which fails because fileUploadForm does not exist in the current context, but requires ClientId because Form requires runat="server"...you get the idea.

Another thing that I would love to see is the ability to set breakpoints in javascript inside user controls. I was delighted about javascript debugging in VS 2008 until I found out that, since nearly all our forms are made up of user controls, it didn't work :(. Very frustrating...

Better intellisense...another great idea...

These things are far more important to me than  rich text editor, chart, color picker, etc.

Anyway, great that you guys are so forward thinking!

Carl

  Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4 /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;}

Just like there is LoginView (which is very intuitive), it would be very nice to have a “CookieView”. I could then drag an instance of the control from the toolbox and set its property (say “CookieID”). This will control what the user sees on a web page based upon the existence of the cookie specified in “CookieID”.

just downloaded. Yet to go into it.

Rough look gives good impression.

One of the controls that I've always missed is "DefaultButtonGroup". The DefaultButton only exists at page level. It would be very cool if there was more than one DefaultButton on a page. And the DefaultButton ould change depending on the TextBox that had gained focus.

I would drag a "DefaultButtonGroup" from my ToolBox while designing. It would have a collection called "fields in the group" in the properties window. I would add all the fields on the page that belong to this group. I would then set a property called "DefaultButtonID".

This way I could have multiple default buttons on a page. All I would have to do is to drag another instance of "DefaultButtonGroup" and set its properties.