I find it interesting that most work I’m seeing these days is with the JavaScript API that ESRI released at ArcGIS 9.3. I assumed a couple months ago that people would really be looking at moving off of the WebADF (.NET or Java) for the JavaScript API and it appears that this trend is beginning to happen. Now before you think that I’m really sticking a fork in the WebADF, think again. The WebADF will continue to grow and be used where it makes sense, but probably not as the “default” mapping front end for ESRI web servers. The simplicity of the JavaScript API and the way it works, makes the classic WebADF and HTML viewers obsolete for most users (I’m still waiting to see what ESRI does with Silverlight, but that discussion is for another day).
Also, coupled with the JavaScript Extenders for Google Maps and Virtual Earth, there is probably very good reasons to be looking this way instead of deploying the WebADF. I’ve also seen people abandoning third party “helpers” for the WebADF such as Geocortex Essentials (I guess we’ll see JavaScript API tools from these companies soon, eh?) to move back to simpler JavaScript front ends. There are times and places for .NET or Java server solutions, but what the JavaScript API has done is allow ESRI customers and implementors to go with a more lightweight solution and in turn brings them to more cutting edge RESTful and JavaScript technologies that can be leveraged outside of the ESRI silo.
I’ve really started to try and point my clients (and anyone else who asks) away from the Java and .NET WebADF and toward the lightweight ESRI JavaScript API. Everyone who has moved in that direction has really been satisfied and given the 9.2 release of ArcGIS Server, that is really turning things around.
James seems to be pushing ArcGIS Server again
Spatially Adjusted 