Rick Strahl's Weblog  

Wind, waves, code and everything in between...
.NET • C# • Markdown • WPF • All Things Web
Contact   •   Articles   •   Products   •   Support   •   Advertise
Sponsored by:
Markdown Monster - The Markdown Editor for Windows

The JavaScript Dilemma

On this page:

In the last year or so the Ajax lifestyle has become common practice for Web development even in the developer mainstream after a few years where the technology was primarily treated as bleeding edge technology. Today however, Ajax is drifting more and more into the mainstream of Web development and you’d be hard-pressed to find a Web development tool that doesn’t support it in some highly abstracted way.


Ajax is all about JavaScript and HTML DOM scripting and I thought in this column I’ll review some of the approaches that are available to satisfy the requirements to build richer client applications and offer some thoughts on issues that I am struggling with as I compare the choices available for my own development and solutions that I work on with customers.


It’s pretty clear that the days of hand coding most of the JavaScript to deal with client side logic are over. These days the complexity of what’s happening on the client and the UI is quickly getting as complex if not more so than what’s happening on the server. And while in the past we might have written a couple of lines of JavaScript here or there to validate forms, these days the requirements are much more involved. It’s almost a foregone conclusion that the client side now also requires some sort of framework which is often completely decoupled from the server side.


JavaScript Frameworks

At the moment client side frameworks are all the rage. There are basic JavaScript libraries that help with common tasks automating the DOM. The most popular along these lines is Prototype which provides basic JavaScript language enhancements as well as basic browser independent DOM manipulation functionality. Many other libraries build ontop of Prototype to build additional libraries the most common of which these days are user interface widget libraries. Dojo and Yahoo’s Widgets  are examples of Widget frameworks. Similar are effects libraries like Scriptalicious, Moo.fx



The first stop for most ASP.NET developers likely is the MS Ajax toolset along with its various support libraries. MS Ajax provides both a server centric and client centric toolset. The server side functionality is primarily driven through the UpdatePanel control that allows wrapping server side controls and containers into an updateable panel container that allows for partial page updates. This component is the basis of MS Ajax’s server functionality and provides a core set of features that can be taken advantage of by other controls. The MS Ajax Control Toolkit can also be used in combination with the MS Ajax library to provide many other controls that provide server centric implementations with client side. The Control Toolkit takes uses a common pattern to create client side control implementation and also expose the control or behavior via a server side control which allows getting the base behavior exposed in a way familiar to ASP.NET developers with a minimum or no client side scripting.


MS Ajax also includes a large client side JavaScript framework that provides core language features and basic HTML DOM accessibility through a common JavaScript API. The key feature of the client side framework is that it provides a .NET like type system and a common implementation pattern for classes and components. So you will typically use a set of guidelines based on namespace, interfaces and classes to implement your classes. You’ll use property get/set syntax for property declaration and invocation when creating your own classes and the framework more or less forces you into a specific way of doing things which is both a good thing and a bad thing depending on whether you agree with the design decisions Microsoft made. But the rigid structure of the framework also means that using it requires a certain discipline and in some ways is much more verbose than other JavaScript frameworks.


The client side framework in version 1.0 can be thought of as core framework services rather than as a complete Ajax framework. This includes the type and language facilities, extensions to some of the base JavaScript objects and the base Html DOM element. Of course there’s also support for remote communication via XmlHttp both on a low and high level as well as JSON serialization facilities and the ability to use ASMX and WCF Web Services.


To me MS Ajax is completely mixed bag. On the one hand I think Microsoft did a great job of providing a deep framework that is modeled closely to the .NET framework’s design which makes it somewhat familiar to .NET developers. But on the other hand the framework is bulky and it feels very rigid and formal in its implementation and usage.


But there’s no doubt that there is some allure in MS Ajax because it provides a single framework for client and server. The above mentioned rigidity of the framework can also be advantageous to control developers as it clearly forces common patterns for implementing components that work and expose functionality consistently. There are also many advanced features baked into the client framework like localization, testing and instrumentation at every level and not just at an afterthought.


Pure JavaScript Frameworks

