ArcGIS JavaScript API 4.0 Out of Beta

Nothing fills a developer’s mouth with words of both praise and cursing more than a major version release (Just ask the Angular JS community). ESRI released the ArcGIS JavaScript API 4.0 out of beta yesterday. If you’ve had experience with the 3.x version, a tour through the 4.x line looks a bit incomplete, much like the second Death Star in Star Wars VI: Return of the Jedi. But don’t be fooled, this new version is a fully operational API.

ArcGIS JavaScript API 4.0 as a Death Star

What’s New in the ArcGIS JavaScript API 4.0?

The big attraction to the ArcGIS JavaScript API 4.0 library is the support for 3D maps. The library takes advantage of a lot of WebGL technology found in modern desktop browsers to deliver a rich user experience. Not only can you spin a globe in your browser, but you can also render both 2D and 3D assets on the globe, giving users a good idea what a new building, park, or construction will look like.

The ArcGIS JavaScript API 4.0 library is Promises driven. That means that maps, layers, and other modules created in the API will return promises that will run whatever code you tie into them when they have been completely created. You no longer have to test whether a map or layer has been loaded before you interact with it. You can create a map, and call map.then() with a callback function that will run when the map is loaded… and it works.

The API also provides views and viewmodels for interacting with the application through JavaScript. For those not familiar with MVVM or MV* architectures, viewmodels are the code that pulls data from data sources (a.k.a. models), and manipulates them so they can be presented in your views. For an example, you can create an ArcGIS Online Web map as a model, create a 2D WebMap and a 3d WebScene as viewmodels for that model, render a 2d MapView and a 3d SceneView, all from the the same map.

What’s Missing in the ArcGIS JavaScript API 4.0?

The big thing missing is all the dijits, or the built in user controls that come with the 3.x API. This is a mixed blessing. The dijits used in the 3.x version made operations like editing, measuring, and printing easy. However, they relied heavily on Dojo UI components, which rely heavily on other Dojo UI components and CSS styling. They made your life easier IF you were willing to play by their rules.

From what I saw at the ESRI Developer Summit, the 4.0 API focused around giving you the code-behind access to the operations typically handled by the dijits, and let you develop your own user controls. If you are in a development shop that uses Angular, you can use Angular without worrying if it plays nice with Dojo Dijits. If you work with React, you can create React components that work with the API. You’re responsible for your user interface, and to me, that’s a good thing.

There are a few other features and functionality not released yet into the ArcGIS JavaScript API 4.0 version. Dynamic map service layers (now called MapImageLayers) aren’t time enabled, don’t support dynamic layer reordering, and don’t disable client caching. FeatureLayers don’t support editing at this time, though Rene Rubalcava has provided a handy post on how to implement editing on your own. Also, printing web maps isn’t supported yet.

Which side will you choose?

ESRI provides a solid roadmap to help you choose whether you should migrate to 4.x now, or stay with the 3.x line. They tell you what features are available now, what features will be available down the road, and what features they probably don’t want to support any longer. They plan a few more updates on the 3.x API, and will continue to support it for a couple years.

ESRI supplies a simple decision tree to help you decide which API line you will support. I would like to expand on that a bit.

  • If you need to use 3D maps, go with the 4.x API
  • If you are dependent on existing dijits in your applications, stay with the 3.x API
  • If you primarily work with other JavaScript frameworks like Angular, Ember, or React, go with the 4.x API
  • If you require features only found in the 3.x API, and don’t want to rebuild them for the 4.x API stay with the 3.x API
  • If you still need to support IE8… God have mercy on you (and stick with the older 3.x API).
  • If you’re willing to get your hands dirty creating UI components in your web mapping applications, go for the 4.x API

May the force be with you.