Esri’s Roadmap for Web Developers

This post is designed to provide clarity on the future of our Flex and Silverlight development efforts. In order to align our product road maps, we continually monitor general web technology trends and the direction of our customers’ development efforts. Advances in modern browser technology combined with limited browser support for Flex and Silverlight, encourage the use of JavaScript/HTML5 for web GIS implementations. JavaScript/HTML5 has become the technology of choice among our user community for web GIS solutions going forward.

Given this shift in technology, Esri will aggressively encourage the use of the ArcGIS API for JavaScript to build custom and out of the box web applications. This year, we plan on advancing our JavaScript API to version 4.x to integrate new ArcGIS platform capabilities such as 3D visualization, enhanced vector rendering, and stream layers. We do not plan to add these new capabilities to the Flex and Silverlight APIs, which will remain at version 3.x. A new JavaScript API based web application builder will be introduced as a beta product in March, with the final release targeted for July. Flex and Silverlight Viewer users and developers are encouraged to transition to the JavaScript API based web application builder.

Does this mean that the Flex and Silverlight APIs and Viewers will be deprecated? No. We will continue to support the Flex and Silverlight user communities. However, this post is geared towards providing transparency regarding the future of our Flex/Silverlight development efforts and our strategy to promote web application development with JavaScript/HTML5. We anticipate one or two maintenance releases of the Flex and Silverlight APIs and Viewers in 2014. These releases will focus on bug fixes and critical enhancement requests. We will continue to gather feedback from the Flex and Silverlight user communities to determine if additional updates are necessary beyond 2014. Technical support for the Flex and Silverlight APIs and Viewers will continue beyond 2014.

How to learn about the ArcGIS API for JavaScript
We will hold a wide variety of technical sessions at 2014 Esri conferences, in addition to Live Training Seminars to help users learn how to develop with the JavaScript API. We are very excited about the opportunities for advancing web GIS with the ArcGIS API for JavaScript, and the work we have planned for continued innovation in 2014 and beyond. If you are interested in learning more about the ArcGIS API for JavaScript, here are some valuable resources that will help you get started:

Esri’s International Developer Summit being held in March will have several sessions to help you come up to speed on the ArcGIS API for JavaScript. Here are a few great sessions to check out:

This entry was posted in App Developers, Apps, ArcGIS Online, Developer, Web and tagged , , , , , , , , , . Bookmark the permalink.

Leave a Reply

