The Ajax Experience

JD, reporting from the Ajax Experience conference says:

"The "browser differences" problem looks like it's being pushed up the stack, into the "framework differences" problem. Techies tend to have a weakness in focusing on initial development, and ignoring support and maintainence costs... we tend to be fascinated by Bright Shiny Details, and get excited about new things we can accomplish. I could easily be wrong in this prediction, but the sense I got at this conference was that there was a looming problem in sustainability that remained unaddressed by the speakers I heard."

And this is where it belongs for now. This concept isn't really new. Even before Java and .NET, people abstracted away platform differences with C++ libraries. The ideal situation certainly isn't coding all the differences yourself. Yeah, maybe the original dev might be able to modify the code a little easier if he wrote all the code to abstract away the differences, but he is probably going to be making a lot more changes and certainly going to take a lot more time to get the job done. If we are talking about long-term maintainability, when that dev leaves or another dev comes on the project you are probably worse off writing it yourself. Frameworks written for mass consumption generally have cleaner code than frameworks written by a few in house guys for their latest project. The solution is not trying to keep all the framework differences on your plate. The solution is to make sure you chose a good Ajax library. This is exactly where companies like Microsoft come in with Atlas. This provides you with a framework that is going to be maintained, that is going to be tested, and that is going to be improved--all by other people, people who understand the browser differences and the Ajax space better than you or any of your developers will any time in the near future.

[1] http://weblogs.macromedia.com/jd/archives/2006/05/ajax_experience_2.cfm

2 Comments

  • I'm still thinking this through, so thanks for the response. The framework scene for JavaScript is in high churn now... timing issue... hard to predict now what will be used in late 2008, what the maintainence/renovation costs will be for each approach by then.



    I also agree Atlas will inevitably get mindshare, and be a factor for some time to come, regardless.



    Frameworks are good... it's useful, and inescapable, to keep increasing the abstraction level. Because there are so many approaches to papering-over the differences among the audience's browsers, making a choice among these strategies has implications down the road, too. This seem right to you...?



    tx, jd

  • I think it's safe to say that a lot of the AJAX solutions that are out there and available today are going to be rewritten. Popular frameworks like AJAX.NET are going to be superceeded by ATLAS. The good news about ATLAS is that you can use it without ASP.NET, so it is going to be a nice open framework that anyone can take advantage of. For sure, starting in 2007 any cutting edge .NET project will be using ATLAS. It will take a while for it to trickle down to the masses, so I would say it is pretty safe bet that by late 2008 ATLAS should have broad adoption. It is a very slick bunch of code. Churn is something you can always expect in a new industry, but as soon as the big players get involved, things start to consolidate. That is exactly what we are going to see when ATLAS enters the picture.



    In any case, if you restrict yourself to IE 5.5+ and Mozilla/Firefox, you can cover a ton of ground and the JS differences really aren't all that bad. If you control both the client and server pieces, hand coding is not as bad as it is made out to be. You just need a good SOAP/WSDL library and google search ready. Both IE and Mozilla implement the DOM specification pretty well, which really helps for just about everything you need to do in a simply AJAX app. About the only big difference left that we found after we got ahold of a good SOAP/WSDL library for our last AJAX project was in dynamically wiring up events (nothing that couldn't be handled by a pretty simple if / else statement).



    Of course, there are plenty of other differences in the browsers that you may run into if you are doing a really complex AJAX implementation or need to try and support every browser type that hardly anyone uses, like Opera (which isn't the case for most AJAX work today I would venture to guess). Things like XML namespace support and lack of JS namespaces are a potential gotcha with SOAP calls and JS libraries, but these are problems that 99% of developers won't have to worry about. For the other 1%, ATLAS provides built in solutions for that type of thing.

Comments have been disabled for this content.