Microsoft started from scratch when they built MS Ajax but there are a number of very popular JavaScript libraries available most of which are easier to use and more light weight to boot.


If you are a developer who’s familiar with JavaScript and not afraid to code on the client side, a raw JavaScript library might offer you much more flexibility and options to create cool interfaces because there are a large number of libraries available. The most difficult portion of a JavaScript/Ajax framework is the browser interoperability and functionality extension of the base JavaScript objects and basic DOM objects and all of the libraries I mention here address this scenario. These libraries do away with the inconsistency of dealing with various browsers which is easily the biggest time waster when dealing with client side scripting. Take that away and you might find that JavaScript coding is not a big deal after all.

The most popular among the JavaScript frameworks is Prototype which is a highly usable and relatively small library that provides JavaScript type extensions and a large number of DOM abstraction and enhancement functions. Prototype is small and concise and is easy to pick up by anyone reasonably familiar with JavaScript which accounts for its popularity. It’s definitely going to be less familiar to ASP.NET developers as it’s clearly a JavaScript centric framework. Prototype has pretty much become the yardstick by which other libraries are compared. Prototype is also the basis of many other higher level frameworks and many smaller add-on libraries exist that provide specialty functionality on top of Prototype.


There are other frameworks that follow a similar base approach. A couple of others that I’ve used on several occasions are jQuery which is very light weight and provides mostly AJAX/ JSON functionality, plus basic browser abstraction. MooTools is a full featured library that focuses heavily on effects (like drag and drop, animation etc) . I’ve found MooTools to be very enjoyable to work with and it feels like the cleanest and easiest to use implementation of the JavaScript frameworks I’ve played with. It also uses a very Prototype like base implementation although it doesn’t rely on Prototype itself so it will be immediately familiar to users of Prototype. Mootools also has a cool feature on their site that lets you customize the MooTools JavaScript library by feature so you get only the features you want include in your set (or sets).


Other libraries yet aim to extend the popular Prototype library. script.aculo.us for example, provides an effects library that runs on top of Prototype as does Moo.Fx, which is a tiny effects library that can work with Prototype or as part of MooTools.


All of the the libraries I’ve described so far (including the MS Ajax client library) are really core framework libraries. They provide language, object and DOM extensions, but they don’t provide much in the way of new user interface functionality. There are a number of libraries available that address this space with Widget frameworks. A couple of prominent entries in this space are Dojo, the Yahoo UI Library and even OpenLazlo (works either with Flash or DHTML) which provide a host of client controls. These frameworks are big and are often complex to use, but they provide really rich client side functionality that allows building interfaces that mimic desktop applications to some degree.


The good news with any of these tools is that they will work without any sort of server implementation so they’re easy to drop into any application – simply reference the JS libraries and off you go.


Unlike MS Ajax these libraries are purely client side – they know nothing about ASP.NET and the server side. But that’s part of the benefit of these frameworks as they are completely server agnostic. Communication between client and server is provided using XmlHttp and JSON serialization, deserialization, but if you plan on using it in combination with ASP.NET you probably will want to at least implement a custom JSON service interface that you can use to pass typed data between client and server. There are several open source .NET JSON libraries available (JSON.net, here and also my own wwHoverPanel) that make short work of this task. wwHoverPanel for example implements a self-contained HttpHandler implementation that lets you call JSON methods and return results from them.


Other ASP.NET based libraries like Anthem.NET, Ajax.NET and several others also provide server side JSON functionality. These libraries are also options for ASP.NET developers, but they tend to be server centric, and my focus here is on client side scripting so I won’t go into more detail here.


Build your Own

When I started out with Ajax about 3 years ago, roughly about the same time Microsoft announced MS Ajax (Atlas at the time), I also got excited about Ajax functionality and thought that it wouldn’t be too difficult my own library with some basic functionality. Before long the library grew into a small client framework with a very focused feature set that did exactly what I needed in my applications and life was good.  However, I also quickly found out that building your own is not as trivial as it sounds at first once you go down the path of building more sophisticated functionality. My library ended up adding things like drag and drop functionality, modal dialogs, pop up windows and various basic effects. At the time my JavaScript skills were pretty creaky and it took a bit of time and refactoring of the JavaScript code to get up to speed and actually understand more about JavaScript’s language peculiarities and browser DOM quirks. This is an ongoing effort that continues to this day.  


