Ajax.NET support in future .NET versions??

Tuesday, May 31, 2005 10:16:00 PM

I added the Ajax.NET idea to the Microsoft Product Feedback Center:

http://lab.msdn.microsoft.com/ProductFeedback/viewFeedback.aspx?feedbackId=FDBK28434&lc=1033

If you are thinking that the idea of Ajax.NET using attributes to create proxies for client-side methods would be nice to be added vote on this suggestion.

4 Comments

  • Nikhil Kothari said

    Steve, I totally agree more needs to be done in ASP.NET (in terms of the general framework, programming model, and controls) to easily enable AJAX metaphors. You can totally expect to see more from ASP.NET as focus starts to shift from Whidbey and onto v-next oriented features.

    Like you, I envision, and believe the goal of the framework needs to be no-javascript programming required of page developers. They should use controls very much like they're used to. I also believe that true AJAX support does not come from individual controls doing callbacks, but the overall framework and all the controls working together in an AJAX-fashion.

  • Charles Chen said

    While I like Ajax.Net (had lots of fun with it on a project I worked on recently), the fundamental disconnect between the paradigms realized by Ajax.Net and the ASP.Net postback architecture is such a large gap, that any UI framework featuring Ajax.Net would be like a seperate aspect completely meaning it would have no place existing side-by-side with ASP.Net postback architecture.

    In some sense, it is a *superior* architecture than ASP.Net postback (no page refresh, more compact data transfer between client and server in most cases, more responsive UI's, able to do some really cool stuff); in some sense, it is a *weaker* architecture (this iteration requires a lot of client side programming, writing cross browser compatible scripts, disconnect between server-side object/control model and client side HTML elements, larger initial downloads due to script files, harder to maintain, less IDE support, more room for abuse/bad/hard-to-maintain code (bad scripters), etc.).

    It would almost necessitate a seperate development branch for the ASP.Net team to create two different UI frameworks if you really wanted to get the most out of Ajax.Net and get it to a state where you wouldn't have to write *any* client-side code for default behavior of controls (i.e. MyTextBox.Text = "hello world"; maps to document.getElementById("_ctl12").value = "hello world";).

Comments have been disabled for this content.