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

[DonKang]

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]

This is a great question. I can only offer my opinion... 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). Granted, a lot of these moves were in an effort to keep up-to-date with technology and industry standards, but it makes it incredibly difficult for organizations to invest in personnel training and development time on one technology.

My organization has hesitantly decided to invest in developing our web mapping apps primarily on the JavaScript API. We evaluated the Flex API for about a year, we did not dabble with Silverlight at all. The reasons we have decided to focus on the JavaScript API are as follows:

1. After the cost of ArcGIS Server, the JavaScript API requires no additional investment in software for development, such as an IDE like Silverlight or Flash Builder. All you need is a simple text editor.

2. The JavaScript API and the Dojo Framework are open source. No proprietary investement or development environment is required.

3. The code does not have to be compiled. It is all open HTML and JavaScript.

4. No specialized training is required (such as Silverlight/.NET or Flex/Flash). Getting access to HTML and JavaScript documentation and resources is very easy.

5. Most programmers in our organization are familiar with HTML and JavaScript, but not necessarily Silverlight or Flex. This makes it easier for our GIS staff to receive support and interface with non-GIS personnel. Also, in this time of budget cutbacks and layoffs, it is easier to get a new person up to speed with HTML/JavaScript than it is with Silverlight and Flex.

It seems that FLEX has been the hot technology for the last couple of years, but I see more and more interest in the JavaScript API, especially as it gets more robust. I'm hoping this means it will have more staying power, but we are still talking about Esri here so anything can happen.

[DonKang]

I agree and especially the deprecation part.
Like you've mentioned on #5, lately I've had several request from non-GIS programmers wanting
to add a simple mapping functionality (but customized) to their web projects. And they really like the javascript api because of easiness of embedding into their pages.
And do not require plug in nor frame work installation like webadf.

Yeah, I will be cautious too. Not falling in love with this too fast.

thanks for your comments.

Don Kang

[StephenLead]

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

[DonKang]

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

[MatthewLawton]

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