Today as I’m looking back I’m really glad I went through this experience as it taught me tons about JavaScript that I probably would have never figured out and now I feel at least reasonably proficient with JavaScript not to cringe at the thought of having to write client script. But I also realized that writing sophisticated client side JavaScript DOM code is damn hard especially if it has to work across many browsers and I really started to appreciate the efforts that have gone into libraries like Prototype or MS Ajax’s client library.


I still see a lot of value in building a custom library, however. If I had to do it over (and I may) I would almost certainly use one of the more prominent base frameworks as my base library and build on top of it. Using Prototype or MooTools would cut my framework code in half and let me focus on the specialty features I want in my framework.


The design I chose ended up creating matching client and server controls for most components built in such a way that the client control interfaces largely matched the server controls. The key features were to provide easy and flexible remote callback functionality to the server, a small windowing library that makes it easy to present pop up window content,  along with a host of basic client side behaviors all in a small package. And finally combining all of this into an easy to use ASP.NET based interface.


Building your own is probably an edge case, but I’m often surprised how many people like me have gone down this path mostly because in the early days there weren’t as many choices available as there are today. The advantage with this approach is that you can build a truly customized framework that matches your toolset. It can also be beneficial to do this as a tool developer so you can provide additional functionality that is self contained. For example, even today with MS Ajax you can’t easily have client side code call back into a control without major hassles but with a custom interface it’s as easy as adding a method to a control and calling it from the client side. These are the kind of things you may never see in an official framework but are indispensible when you’re dealing control development for example.


So far I’ve looked at client side JavaScript coding which is often regarded as a hassle. But there are a also a few alternatives available that let you code in a different language and output JavaScript from it. One such tool is the Google Web Toolkit which lets you write Java code to generate JavaScript code. Being a .NET developer using Java doesn’t sound so enticing, but luckily there’s a .NET project available that provides similar functionality by using C#.


Nikhil Kothari is one of the Program Managers on the ASP.NET team and he keeps cranking out some highly valuable and useful tools. One of the most exciting tools he’s created some time ago and recently updated is Script#. Script# at its core is a C# compiler that rather than spitting out MSIL compiled assembly spits out JavaScript source files. There are two pieces to this magic – the actual compiler/parser that does the translation and a set of libraries that provide the supported set of features that you can use with the C# code you write. The thing to understand is that you don’t get access to the full CLR and .NET libraries, but rather to a specific subset that is available to Script# and capable of being mapped into JavaScript code.


The benefits of this approach are that you get full support for a rich editing environment in Visual Studio, strong type support and Intellisense for the supported features.


There are a number of ways that you can create Script# generated JavaScript – one is inline inside of pages via a Scriptlet control that can contain C# code that gets converted on the fly and a more traditional library type approach that creates a separate .js files.


One of the cool things that Nikhil has done is provided a mapping assembly that provides a good chunk of the MS Ajax client library so you can generate code for MS Ajax compatible controls and behaviors. But even without the MS Ajax support, Script#’s core JavaScript support libraries provide many of MS Ajax’s type system like namespaces and class registeration etc.


Script# is an interesting concept and Nikhil himself has used it for building a number of controls and helpers he’s published recently which is a validation of this concept for real work in a lot of ways.


Unfortunately this project currently has not been given any official support from Microsoft, so currently it’s impressively maintained by Nikhil himself. The toolset includes pretty good integration into Visual Studio .NET with project and item templates and integrated editor support for most things in the way you’d expect from C# source editing. But some of these integration features are a little rough around the edges which is to be expected for an early release (0.3.0).


I’ve played around with Script# off and on and it provides some really interesting possibilities, but somehow I can’t shake the feeling that this is somehow limiting my options for coding general purpose JavaScript. Script# also subscribes to the MS Ajax way although it can work without MS Ajax. If I were to build MS Ajax controls I think I would start seriously looking into this tool to provide some of the core plumbing. Script# will manage things like automatic property creation (MS Ajax style), class and namespace registration, handling and providing Intellisense for the core MS Ajax infrastructure which provides great discoverability and a great reduction in the amount of plumbing code you have to type to create the tedious MS Ajax client code.

There’s a lot of potential for this sort of tool as a lot of people feel a lot more comfortable in the C# vs. JavaScript. But without official support from Microsoft it’s unlikely that this tool will gain wide acceptance although there are certainly some people who will find it useful for their work.


SilverLight 1.1 and .NET on the Client

Microsoft recently announced SilverLight 1.1 and one of the features of the 1.1 version when it releases later this year or early next year will be the capability to run .NET code on the client. I don’t want to dwell on the rich user interface features of Silverlight here since this has been beaten to death recently, but rather focus on the .NET programmability and the ability of the .NET code to reach out and manipulate  the HTML DOM from within the Silverlight .NET runtime. This gives yet another option for managing client side code using a .NET language rather than JavaScript. This means that you can use Silverlight in combination with .NET to write fully standard  compliant HTML.


The way this works is that the .NET runtime hosted in Silverlight provides a programmable reference to the HTML DOM that Silverlight is hosted in. This may be IE or FireFox or Safari on the Mac or Windows. Silverlight provides interface to the the browser’s DOM and allows automation of it.


 In concept this is a great idea, but before you get too excited remember that the current DOM support is very limited and deals primarily with accessing HtmlElement at the raw DOM level. There’s no browser abstraction or any support for specific HTML constructs. However, it’s quite possible to extend this basic functionality using .NET code to provide a much richer abstraction and browser independent access to the DOM. This would require somebody to build a browser abstraction layer first, but once done imagine the benefits that this would bring: You could build a browser abstraction layer that’s driven through the .NET coding model providing all the benefits of compilation and discovery and of course Intellisense.


We’re not there yet, but the possibilities of this technology have tremendous promise not just to address the flashy scenario we’ve seen so much of with Silverlight but also using Silverlight as a behind-the-scenes scripting engine for the HTML document.


Too many Choices?

As you’ve seen there are quite a few options available these days to build client side code. It’s no longer just about the remote AJAX functionality but also about building rich and snazzy client side interfaces.


There are many ways to skin this cat. The Ajax framework market is hugely fragmented and this is a problem especially since many of the Ajax frameworks and tools are so drastically different that moving between them is nearly impossible.


Even if you look only at the ASP.NET space, you’ll find that the MS Ajax release late last year has not found the universal adoption that’s typical for anything major coming out of Microsoft. While MS Ajax almost certainly has quickly become the most prominent ASP.NET Ajax framework by default, many early adopters of Ajax technologies are finding that MS Ajax is not a must-switch solution and continue on with their existing tools. That may change as time goes on and MS Ajax matures and adds more useful functionality that makes it more compelling as a client side tool.


Where does that leave us? I feel right now just about all of the Ajax tools out there are immature and often buggy. That doesn’t mean they don’t work, but they are not necessarily easy to use or maintain. The best that we can do as developers is to try and pick a toolset and stick to it if possible. But even that is often difficult if you work with multiple clients that have different preferences for the toolset used. Over the last year I’ve worked with at least 5 different Ajax frameworks on various projects and switching between these frameworks and building interfaces that run on top of them is not optimal to say the least. But it’s become a fact of life.


For my own internal work I’ve also landed myself in a dilemma. Do I stick with my custom built solution, or do I bite the bullet and make the switch to MS Ajax just because in the ASP.NET space at least it’s as close as it gets to a standard implementation? Even though I’m less than thrilled with that toolset? Or do I stick with what I got, possibly refactor and use a base library like Prototype? That’ll be most likely the path I take, but for now I’m sticking with the original framework I built. There are a lot of choices to make, benefits and tradeoffs to weigh.


Ajax and client side development is here to stay, but we are bound to see some consolidation and stabilization over the next few years. These are turbulent times.


Welcome to Web Development in 2007.

Posted in JavaScript  AJAX  

The Voices of Reason


# DotNetSlackers: The JavaScript Dilemma

June 03, 2007

# re: The JavaScript Dilemma

jQuery rocks but I beg to differ on your point that it's mostly about AJAX/JSON. I don't know when you looked at it but it might be worth revisiting. Things that used to make us wince, are now a total breeze with jQuery. I found that prototype just buggered about with the underlying JavaScript objects too much, wasn't particularly intuitive, and was very poorly documented.

June 03, 2007

# re: The JavaScript Dilemma

Another nice writeup Rick! I enjoy reading your analysis -- very thoughtful.

Another way to look at it is that JavaScript code runs in the interface, and as such will most likely be replaced in a few years anyway, so don't stay awake at night worrying about the framework.

By the way, for anyone looking for a great introduction to the ASP.NET AJAX JS client framework, check out the new book by Dino Esposito, "Introducing Microsoft ASP.NET AJAX". The first 60 pages provide a spot-on perfect introduction for those who want to understand what that framework is all about. My only regret is that the book then shifts to the server side of things. I wanted more about the JS library!

Rick Strahl
June 03, 2007

# re: The JavaScript Dilemma

Duncan I spent a bit of time in the last few weeks reviewing various JavaScript frameworks. jQuery is nice and concise but it's pretty light on features. Specifically it doesn't have a ton of element extension/movement functionality which is what I need desperately. Dealing with positioning, switching between absolute positions and non-absolutes etc. is something I didn't see in jQuery. But for a base library that's small it's looks good - I did see it has a base set of animation and effect features which is cool given its small size.

The problem is each of the libraries has good stuff and some annoyances. I'm leaning towards prototype because at the core level it has all the things I need, but I'll need something on top of it for effects. In addition Prototype is as close to standard as there is at this point so to build on top of that might be the way to go.

Todd - I was thinking about that comment of yours for the last few weeks. As you remember I've been checking out Silverlight, have been dabbling in Flex and started doing some work with WPF. After doing that for a couple of weeks I was glad to get back to plain Web development which if not as flashy is much more reliable. Microsoft definitely has a long way to go to have something to replace client side scripting in the browser and even if they nail it there's an political uphill battle because well they are Microsoft and nobody trusts them on the client for browser independence.

I'm struggling with the client side man! All of it is decent, but none of it strikes me as satisfactory or rounded out. It all feels very immature. I need to make some changes for my framework stuff in the near future so the above is sort of some thoughts that relate to my quest...

June 04, 2007

# re: The JavaScript Dilemma

Thanks Rick for a really insightful article (as usual). I've basically come to the same conclusions as you. We're using the "Ext JS" library which is an amazing JS-only library that layers on top of jQuery, Yahoo UI, etc. to provide the kinds of high-level actions you're talking about in the previous comment. It's well-written, full-featured and getting better and better documentation each day.

On the other hand:
1) The whole thing still feels really "hacky." IE bugs, hidden JS library behaviors, etc. all conspire to create a minefield of potential problems. Even slight deviation from the library's intended purpose can leave you in unsupported territory.
2) When this does happen, debugging sucks. If anything breaks, you're dumped into very advanced JS code - luckily I can read it but no one else on my team has dug in so deep yet.
3A) Wire formats suck - as you imply, if you want to take a JS library and communicate with ASP.NET you are in for some ugly wrapping to allow you to make typed calls to server-side methods.
3B) Even then, just converting the data back and forth between objects and JS's associative arrays via JSON can be a real mess
4) Finally, it's still quite hard to run automated tests on AJAX behaviors and keep from introducing new bugs or regressing old ones

It all feels like developing in 1990 or something... the wild frontier of programming before rich dev environments and debugging tools came along to help. I loved it then but now I just want a single client interface that *works*

June 04, 2007

# re: The JavaScript Dilemma

Hi Rick,

just came across this one! its huge :) I like it and also copied to my blog!
Thanks again for this great reading!


Milan Negovan
June 04, 2007

# re: The JavaScript Dilemma

Great post, Rick!

I used to favor Prototype over MS AJAX quite heavily (see http://www.aspnetresources.com/blog/prototype_vs_atlas.aspx). MS AJAX has a nicely thought-through component model familiar to any .NET dev. However, the MS AJAX Library itself, with all its "OO might", is very limited. For example, both the DomEvent and DomElement classes have very, very little going for them almost to the point of being useless. It's a shame. It feels like somebody just added stuff they needed and left it at that. In this regard, Prototype and Mootools go much further and give you pretty much any manipulation primitives you may want.

On the other hand, Prototype has an ugly class inheritance model. I just can't get myself to use Prototype for this exact reason. It just feels dirty to me coming for the C++ background.

Another constant concern of mine with non-MS AJAX libraries is view state. You're left to tweaking the DOM by yourself, and those changes don't make it into view state. At times it's "show stopper."

Maaaan, the paradox of choice, eh? :)

Ryan Haney
June 04, 2007

# re: The JavaScript Dilemma

Have you tried "Gaia Ajax Widgets" yet (www.ajaxwidgets.com)? They extend simple controls to make them ajax compatible. What's great, is to start using them, you drag a dll to the toolbox, and from there, drag a "textbox" to the form you are working on. Full designer support and source view support. Seems like this is the way Microsoft should have went.

And no, I am not affiliated with Gaia, just an excited user.

Rick Strahl
June 04, 2007

# re: The JavaScript Dilemma

Milan, I think you really nailied with MS Ajax in your comment. I would be happy to use MS Ajax, and while the framework for core services is there the functionality provided for useful application level work is nearly missing. If I'm going to use a big framework like this I need more justification to use it! Some of the more useful stuff is in the Futures package but I can't trust that stuff since it's been changing.

I agree with Prototype and other libraries on extensibility but frankly I don't think that there's much extensibility needed on the actually library code. This is the sort of plumbing code that doesn't need to be touched and is meant to be used in instantiation. Even if you are a client component develpoer this shouldn't get in the way IMHO although you'd have to come up with your own component model, but that's not that difficult. More important (for ASP.NET tools anyway) is to build something that can jibe well both client and server side.

But most of this stuff is immature, buggy and horribly documented. I spent a couple hours last night looking at script.alic.ous and man is that painful when their Web site is nearly unresponsive, the documentation has three topics in it and the samples cannot be found <s>...

Yes I wish Microsoft would stand more firmly behind MS Ajax and provide more of a road map of what they plan to provide for Orcas. Right now MS Ajax seems like it's in Limbo, given up for more exciting things (in MS terms) like Silverlight...

June 05, 2007

# re: The JavaScript Dilemma

I use Infragistics. It's the UI framework used at my company and it does most of the heavy lifting for me. It has extensive client side scripts and a bunch of nice UI controls. It's also compatible with MS Ajax.

I would like to see an extensive review of the commercial frameworks out there for ASP.NET:
Telerik, ComponentOne, Infragsitics, DevExpress, ..etc

Paul Glavich
June 05, 2007

# re: The JavaScript Dilemma

Hi Rick and Milan,

I agree about MS AJAX having sometimes little functionality in areas like the Sys.UI.DomElement class, although it used to. If you cast your mind back to the "good ol'" Atlas days, there was a stack of functionality in the core framework that got stripped as RTm became reality. We now have this futures kit which by and large is a very mixed bag.
As you have already surmised Rick, MS Ajax is a cor framework. They kind of stripped it all back from when it was Atlas, left the real crucial foundations in there, and released it. I think there were major decisions and implementation hurdles that they did not want to tackle at that time. The Ajax Control toolkit is probably part of that strategy. Its probably the best value-add for MS Ajax around.
I also think this 'core' client library is a part of the abstraction that Silverlight may use. Silverlight can talk to a common API such as MS Ajax. MS Ajax has already done a majority of the work around browser compatibility (at a pure DOM level).
Nice write up though.

Rick Strahl
June 05, 2007

# re: The JavaScript Dilemma

Paul, yes I can see your point.

But the MS Ajax client library is more work than it's worth in my opinion. The problem I have is that using it I still find myself diviing into low level element syntax constantly getting no help from the library. Trying to get reliable positioning information? You're on your own. Trying to get transparency? You're on your own. Trying to get and set style values? Acces the style syntax on your own (and do the conversions).