32 Comments

  1. csburris says:

    I am glad. I remember asking a number of staff to go this way. JavaScript has pretty much won the browser wars, and works on mobile devices (iOS and Android).

  2. kmower says:

    Comment deleted on request by “kmower” -jb

    • govindtm says:

      Wish ESRI had discussed this in any of the User Conferences and listened to developers. This decision appears to be unilateral and lacks the critical reasoning expected of it.

    • govindtm says:

      No one is against ESRI patronizing JS. But that should not be at the expense of killing support for Flex. Save Tigers doesn’t mean kill Elephants!

  3. mariusnorthgis says:

    Transparency… That’s what we need. Above all, I value that Esri is making all of us know where they are going. As for the decision, I personally think that it is the right call. HTML5 is the way to go and knowing that Esri is focused on it makes it MUCH easier for me. @kmower: Dude! Very rude. Don’t you think? Besides, I do not read anywhere in the post that Flex is dead as you suggest.

  4. john_bailey says:

    As a Flex developer, I am not going to say that this announcement makes me happy, but I find myself being pushed into JavaScript and the JS API anyways by my own customers. So I guess it was a matter of time that Esri would put emphasis on Javascript. Ok, so now we all know. Now, I would like to see Esri turning over the Flex API to the Open Source community so we can contribute to it as well and keep it alive.

  5. madmule says:

    Esri makes money on ArcGIS Server…not the client API’s that are used to interface with it. As such, they have no choice but to make hard decisions on where to task Esri developers. That said, the same line of reasoning does suggest that they are doing themselves a disservice by not making the api’s open to the development community. I understand why management wants to call everything “IP” but I believe it is a mistake to not even let developers be able to see un-obfuscated api code to figure out what is breaking, or heaven-forbid….extend/improve it and share with the community. For context, I’m primarily a JS developer.

  6. oreng says:

    Thanks Esri for being transparent. Although this post should have been written 12 or 18 month ago, It’s still better than Microsoft approach of not talking about that at all. I learned to like the JavaScript language and I’m helping all my clients to do the Shift.

  7. rafaelncruz says:

    Thanks for the info, on another matter, since ESRI is an international company maybe it should stop using spring, summer, etc to reference software releases and instead use quarter year or something.

  8. govindtm says:

    This is a very disappointing decision. I do not take sides with technology and i expect the same from ESRI. Much has been said about the benefits of JS over Flex. The trouble that one faces with JS is its inconsistency across browsers. We have used ESRI Dojo and found that the JS look/feel and certain events are not the same across browsers. Not to mention the ever changing browser versions. These are not the issues one faces with Flex. We get additional advantage with packaging and deploying Flex solutions which is much more easy than JS. Above all the Flex ecosystem is thriving and should’nt be ignored. To say that we will not give updates is equivalent to saying that this is the end. Most of the enterprise projects currently under design or development in Flex would not welcome this update. As pointed out by @madmule ESRI derives licensing by the no. of cores of deployment. As an example, take the case of VBA, your own partner Schneider still needs VBA extension for ArcFM. What is needed from ESRI is a sustained support for both the platforms thereby giving the developer to build the application of his choice. Hope ESRI would consider this request.

  9. elenafomenko says:

    Very dissapointed. Killed. Crasy. Flex is not dead. It is going in a new life with Apache. My company (Canada, Toronto) has projects both on the server and mobile side. We use ArcGIS Viewer for Flex and ArcGIS API for Flex for Web and Mobile applications (cross-platform: Android, iOS, BlackBerry). Our managers and clients will be “happy”…. to understand that Flex API won’t get necessary support in future.
    The mobile applications we develope is not possible to write with JavaScript/HTML5 (e.g. Offline Editing functionality, replicas, Online/Offline syncronization, big data sources on the mobile device external SD card). We have neither resources nor budget to pay for three mobile platform apps development.

  10. elenafomenko says:

    I am absolutely agree with govindtm concerning browsers compatibility problems and advanced applications. Even Mark Zukenberg (Facebook) said that they lost a lot of revenew (big losses) using extensively JavaScript: some advanced and complex functionality for mobile applications is not available for implementation with JavaScript/HTML5. Facebook returned to native plattforms (iOS, Android) !!! ESRI, please, listen to developers and enterprise community request. Do not kill Flex support!!!

    • govindtm says:

      There are no proper tools for debugging JS apps . FireBug and other tools are not that user friendly. Second the code that we develop becomes easily available and are available for anyone to reuse. I dont think JS code written using ESRI Dojo js can be obfuscated.

      • wraja@starbucks.com says:

        We can use Visual Studio ,aptana studio,fiddler for debugging Javascript applications.Visual studio 2013 provides debugging capability on all the 4 browsers….IE,Mozilla,Chrome,Safari.

        I agree to the point that javascript code becomes easily available but we can secure the application using the portal security (token based)provided by Arcgis Server which will provide access to authenticated users only.

        Also please refer to the ESRI Training http://training.esri.com/gateway/index.cfm?fa=catalog.webCourseDetail&courseid=2771 which will give some insight to solve coding problems and other common issues that arise when building web mapping applications.Also this training provides help on debugging mobile based aplication.

  11. stepanoff says:

    Not every web map is a cool app on a phone, some are but far from all. Sometimes a web map is a enterprise web application that need constant updates/fixes/enhancements by a semi developer and I think that many ArcGIS Server customers are semi-developers who have theese kinds of maps. Certainly for semi developers I think the Flex API couple with the ArcGIS Viewer for Flex is much better than the JavaScript API. Why? Better debugging tools, much better code assistment, mxml makes some things easier, modular widgets in the Flex Viewer, more helpful IDE, many components functions come out-of-the-box?
    Thanks to the Flex API, ArcGIS Server and Python I can be a gis (semi) developer, arcgis desktop specialist, gis engineer and a gis manager at the same time. I’m afraid something have to go if we are forced to swith to the JavaScript API.

    • roemhildtg says:

      Debugging Javascript isn’t as difficult anymore thanks to many built in browser debuggers. OP commented that these can be confusing to use, which may be true, however, there is still interactive debuggers built into IDE’s like Visual Studio, Netbeans, and others that debug the programs using connectors to modern web browsers.

      The biggest issue I’ve run into is lack of api documentation in certain areas, but that is getting better and better, especially with the dojo api.

  12. rgillain says:

    I understand that Esri prefer to no work on evolution of the slivelight API.
    But for me it’s realy a bad decision to not continuing with the Flex API.

    With my experience, the JS API is far from being at the level of the Flex API.

  13. mattias_j says:

    I’m not very surprised that this would come at some point, but still I am disappointed to hear this. It feels like it was not long ago ESRI promised that flex wasn’t going away (in this blog post).
    “We’re committed to providing the best technology for GIS developers and giving choices from the most widely used developer platforms in the market. By offering many options, we enable developers to address different customer needs and expectations. Our commitment is not based on a specific technology, but based on supporting the GIS developer regardless of the platform chosen.”
    “We’re committed to supporting Flash/Flex for the foreseeable future as many of our customers have successful deployments using it.”

    But it was november 17, 2011 and I guess that foreseeable future has passed now, even though I think it’s way to soon.
    In my opinion the JavaScript API isn’t ready to replace the Flex API yet, and I’m afraid switching to JavaScript will make it harder for GIS staff with some developing skills (like me) to build web applications. Neither will the desktop users (which our users are) get a better user experience.

  14. rixlabs says:

    Good news, but please give us something better than dojo…

  15. mike.s says:

    I am glad too. Finally ESRI can put more development resource on JavaScript API.
    Make it better ESRI!
    The following is one of the take-aways from 2013 dev-summit:
    Take-away 10: Going HTML
    More than 65 percent of the web developers who attended the DevSummit use the ArcGIS API for JavaScript. All JavaScript sessions were standing room only—clearly a sign, isn’t it?

  16. cnorth says:

    I’d like to echo the comments made by stepanoff. What is missing with the JavaScript API is a framework like the Flex Viewer. With that, I can add modular functionality to the viewer framework and get a solution in my clients hands very quickly and cost effectively. I’m building real tools for my clients, not just sexy one-off demos.

    With JS API as it stands, I have fuse together a bunch of stand alone samples written in a mish-mash of styles and approaches, and different UI standards. It’s too time consuming and I’m back to square one each time I start a new project. With the Flex viewer framework, I can focus on building a widget that drops into the viewer, and my development time is reduced, I can also grab third party widgets and either use the compiled SWF as is, or tweak the code. I don’t have the equivalent in JS.

    Couple all this with the browser incompatibilities, lack of a good IDE, and inability to compile my code easily, and JavaScript just isn’t as appealing as Flex right now. I get that a Flex doesn’t work on tablets. But anyone hoping the exact same app will work in a browser and on mobile us dreaming. You have to address the user experience specific to the platform.

    So, Esri take note. If you want to elevate the JavaScript API beyond snazzy toys, we need the JS equivalent the the Flex Viewer Framework. If this is the direction you’re heading with the JavaScript viewer, great. I really have no preference what API or language I use, however I do care about consistency and efficiency. But if this isn’t what the new JavaScript Builder is, then please continue to keep the Flex API up to date.

    Please don’t get caught up in the whims of going with what is ‘cool’. Think about how the technology is going to be used, and how best to solve those problems. I’m happy to switch to JavaScript. But it’s prohibitive without a framework.

    • detroit says:

      @Cnoth:
      As far as I know (acccording to last webinar I attended) there should be a JS app builder (if that is what you meant by Flex Viewer). I do not like those builders since they make me look redundant hehe. But yeah, as I heard demo of JS builder is due in March. You can build tools really quick just by knowing DOJO as well. I also understand the grief coming from the flex and silverlight devs since I started on silverlight and I kinda liked it, but ever since i moved on to JS (a year ago) it’s my favourite tool for anything web related.

      Chin up guys, JS/DOJO are really fun to use – coming from a “still” beginner

  17. thebillcarr says:

    Wish I knew this last month before I dumped so much time and money into flex. Oh well, it seems like the way of the future, so I’m on board. Flex is Dead? They said the same thing about punk rock. I wonder how that worked out.

  18. blynn says:

    Guess we have come full circle. My ArcIMS app was javascript and now my ArcGIS Server apps will be as well. Been from JS/HTML to ASP.NET Framework to JS API, to Silverlight, and finally back to HTML/JS – wow what a journey!! Funny how quickly technology changes. I remember standing room only (actually standing in the hall) at the ASP.NET Framework meeting my first year at the developer’s conference, standing room only at a Silverlight session about 4 years ago, and last year we were all back to the JavaScript API. Glad someone is keeping up! Thanks for the update and clarity on the strategy going forward.

  19. jeff.pace says:

    This is great news. ESRI did not kill flex and silverlight, the web community did. JS/HTML5 is the way of the future. I just wish this transition had begun earlier.

    As for dojo, don’t prejudge it. It is an excellent framework. I began using jQuery, and quickly abandoned it as dojo could do everything a needed.

    Plugin free for the win!

  20. geasand says:

    Like many others that have made comments, I find it discouraging that ESRI is effectively dropping support Flex & Silverlight. My development journey has been with Silverlight and like the Flex people I find it to be much more efficient at getting apps to the users. After attending this years Dev Summit and attending the HTML5 course I came away wondering why anyone would choose to develop in the chaotic JavaScript/HTML5 space. The HTML5 instructor presented stories of HTML5 features being agreed by the “Standards” group and being implemented in Firefox and Chrome and then within a month or so the HTML5 “standards” group changing their mind and the features being no longer supported. In one of the Dev Summit talks a fellow displayed a list with several dozen frameworks, IDEs, add-ons, hacks, etc etc. Crazy! Where does one start? In an HTML 5 talk I attended two years ago the statement was made that the HTML5 “standards” would not be finalized for at least 10 years, by design!

    Ah well, because ESRI is going with the currently perceived bright future I will tag along and start learning the stuff. No doubt it won’t be as bad as it currently seems but I do wonder if Flex and Silverlight will truly go away. Flex has been around a long time, has a large development community, and is still very prevalent in many web sites. Silverlight is a subset of WPF and Microsoft is carrying forth with that technology. Like the full circle from ArcIMS/Javascript to todays JavaScript API, I won’t be surprised if in a few years we are standing shoulder to shoulder in Dev Summit talks all about the new Flex and Silverlight gizmoids.

    Observations worth chewing on:
    1) If Apple had not blocked web browser plug-ins in iOS, would we be having this conversation? What happens if Apple decides to allow plugins to run in iOS?
    2) On my iPad yesterday I received the update to the Washington Post news app. Quoting in part from the what’s new description, “A faster app that’s easier to read …. we’ve switched from HTML5 to iOS’s native framework … better display … improved stability … fewer crashes …. smaller storage footprint”.
    3) The new ArcGIS Web App Builder – you can only get it if you have a license for ArcGIS Portal. Not free like the Flex and Silverlight Builders. Hmmmm (ChaChing $$$$$$$)

  21. dmuthami says:

    This is a good post that is very informative.