I have little doubt that the most commonly-used control will be the update panel, because it is the least disruptive way of adding AJAX to ASP.NET. You just surround your controls with it and voila, magically the page doesn't refresh any more. Unfortunately it's little more than a hack. It's not really Web 2.0 in the sense that it doesn't expose a service that is consumable by a variety of clients. It still sends presentation information mingled with data to the client. It basically just sends a smaller portion of the page and its view state to the client which then rewrites the page using the DOM.
I'm going to say something controversial now: page refreshes are not that big a deal. Before you accuse me of heresy let me remind you that ASP.NET has had the option to maintain scroll position after a page refresh since 2.0. After a (hopefully) brief flash the user sees exactly what they would have seen if the update panel had updated the page asynchronously. Often preserving scroll position doesn't even do very much for you because the fluid nature of web page layouts can move the users reference point up or down vertically while preserving the exact pixel position of the scroll bar.
The real problem with AJAX for ASP.NET is that it's very difficult to move some operations to the client-side while continuing to perform certain operations on the server-side. Why? ViewState and Session state. ASP.NET's state maintenence information is not accessible on the client side. This limits the amount of work you can do on the client lest it get out of sync with the server. To make Web 2.0 applications really easy to write you need to raise the level of abstraction. I can see a few different ways of doing this:
1. Provide powerful controls that you can manipulate on the client-side. Where is the AJAX-enabled GridView control? You know, the one that transparently pushes sorting and paging to the clients that can perform them. I suppose I will have to wait for a third-party to provide one but I shouldn't really have to.
2. Make javascript better. Javascript is growing up but you wouldn't know it if you are targeting IE. Firefox 1.5 and Actionscript 3.0 can mingle XML literals and code like this...
var name = "Jafar"
var customer = <Customer>
This is a big deal. Dynamically generating HTML/XML using the DOM is difficult to read and write. Microsoft is well-aware of this problem. In fact, they designed a research language called C-Omega to address it which integrated XML literals and stream processing into the C# language. These improvements have found their way into the next version of VB.NET but strangely Javascript, which stands to benefit just as much from these features, is basically unchanged in IE 7.
3. Hide javascript. If Microsoft refuses to keep Javascript up to standard I suggest that it hide it as Google has done. The Google Web Toolkit compiles Java into Javascript, providing static type checking at compile-time. The inability to do this in ASP.NET really annoys me given that C# is a much better candidate for this role than Java. It maps to Javascript much more cleanly because it handles events in the same way as Javascript: function pointers. I know that this is an area of research in Microsoft but considering Google has already developed several well known applications using GWT it would seem that the concept has been proven.
It doesn't look like things will improve substantially with the next version of Orcas. Javascript intellisense and type inference will make web development a lot easier but this is really just putting some (very nice) lipstick on a pig. I hold out hope that developers will demand more from Microsoft so that they can develop the advanced web applications that their users deserve.
10 comments:
I think you're being unfair in saying "It's not really Web 2.0 in the sense that it doesn't expose a service that is consumable by a variety of clients." There is a whole infrastructure there to do just this! You can JSONify a web service with a line of code, and if you can live with the weight of JavaScript that the ScriptManager spits out, it'll create a client-side proxy for free.
With that in place, I can go back to the CLR on the server side where everything's happy and testable, and I won't get shouted at by designers and JavaScript coders (justifiably) complaining about the stuff that comes out of the built in controls. Like ASP.NET's web controls, the controls in AJAX for ASP.NET are probably highly demoable but mostly unusable. But the service stuff seems to cover my usage pattern perfectly. :)
You are right, c# is way more powerful :)
And yes there is a prototype to translate compiled c# code to javascript.
visit http://jsc.sf.net
Script# compiles C# to JavaScript:
http://www.nikhilk.net/ScriptSharpIntro.aspx
thom: As far as I'm concerned handling the plumbing for making web service calls from javascript is the bare minimum.
The inability to keep server side state in sync with changes made with client side code is a big problem. If I change a control in response to user interaction and then I have to do a post back for some server-side behavior, the viewstate mechanism can't ensure that the changes made on the client-side are preserved. As a result, if you want to do a really advanced AJAX app you have move most things to the client. This means you are forced to use Javascript and it is frankly not up to the task. Javascript was originally designed to be light-weight to keep if from balooning the download size of the browsers and chewing up a lot of CPU cycles. Prototype inheritance is very useful if you are just trying to embed a little behavior in a web page but it's very frustrating if you are trying to write a serious application.
The newest version Javascript addresses most of its issues but Microsoft has not bothered to keep its version up to standard.
zproxy, bill pierce: I'm aware of both of these projects (thanks for pointing them out though). Neither is ready for production use and I think Microsoft should provide a solution they are willing to stand behind. It doesn't look like we'll see anything in the Orcas time frame and that frustrates me.
Hi,
you mention in your blogpost that since ASP.NET 2.0 it's possible to keep the scroll position. Actually in 1.x you already had SmartNavigation to do that for you.
Take a look at this page: http://msdn2.microsoft.com/en-us/library/system.web.ui.page.smartnavigation(VS.80).aspx for more information.
Grz, Kris.
I was not aware of that Kris. I just want to note that this is deprecated in favor of maintainscrollback position now. Thanks for pointing out though.
Interesting points that I have more than a little sympathy with and can understand your frustration.
I think what ASP.NET AJAX is offering is an entry point Ajax (like) solution that can work as well on the open web, with UpdatePanels being particularly useful for having your code downgrade for lower end / disabled browsers and mobile devices.
I too was frustrated as it appeared much of the advanced client controls were kept back in "Futures preview", things just like client side 2 way data binding to client side DataGrids, DataServices and the like.
Your comments regarding Javascript did seem quite severe however as it appears to me to be an extremely flexible language that can be made to follow a classical inheritance pattern (as Microsoft have implemented in the client side scripts).
Once "tamed" in this way, it can begin to resemble a "Mini C#" on the client, and is something that is widespread and mature right now, and has been for quite some time.
As for your example of what Actionscript can do, well isn't that pretty much the same as:
var name = "Dave Crane";
var obj = {Customer: {Name: name}};
So my main problem with ASP.NET AJAX is more the fact that the true Ajax features have been kept back so far, and what is left (UpdatePanels, Web Services, Control Toolkit) relies heavily on existing ASP.NET Web Controls and thus the whole "Postback" architecture and all the State maintenance that goes with it.
And it's this overly complex and fragile state management that causes all the problems.
The mere fact that parts of a page are "thrown away" means zero opportunity to maintain pointers to objects on the client side, meaning that everything requires an ID in order to be referenced in code, the more complex the page the more and longer these IDs get until you look at your source code and it is full of impossibly long and bloated tag IDs, with very little real content. Most importantly though, you have lost the ability to add/remove event listeners and the like. In fact from that position all you can hope to do is to hack it by sedning something like this to the browser (div tag removed):
div id="SomethingReally$Long$GoesIn$Here" onclick="DoSomethingToStartWith();ThenDoSomethingElse();AndFinallyDoThis()"
Hello
/div
Rather than doing this in your client side code:
// Obtain event delegate
var delegate =
ajax.lang.getEvent(window, this.MyDiv, "onclick");
// Add or remove listeners from the delegate any time yuo wish...
delegate.addListener(this.DoSomething);
delegate.addListener(this.DoSomethingElse);
delegate.addListener(this.AndFinally);
// Just for fun
delegate.removeListener(this.DoSomething);
While this is manageable in small, not very interactive "web pages" the more you move towards richness and real web applications its failings begin to hamper things significantly.
And then there are the Script Manager scripts, what are they 300 or 400k now? Not so much a big deal nowadays but still it acts as a barrier (you wouldn;t want that on your home page for example). Unfortunately there is no "Lazy Loading" pattern available so if you want the smallest amount of MS Ajax on your web page then you need to download the entire client side library.
I would like to see the ability to have the library split into separate classes, downloaded only when the user actually invokes a need for the class.
I would also like to see Microsoft offer up a "one page app" solution where the (book-like) notion of "pages" can be done away with (changing pages = state management issues) and proper, rich, stateful applications can be built with ease on the web, if say, you are willing to insist on basic browser support for javascript etc.
All this can be done and *is* being done but is not reflected in what Microsoft are presently offering or promising.
Women’s nike tn Shox Rivalry est le modèle féminin le plus tendance de baskets pour le sport. tn chaussuresConcernant la semelle :Cheap Brand Jeans ShopMen Jeans - True Religion Jeans nike shoes & Puma Shoes Online- tn nike, le caoutchouc extérieur, l’EVA intermédiaire et le textile intérieur s’associent pour attribuer à la.ed hardy shirts pretty fitCharlestoncheap columbia jackets. turned a pair of double plays to do the trick.Lacoste Polo Shirts, , Burberry Polo Shirts.wholesale Lacoste polo shirts and cheap polo shirtswith great price.Thank you so much!!cheap polo shirts men'ssweate,gillette mach3 razor bladesfor men.As for
情趣用品|情趣用品|情趣用品|情趣|情趣用品|情趣
Post a Comment