As a client library it just doesn't feel rounded out enough to be useful.

It also seems that after RTM of MS Ajax it got awfully quiet. There's not been really much discussion of what we can expect in the Futures release for Orcas.

June 06, 2007

# re: The JavaScript Dilemma

Someone already mentioned it, but Ext JS really stands pretty high among widget toolkits. Head and shoulders above most others, I think.

Also, Prototype isn't so much rooted in the Javascript world as it is in the Ruby world. A lot of the stuff, for example, in the Enumerable extensions to arrays and hashes is borrowed directly from Ruby. And it was originally developed for use with Ruby on Rails. That said, it's still perfectly useful outside of the Rails environment, but you can still definitely feel the Ruby influences if you know Ruby. So perhaps that is why some of the things in there can feel somewhat awkward (like the extensive use of closures for things like iteration).

Kevin Hoang Le
June 07, 2007

# re: The JavaScript Dilemma

With so many choices when it comes to build Ajax apps, it's hardly a dilemma. If using XmlHttpRequest object is the choice, it won't be so confusing for one to choose, but that would be a dilemma then, I think.

Steve from Pleasant Hill
June 07, 2007

# re: The JavaScript Dilemma

My bet is that MS Ajax will quiet down as a new MS stategy is rolled out for client-side functionality.

While it is wonderful to have so much happen on the client, it is my opinion that this technology should be used in limited scenarios, as the cost of maintenance in a corporate world would be exponential to the number of lines of code needed.

Tom Brothers
June 10, 2007

# re: The JavaScript Dilemma

This is a very interesting Blog and Comments. I didn’t even realize that there were that many different JS/Ajax frameworks available. I guess I have had my nose stuck in too many Microsoft dominated magazines. That being said, my time has been spent working with the MS Ajax framework and toolkit. However, my use of this framework hasn’t been exclusively just for Asp.Net. I’ve spent a fair amount of time trying to get several of the Controls from the ToolKit to work from within a Web Connection 4.x application. But most recently, I’ve been working on getting the UpdatePanel to work from within then new Web Connection 5.x Control Framework. I would appreciate any feedback on what I have done so far. Here is a link to check out my attempt at documenting what I’ve done: http://www.tpisolutions.com/WhitePapers/UpdatePanel/Default.aspx.

What I would really like to see happen... is get a community involved in developing Web Connection Server controls to utilize some of these frameworks. What are your thoughts?

Rick Strahl
June 10, 2007

# re: The JavaScript Dilemma

Tom - wow nice work on that - we should move that discussion off onto the message board (www.west-wind.com/wwThreads/) for that to dig a little deeper. You're actually mentioning a few issues with the way that the framework handles some extensibility tasks that are - uhm suboptimal. This is perfect timing too as I'm working on a couple of controls at the moment as well and basically have the same 'modify the core code' issues you had to deal with - I would welcome a good discussion with someone who understands how this works <s>...

As to the JavaScript framework issue for Web Connection - I'm in the process of putting stuff together and really this was the inspiration for this blog entry in the first place (for both my ASP.NET framework and the Fox Web Connection stuff which currently share the same client library). I have added Prototype to the client library and am debating about a couple of other support libraries to provide some effects functionality, drag and drop and windowing.

Again a better place to discuss issues along these lines for Web Connection are on the message board. I hope you'll participate over there in digging further into this...

Rick Strahl
June 10, 2007

# re: The JavaScript Dilemma

>> My bet is that MS Ajax will quiet down as a new MS stategy is rolled out for client-side functionality.

I'm not so sure that we'll see this in the near future to be honest. I'm guessing you're referring to Silverlight and related technologies. Although interesting and promising I just don't see this gaining enough momentum to become a full fledged solution to displace HTML based interfaces.

June 30, 2007

# .Net技术中心

July 07, 2007

# 本周ASP.NET英文技术文章推荐[06/03 - 06/09] - Dflying Chen @ cnblogs - 博客园

West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2023