I am debating between using Asp.Net Ajax and "regular" Ajax. As of now I have used Ajax by writing the javascript files and the web service/web pages that does the XmlHttpRequest.
So my question is what benefit would I get from using Asp.Net Ajax.
For the most part, AJAX is AJAX. ASP.NET would be your deciding factor, over a different technology. But if you're currently using ASP.NET and creating the AJAX functions by hand, the toolkit will alleviate the need for hand coding.
Jeff
How does the toolkit render the page, if I add some Asp.Net Ajax tools to an already existing Asp.Net page will my viewstate get bigger, will Microsoft add some code to the page to make it work that I don't know about.
ASP.NET AJAX - it's easy, quick and it's fun. :)
You can use notepad to write your .NET application, but you can use the Visual Studio ...
You can do AJAX functionality by hand, but you can use ASP.NET AJAX...
with asp.net you pass beyonde web pages u build web applications wth easy use of ADO.NET and so on... I would suggest you to try asp.net.. enjoy exploring cause this is basicliy what I'm doing...
It's a good question.
The thing is ASP.NET AJAX gives you all these things with a Microsoft Support team behind it:
1) Client side AJAX API - probably much like the one you've written but almost certainly far, far bigger. It can also call SOAP Web Services, Static aspx Page methods, serialize and deserialize objects and supports "classical class inheritance" with interfaces. It's a pretty good client side API and has had some very clever people develop it. The CTP also has a taster of even more ambitious Client APIs like XmlScript, DataTables and DataSources. Its not perfect by any means but I understand the next version of Visual Studio will include full Javascript intellisense for it which could be very cool indeed - especially if it alo makes it into the Express versions of that product (which I would expect it to).
2) Server Side API - Based around the Script Manager and UpdatePanels mostly. Update Panels are rediculously easy to use although FAR from optimal AJAX but have the huge benefit of "degrading" to a normal postback if Javascript is disabled. Conversely, the Bandwidth used for SOAP WebMethods could hardly *BE* more optimal, using pure Json up and down the pipe - fantastic value for money!!
3) Client Server integration: easily pass objects from client to server and back again.
4) Ajax Control toolkit - a set of Widgets to easily add cross browser GUI controls that take advantage of AJAX
5) Provides a defined Ajax Framework which is backed by microsoft, something non of the other frameworks can offer. The more popular ASP.NET AJAX becomes, the more community it gets and the better it gets. Dojo, Prototype, Bindows are all great but will always remain a little marginalised by something like ASP.NET AJAX.
6) This community and others like it.
I think it's fair to say that given where ASP.NET 2 used to be, with its postback architecture to where it is now (with ASP.NET AJAX) I think is a great improvement indeed, just the act of popping an update panel on an existing ASP.NET page can transform it from being humdrum and ordinary to something with much greater response and even "Wow" factor as it will only do a partial render (less bandwidth), there is no flicker (as the page does not get discarded) and the page scroll position does not need to be affected. 100% better already.
I would also say that although much of it comes across as "Ajax for dummies" (although you could also say that about the other Ajax frameworks out there) I think there is plenty of scope there also to create nice, optimal interfaces, additional toolkit widgets and other reusable AJAX enabled objects but the real key is the support and the continued development by some very, very talented people. Fundamentally I think the "ASP.NET" thing gets in the way of the "AJAX" thing and can make things far more complex than they need to be but ultimately, if you are using Visual Studio (full or express) and are creating Web Applications or dynamic sites then ASP.NET AJAX is the way to go.
Or to put i another way, what do you think will get you your next job in a programming team, saying you've written this killer AJAX framework and use it all the time and it "works great form me", or saying that you have mastered the "industry standard" AJAX toolkit and can leverage the knowledge therein, and which may well be the AJAX toolkit your next employer is already using? Trust me when I say I was in that position offering the former, I showed them my widgets, my treeview, my resizer bars, my fake windows, my serialization objects, my lazy loading, my drag and drop, my menuing system, my eventing system, my animation system, even my 2D and 3D graphics engine, all pure javascript and all built in - yes I got the job but had to promise to learn ASP.NET AJAX straight away if I wanted to do that kindof thing (ie: it's industry standard and the other developers can then work on my code, ie I remain dispensible, which is what they want).
Just the answer I was looking for.
VR2 you said:
"yes I got the job but had to promise to learn ASP.NET AJAX straight away if I wanted to do that kindof thing"
For you to learn straight away what books/websites, if any, did you use to move from your old way of writing ajax apps to Asp.net Ajax?
Another question:
Is there any speed difference when using Asp.Net Ajax compared to other Ajax Frameworks, and does anyone know if search engines look at the pages differently.
You can start from
http://ajax.asp.net/docs/
http://ajax.asp.net/documentation/default.aspx?tabid=47
"For you to learn straight away what books/websites, if any, did you use to move from your old way of writing ajax apps to Asp.net Ajax?"
I got a book called "Programming Atlas" which I nearly threw out in disgust until I was told that the stuff it talks about still exists but in the CTP (and in a modified form). Also this website has been invaluable. I have to say though that I'm still just finding my feet not only with this but with ASP.NET also (I previously used COM, VB6, asp classic & javascript).
As to the speed of ASP.NET AJAX - I'd imagine that it depends what you are comparing it with and *how* you are doing it.
In general UpdatePanels will be slow and clunky (by comparison) but will offer extreme ease of use and a server based event architecture using the well established and frankly huge ASP.NET 2. And it will degrade for the mobiles etc!
Web Services and Static Page Methods will be fast and nimble but - what do you DO with the data once you have it? This is where you need a strong client side API (widgets) to display and allow the user to manipulate the data WITHOUT needing update panels to post back the viewstate every click (so that server events can fire and update the server version of the page DOM and send it all back again).
And this is where the CTP could come into play, just so long as you don't need to be able to downgrade for Mobile Phones! For example, I did an experiment using the CTP client side DataSource and DataTable - and a server side DataService or WebService (wrapping calls to a TableAdapter) where you could simply instatiate these objects on the client and have a grid that was effectively 2 way databound to the datasource, meaning that the user could update any data in the grid they wanted and the DataSource would post only the changes back to the server using JSON. The custom grid object tool a while to write as an extender in the AjaxToolkit but once written, in 2 minutes you could have this up and running and it was as optimal as you like.
busyweb: