Coffeehouse Thread

12 posts

Asp.Net AJAX vs. Plain (old) Ajax

Back to Forum: Coffeehouse
  • User profile image
    cmanciero

    Wondering if anyone can give me some insight on the benefits of using Asp.Net AJAX rather than just using standard Ajax.

    I want to know why someone who can write Ajax applications the old way would use Asp.Net Ajax.

    Has anyone made/attempted the leap from standard Ajax to Asp.Net Ajax and was successfull?

  • User profile image
    ScanIAm

    Interesting point, there.  I never thought of it that way, but the MS Ajax stuff is very server simple if you want it to be.  Ultimately, though, you could do both, right? 

  • User profile image
    irascian

    My reading of it is this: Most developers fall into one of two camps: front-end developers who are really sharp with CSS, HTML and JavaScript and .NET developers who are really sharp with C#, ASP.NET, OO and Server controls.

    AJAX is all about client-side development, which those of use used to server-side development and its intrinsic advantages (type safety, OO, debuggers etc) find picky and painful to do, especially with browser variations that mean code which works in one browser won't work in another.

    AJAX ASP.NET assumes you're an ASP.NET server side developer. It enables you to program client-side using a very similar programming model to the server-side. The plumbing takes care of all that gnarly client-side stuff "under the covers". So it makes life easy. With other AJAX implementations I believe (but haven't looked at them!) that they assume you're a more traditional client-side developer, or they provide a programming model that isn't as closely tied to ASP.NET as AJAX ASP.NET is.

    For the server-side developer it takes the pain out of programming client-side stuff for browsers.

    If you're a client-side developer you may find better AJAX implementations more oriented towards your way of working out there.

  • User profile image
    irascian

    ScanIAm wrote:
    Interesting point, there.  I never thought of it that way, but the MS Ajax stuff is very server simple if you want it to be.  Ultimately, though, you could do both, right? 


    Indeed! And if you're a good developer who doesn't like having to trust a "black box" it's worth finding out how it all fits together on both client and server-side. The point being that ASP.NET AJAX gives you the choice and is a very effective, quick and powerful solution if you don't want to get too down and dirty with the client-side internals.

  • User profile image
    cmanciero

    Thanks for the info Irascian, I'm gonna stay with the standard ajax methods, since that is what I have been using for quite some time.

    From your take on Asp.Net AJAX I'm not missing out on anything and that was the main question that I wanted to answer.

  • User profile image
    Human​Compiler

    I disagree.  I think there are many advantages.  When we first developed on10.net, we did our homegrown AJAX.  It worked ok, but was extremely disorganized and hard to find bugs.  For the new Channel 9, we've switched our platform over to using ASP.NET AJAX completely and I must say...life is good!

    I'm an inbetween guy.  I've done server coding my whole career and I'm ok at CSS, but not a god.  At first we used UpdatePanels.  This is the "magic" that was referred to.  It worked surprisingly well and made the transition from server to client extremely easy (read: most work is still done on the server).  You're still doing postbacks, just client postbacks that don't reload the whole page.  I found though that we still needed a lot of viewstate and for what we want to do and the high traffic of Channel 9 it didn't make sense.  So I switched our server controls over completely to instantiate custom client controls on the client (inheriting from Sys.UI.Control).  Looking back at where we started, to where we are now, it is 100 times better than our homegrown client code.  I'd say for you, the big advantage you'll get is manageability of your code and all of the great OO stuff that you get in .NET will exist in javascript.  The only major thing you don't get is strongly typed variables.  But honestly, since you get inheritance, interfaces, properties, enums, helper classes (StringBuilder, String.format, etc), etc, it is really, really worth it and I'd highly recommend looking into it.

    The other cool part for some people is that the client framework is separate from the server framework for ASP.NET AJAX.  So if you're using Classic ASP, PHP, Ruby, whatever...you can use the client framework and take advantage of all that OO goodness.

  • User profile image
    Stebet

    HumanCompiler wrote:
    I found though that we still needed a lot of viewstate and for what we want to do and the high traffic of Channel 9 it didn't make sense.  So I switched our server controls over completely to instantiate custom client controls on the client (inheriting from Sys.UI.Control).


    Could you perhaps throw up a quick demo for this kind of thing to the Sandbox because I'm not sure i quite follow you on this? I'd love to be able to this kind of thing.

  • User profile image
    App Dev

    Development experience sounds great, but how about app performance? We're using AJAX as implemented in third-party controls. We get improvements like scrolling in long lists but no performance advantage, because callbacks from these controls invoke the ASP.NET page processing and all its overhead. We're looking for a way to get much faster update when scrolling those long lists.

  • User profile image
    irascian

    There have been a whole bunch of talks, whitepapers and slide decks about the relative advantages and disadvantages of different implementations (eg UpdatePanel = great ease of use, bloody awful scalability).

    At the end of the day, as always, you tend to get what you pay for and if you want end-user usability and performance that simulate a Windows client app, well guess what - that performance boost has to come from somewhere!
     
    Hunt around for some of the examples that replace the UpdatePanel with other implementations such as asynchronous calls to web services. I haven't implemented anything at this level myself but I believe there are ways to use the underlying framework, albeit at a greater code cost, without having the horrendous scalability (or what you call performance) problems that just using basic controls can incur.

  • User profile image
    Human​Compiler

    Stebet wrote:
    Could you perhaps throw up a quick demo for this kind of thing to the Sandbox because I'm not sure i quite follow you on this? I'd love to be able to this kind of thing.


    Here you go!  Smiley

    http://ajax.asp.net/docs/tutorials/CreatingCustomClientControlsTutorial.aspx

    irascian wrote:
    (eg UpdatePanel = great ease of use, bloody awful scalability).


    Bingo!  That's why we decided to not use the UpdatePanel.  It was really great when we first started and enabled us to prototype our stuff really quickly, but we need it to scale for the large amount of traffice C9 gets.  So we ditched it built custom controls talking to web services instead.

  • User profile image
    irascian

    HumanCompiler wrote:
    
    Bingo!  That's why we decided to not use the UpdatePanel.  It was really great when we first started and enabled us to prototype our stuff really quickly, but we need it to scale for the large amount of traffice C9 gets.  So we ditched it built custom controls talking to web services instead.


    Guess I should have highlighted that in my first post, but really I was trying to just give the broad brushstrokes.

    Unfortunately the whole UpdatePanel thing is typical of my "Microsoft" experience over the last decade and more, and follows the familiar pattern: We get taken in by a slick, fast demo - usually given by someone 'passionate' from the ASP.NET team -  we rush to implement it because nobody warns us about the real cost or gives us the real gotchas and details of the implementation, and then we wonder why we've burnt a ton of money on developing a site that will never perform.

    I've seen this so often in the past right, from the first days of ASP and Visual Interdev and it's depressing that Microsoft evangelists never seem to learn that long term this marketing approach does more harm than good, and creates more bad feeling than good. It's one reason why it's worth waiting a while after something 'cool' gets released to find out what the real story is. Or to attend 'community' meetings rather than MSDN/Microsoft ones.

    At the moment there's even O'Reilly selling a PDF of a book on how to use UpdatePanel, as if it's ever going to be useful in anything more than 'proof of UI concept' demos. It's small wonder there's a perception out there that UpdatePanel is a silver bullet that does AJAX for free with no coding required.

    Fortunately the UK MSDN AJAX evangelism folks seem to have woken up to the problems with UpdatePanel - on their most recent roadshow they've been doing a good job of educating people about the inherent performance problems of the UpdatePanel  and presented alternative ways of doing things. But I suspect they learnt this themselves the hard way through experience, as you did, rather than having been warned upfront as they should have been.

    This is my single, biggest problem with Microsoft as a developer. The marketing folks get carried away with overly simplistic 'cool' demos and appear to not have the experience to realise they're "training" people to write really crap code (I prefer to assume it's that, rather than deliberately misleading marketing to make their product look so much better than the competiton!).

    This has been going on long enough now that somebody should have cried "foul" and looked at the bad examples that keep being spread out in the wild and stopped them before they escape and create the frustration and disillusionment that turns a Microsoft fan boy into an old cynic like me who then takes everything Microsoft says with an extremely large grain of salt!

  • User profile image
    Human​Compiler

    While I agree with you in principle, it really depends on what you're doing.  The UpdatePanel is still pretty great.  At its simplest, it's just a wrapper around postbacks and does them asynchronously.  Most of the performance issues are the same that you'd have with regular postbacks except that not quite all of the load events are called (just most of them).  If you're creating a really high trafficed site, yes, I wouldn't recommend it, but otherwise it has its uses.

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.