IS Javascript API Here to stay for a long time??

Question

With ESRI's announcement of not supporting .Net WebADF, I've been testing out different APIs and I am kind a getting comfortable using Javascript API. I specially like it fact that I an easily add GIS functionalities to asp.net pages and be able to mingle around with server side stuff...
My question is.. is Javascript API going to be around for a long time. I've built about half dozen of large WebADF apps and about half dozen smaller apps, and I will have to port all these apps to something else soon. 
I don't want to make a mistake again by selecting wrong API and having to do it all over again.

I don't know the percentage, but seems like FLEX and Silverlight is whole lot more popular than Javascript API.

Also, do any of you not comfortable about your code visible to anyone who cares to look at it.
I have mixed feeling about it.

Thanks

Don Kang

MatthewLawton · Answer

Steve, just to provide some more clarification on my position... I think the main issue I have with ESRI's deprecation policy is that their sales and marketing approach is frequently out of sync with their development and training approach. There are many technologies that ESRI has advertised as THE technology for the future (Avenue, MapObjects, VBA, WebADF), even up to a very short time before they suddenly decide that these technologies are mature, legacy, or retired. In 1999, Avenue and MapObjects was heavily pushed as a primary customization platform, only to be eclipsed a year later by ArcGIS 8.0, ArcObjects, and VBA. Why wasn't their marketing team on the same page with their developers? This last year we saw the demise of VBA support in the Desktop platform, yet there are currently no training courses offered by ESRI that cover ArcObjects in the VB.NET platform (there is just one two-day course covering C# Add-ins). For those unfamiliar with ArcObjects customization, what is the recommended training path now that VBA is gone?

I feel that Esri has done very poorly with synchronizing their sales, marketing, development, and training strategies over the years, to the detriment of their end users. Two years ago Flex was the hot thing. When I began creating functional JavaScript API applications, our sales rep's first response was, "Why didn't you do it in Flex?". Now I am starting to see the tide shift a little toward the JavaScript API. I am glad to see that because I think it is more functional for my needs. I hope it continues to be supported for a long long time to come.

-Matthew

kangdon · Answer

Steve,
You have a totally awesome site. Wow!!

I do agree with you in terms of moving on to the new technology and going away with legacy products. But ESRI going away with relatively new products such as .Net WebADF and ArcGIS Image Server (Not the same as ArcGIS Server Image Extension) is not a good news to me. However, I've had issues with WebADF as well as ArcGIS Image Server. It may take some time for me to port over my applications but in the long run, I see a lot of benefits.

thanks for your comments

Don Kang

StephenLead · Answer

Esri has a horrid history of deprecating software after its users have invested heavily in deployment and customization (ArcView 3.x, ArcInfo Workstation, ArcIMS, Web ADF)

I'm not sure that's a fair criticism of ESRI - there has to be a point at which you stop supporting legacy technology at the expense of newer and better technology, and it would stifle innovation to keep spending money on these older programs. As far as I know, there's nothing to stop you from still using workstation ArcInfo or ArcView 3 if you've got it working the way you want.

Anyway, I'd agree with your points on the benefits of the JS API. We used this to create http://atlas.nsw.gov.au and didn't find any areas where we wished we'd had Flex or Silverlight. The API allowed us to show time-aware layers, huge raster layers, and very complicated polygon layers in a fast application.

Being able to read the code wasn't any issue for us, but it could be a valid reason to use a different API.

Cheers,
Steve