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
34 Comments
13 days without an entry from James…… way too long. I’m glad to see you back.
Yea, what the heck James? Way too long.
So the JavaScript API will save us all? I suppose I finally need to start paying attention to that. Our WebADF internal sites are in need of attention.
Love the GeoMonkey on your shoulder man!
Wow, no mention of the Flex API? Here its goes…
After developing in all three (.NET Web ADF, JavaScript API, and the Flex API), the Flex API is by far the best performing (“Google fast” as our users call it), smoothest design, and easiest to develop/maintain. The API is still in beta, with a final release coming any day now. So far, I’m sticking with it for our ArcIMS replacement. Now just to pass parameters to the Flex app via the URL…
While I haven’t had too much time to play with the Flex API… I am very excited about this option as well.
In general, I think all of the API’s will allow us to move to more “user friendly” sites.
As far as abandoning third party vendors, I think there will always be a place for them on the more GIS oriented sites we deploy (And as you stated, I am sure we’ll eventually be able to pull in thier tools through a Java API).
The Flex API will appeal to some, but I think for most JavaScript clients are the way to go. You can’t argue with choice though.
This might be a remedial question but when does it make sense to use the WebADF vs the JavaScript API?
For everyone out there, I want to make clear that our underlying approach for Geocortex Essentials approach is and always has been platform neutral (other than the fact we switched from a Java-focus to a .NET focus a couple years ago).
Geocortex Essentials is our software to make it easier to build real-world applications for ArcGIS Server (not just Web ADF). Since day one we’ve engineered it in a very generic way (i.e. to leverage new and emerging developer platforms like the Javascript and Flex APIs). Through 9.2 our core elements were accessible through Web ADF only; not because we’re ADF-centric but because ADF was the only available platform!
Under active development, Geocortex Essentials 2.0 will provide the capabilities people need whether they‘re using Web ADF or any of the new APIs. Though they were originally released for Web ADF, we’re generic and we’re exposing capabilities through the Geocortex Essentials REST API for use with all the APIs; such as data linking, custom reporting/printing engine, quick search/query, and fine-grained security (to name a few). Even if an app is easier to develop, there aren’t shortcuts around the core capabilities that need to be there; no matter how magical and exciting new technology might appear.
We’ve done a huge amount of development with both Web ADF and the new APIs (with the latter proportional to the time they’ve been available). Our take? Like your assessment, Web ADF has it strengths and weaknesses. The new APIs have strengths and weaknesses. There is complementary overlap. Smart organizations will leverage the best of both. And that’s our approach too. One of our key messages right now is that a compelling reason to transition to ArcGIS Server generation technology is that it’ll allow us to provide the rich user experience public users have come to expect as a result of next-gen consumer mapping applications. Will that be a Web ADF front end? Quite possibly not. We are and will remain developers of and advocates for the best mix of technologies (that actually exist in a complete form) to deliver successful web-based GIS applications. Our customers often come to us for specific features but stick with our solutions for years because we’re committed to with taking them on a sensible, suitably progressive path through all the clutter.
One thing that raised my eyebrows; this is the first I’ve heard of anyone “abandoning third party ’helpers’” like Geocortex Essentials. Our numbers indicate quite the opposite is true (James, I’d be happy to share these numbers with you under NDA). If it was something other than misidentified conjecture, I’d encourage them to take in one of our Geocortex Essentials: The Road Ahead webinars or read about our road-ahead strategy, which I posted about a few weeks ago for customers at the Geocortex Support Center (I‘ll post it on our blog for the benefit of folks who don‘t have access).
http://blogs.geocortex.com/blogs/geocortex/archive/2008/10/16/geocortex-essentials-2-0-and-esri-s-developer-apis.aspx
David, it is good to hear you are going to support the new APIs. You probably should roll that out sooner rather than later. 2009 will probably cost you some customers.
I don’t think the reasons I’ve heard has anything to do with Essentials other than it is built on a platform (Web ADF) users aren’t interested in using moving forward.
Nothing wrong with the Web ADF if that’s what you’re into. You can make good and bad web apps with any technology.
For exmaple, we use the .NET WebADF for a very vertically focused domain specific web application. You can check out at least some pictures at:
http://www.geo-comm.com/geolynx_eoc.html
Well sure John, I don’t think that James’ point was that the Web ADF was “bad”, but it was being used incorrectly.
John, there isn’t anything wrong with the Web ADF. What I’m saying is you shouldn’t use it unless it is needed. “Out of the box” the JavaScript API makes so much more sense and will result in better implementations.
Yes, good programming wins over bad programming. But I say if two applications can be built with both the Web ADF and the JavaScript API, the end user will appreciate the JavaScript API more and it will probably meet their expectations better.
I’ve seen good Web ADF websites and I’d like to think we’ve created some of them. But for most web mapping situations, the JavaScript API does such a better job.
Excellent topic! In fact, just recently I asked the local ESRI distributor for opinions on when to choose JavaScript/Flex and when .NET/Java. So far he hasn’t find any documents he could share, but he promised to keep looking.
While I haven’t dug into this, it appears to me that with .NET/Java, you get eg. TOCs and overview maps from the get go (sample apps), while with Javascript/Flex you’d have to combine those from various samples and code exchange snippets. In live demos and live user sites these are absent as well, which makes me wonder if it’s tedious to implement these successfully. Is it so that Java/.NET would be the choise for an app for GIS-aware people, while Javascript/Flex works fine for the rest that are accustomed for googlelike GUIs and basically want one theme presented on a map with fewer functionalities. That’s the fear that is keeping me from rushing into Javascript.
Opinions?
Kind of off-topic, but can anybody tell me if the ESRI Developer Network software licences time out when your subscription expires? The EDN website is not overly informative on this topic. I just finished an MSc in GIS and I’d like to get stuck into some of these new tools and Javascript APIs etc that I keep hearing about, as well as keeping my limited ESRI skills reasonably fresh until I find a GIS job, but I no longer have access to my academic ESRI software. The EDN costs $4000 pa for a subscription including ArcInfo, which I might be able to afford once, but not every year. Failing that, I might have to aim for a career in Manifold and open-source GIS instead!
The JavaScript API is hosted by ESRI on ArcGIS Online and is available for free use. Not even Manifold can beat that price!
For EDN subscritption and pricing questions I would just call ESRI on the phone and ask them – they’ll give you the exact details you need, and may be more accurate than blog posts on the topic.
Hi James, Js API is what i have waiting for! Now is easier to integrate with j2ee apps. By the way, i have to ask you about an off-topic question… What do you think about what ESRI spain has done with some GvSIG developers? They have been ejected from ESRI 08 Conference… One person of Marketing Staff and Alfonso Rubio ejected them saying those conferences had no interest for these developers… It´s awesome!( they work in GvSIG soft development but make GIS projects with ESRI tech too)! I´d like to know what ESRI thinks about this sad situation! They explain it in this url : ( in spanish, sorry) http://geomaticblog.net/gb2/es/2008-10-16-esri_haciendo_amigos
We just finished a project with ESRI using the Flex API. I must say that it was one of the most positively received applications that we have ever rolled out. In fact, one user commented that it was “the closest thing to CSI I have ever seen that actually worked.”
I think that it is going to be hard for Javascript to catch the jee-whiz of flex on the UI, but that it may be a better way to handle some tasks.
James – Why do you feel that the Java script is the way to go for most clients? One reason I lean towards flex is the cross browser compatibility with flash (and that 95 – 98% of computer users have the app installed). Though I see our company potentially using all of the API’s depending on the needs of the end user.
It will be interesting to see what ESRI does with Silverlight.
Smitty: I look at what end users are using. They are comfortable using Google Maps and Virtual Earth (and so some extend Yahoo! and Mapquest). The key here is delivering applications that they can be comfortable using and look and feel exactly like Google or Microsoft. The Flex stuff I’ve seen is very nice, but it does work differently than most JavaScript clients.
There isn’t anything wrong with using Flex or even the Web ADF. I’m just not seeing it in my work.
@Josu: I don’t know much about that issue with ESRI Spain. The international distributors aren’t under the ESRI Redlands control so what they do is really up to them. Seems like a poor decision on ESRI Spain’s part, but that is between gvSIG and ESRI Spain unfortunately. ESRI Redlands seems to be more open than many of their international distributors.
@John B: Free sounds good! Thanks for the tips.
As a user/app-developer that deals with specialized data, I am not too excited by an API that links to ESRI, Google, or Yahoo base map data. Not nearly accurate enough for me. I would rather construct a map view from scratch using our own data – keep it totally independent and under our control. I guess I could do that with the APIs you discuss, but it seems a waste of effort.
Am I missing something here?
Gary, the JavaScript API is 100% under your control. You need not use any Google/Microsoft/Yahoo! data with it. Rather than use the .NET controls and SOAP, you use the JavaScript API and RESTful services.
Unless you use the JavaScript extenders for Google or Microsoft, you’ll need to use your own data for everything.
You can use ArcGIS Online data with the javascript API, and not your own data, and also not the extenders for Google or Microsoft.
But if you do not want to touch ESRI in any way via the web, such as may be the case for many mission critical apps or other apps where you just want to use your own ArcGIS Server and nothing else, then you can use the ArcGIS Server JavaScript API’s locally. But you need to obtain a DVD from ESRI:
http://support.esri.com/index.cfm?fa=knowledgebase.techarticles.articleShow&d=35491
… I also am interested in hearing about when it would be good to do that (use the JavaScript API locally instead of the WebADF locally). For example, is a web app faster and more performant to the end user in this sceanrio than the WebADF?
John, I would say that most people who need that are those who are behind firewalls and cannot get to ESRI servers.
James – right, obviously. What I mean is, if I have a requirement to not touch the web, and so I cannot get to the ESRI servers – then is there still an advantage in using the JavaScript APIs locally instead of the WebADF locally? Or is really the best thing about the JavaScript API when its hosted at ESRI, on their super duper georedundant server farms designed by the people that know ArcGIS Server better than anyone, and at a scale that none of us could ever implement on our own because the cost in ArcGIS Server licensing alone would make it impossible. Or do you think in the local standalone environment the JavaScript API still has lots of advantages over the Web ADF?
John, remember that it isn’t where the JS files reside, but where they are in relationship to the clients (since the JavaScript is all client side). Thus is the JS API files are inside the firewall, they will probably work better than accessing ESRI’s servers (but as we all know even internal networks can have issues).
I don’t think hosting the JS files locally is needed (or prudent) unless the browser clients are restricted from accessing ESRI’s servers.
Okay, this makes things more clear, I think. It still seems that if I don’t want to use served up data from a big vendor, I might as well develop my own interface on a platform, e.g. Flex, that I’ve chosen because of its features, and not just because it’s there.
I have a bias against ESRI, and I also like to keep our hands into several software pots so we don’t get in a rut.
Thanks for the info!
I’ll give you one big reason the Web ADF should not be used. It uses the post back model and doesn’t work on ASP.NET MVC. The JavaScript API is much more flexible to changing technology and is server platform agnostic.
Now I would love to see a Silverlight API. I think that would make things 10 times easier for us folks that don’t like mucking around javascript and using multiple javascript frameworks for graphics and json and what not.
Concerning the local instance of the JavaScript API: Is that the setup you would use if you were using a portable data appliance and going into the field out of the range of a network?
v2 of Geocortex Essentials will bring the same basic set of tools to the Javascript API as the WEB ADF. Don’t waste your time making simple doodads like select by polygon because they’ll make them for a lot less and maintain them as well. When this happens we’ll switch to javascript API almost exclusively and get out from under the per server licensing for the web ADF. That has really been the biggest hinderance for us. I think that has been a hinderance for most companies.
Oh and I have to concur on the silverlight thing….dojo blows.
as far as hosting the JS api locally…..this is very important for any enterprise. It is folly and stupid to think the Internet is always available. If you can’t reach ESRI one day, your enterprise JS API app is DOA. Do the smart thing and host the API locally.
I’m kinda late to this thread, but I’m a big proponent of using the lightest possible tool set for a job.
But this is somewhat beside the point , since our focus should be on building usable and useful applications that solve problems. Simply picking a development platform “because it’s easier for you to develop on” is not a good idea. End users expect sites to be “Google Easy”. And it’s on our plate to make that happen – regardless of the “geo-mechanics” that are going on behind the scenes. Focus on making your users successful and let that guide your technology decisions.
Late as well to the thread, but as a strong advocate for lightness (and a Geocortex admin) – one of the problems as I have been playing with the Javascript API is that I can see difficulties with version control, etc.
For many large organizations (County of LA over here) the ADF will provide a consistent set of building blocks that a middle tier company can use to create a set of configuration tools, as opposed to development tools.
Javascript, while easy, will allow developers all over the place to create different, unrelated toolsets that will be very hard to support.
well I heard that ESRI is working on a silverlight API so it looks like I wont have to buy an Adobe product to make some cool mapping sites.
@JW: Yes, my source inside ESRI says that Silverlight is coming from ESRI. I much prefer working in .NET than in action script. I too will wait. I am sure something will emerge by the next developer summit.