The ESRI Web ADF 9.3

Remember this post?  Count that as the most popular post ever on my blog (so much for a positive post being my watermark).  Anyway Doron Yaacoby has followed up almost a year and a half later with another look at where ESRI has taken the Web ADF since then.

Almost none of the issues I addressed in my original post were fixed. The API is still overly complex. Resources, functionalities and all these so-called abstractions remain in place, emphasizing the strength of the JavaScript API’s simplicity. And yes, there are still about a billion classes that are named “Converter” in the API. It seems like ESRI insists that you write the entire namespace before every class you use.

Yea that was probably predictable, but I don’t think any of it matters.  We’ve all moved beyond the Web ADFs and on to the REST APIs (Flex, JavaScript and Silverlight).  Really though I’m amazed at how much our web development platform has changed in that time, we all can agree developing with ESRI is much more enjoyable than it was and I’m wagering most of us forget there is a Web ADF out there anymore.  I can’t wait until the ESRI UC to see what the future holds in store.

The killing of .NET and Java on the web continues unabated

The killing of .NET and Java on the web continues unabated.

I come to praise the Web ADF, not to bury it

I was just talking to someone today about web applications for ArcGIS Server 9.3 and they were surprised that I was using the Web ADF to create an application after my post earlier this week on the JavaScript API.  I feel like I need to clarify some things about that post.  It wasn’t so much a desertion of the Web ADF, but point that one should be looking toward the JavaScript API (and I suppose the Flex API) for most mapping situation and use the Web ADF (Java and .NET) when it best makes sense.  I’m using the Web ADF on this project because the requirements of the end user is best met with the Web ADF.  The great thing about the JavaScript API, the Flex API, the .NET Web ADF, the Java Web ADF and even the JavaScript extenders for the JavaScript API is that they all can be called on if needed.  Of course the Web ADF does have licensing issues that ESRI needs to address that limit its appeal even when it is the best choice for the solution. 

ESRI has given their developers choices that we aren’t accustom to and in turn ESRI developers should be looking at the choices when making a decision of what SDK to use.  Also just because you use the JavaScript API or the Flex API doesn’t mean you’ll end up with a great application.  So much more goes into it and there isn’t any reason why the Java Web ADF can’t give you a great application anymore than the Flex API can. 

Et tu, James?

Et tu, James?