概述
当我既写了esri-loader方式来进行ArcGIS JS API的开发文章，又写了@arcgis/cli脚手架的方式来进行ArcGIS JS API的开发文章之后，相信很多小伙伴看到后会产生“选择纠结症”，我到底该用哪种方式来进行ArcGIS JS API的开发呢？不要着急，我给你一个可供选择的参考，简单又实用：
- 如果项目已经在进行实施，中途可能需要用到ArcGIS JS API中的相关功能模块，那就选择esri-loader方式；
- 如果项目并未开始实施，但是后期会有ArcGIS JS API中的相关功能需求，推荐使用@arcgis/cli脚手架，当然，你也可以用esri-loader方式。
既然有两种方式可供选择，那我们简单来看下这两种方式的优势与不足。
相关测评内容
1、实际项目实施方面
根据文章开始所说，如果项目已经在实施，我们只能通过esri-loader方式来进行JS API的开发，因为此时JS API算是后期才引入到项目中的，我们的项目可能并不是一个整体的GIS项目，GIS相关功能模块只是系统中的一小部分，所以我们就没必要用@arcgis/cli脚手架构建一个完整的基于WebGIS框架的项目，这样会影响系统应有的架构，使系统架构的健壮性大大降低。
如果项目并未开始启动实施，并且明确知道此系统后期会有JS API的相关功能需求，而且此项目系统中GIS相关功能模块所占比重较大，那推荐使用@arcgis/cli脚手架来构建项目系统框架，因为我们可以看到，通过脚手架构建的项目应用中代码组织结构非常优秀，并且基于Webpack配备了完整的主流系统构建工具和代码检查工具。
2、主流技术方面
通过esri-loader方式进行JS API的开发时，其实我们很多情况下还在使用ES6甚至ES5的编码方式进行系统开发，项目系统中所用的各种主流插件是我们主动性地去增加配置的，换句话说，如果你不知道有什么主流技术，那你还是一直在啃技术老本，项目系统中并未引入主流的开发技术。
@arcgis/cli脚手架方式可不一样，它默认在你的项目代码中配置了Eslint、babel等主流插件，并且最重要的是，它的项目代码是用TypeScript来编写的，所以从这几点来看，脚手架方式开发JS API的过程中，所用到的开发技术是比较靠近现阶段主流开发技术的。
3、编码方式
esri-loader编码方式如前面所说，你可能在用ES6或者ES5在进行系统开发，然后我们JS API中的各个功能模块还是用基于Dojo的AMD方式来加载，并且实现全局引入加载很困难，代码如下：
// 创建二维地图
_createMapView: function() {
const _self = this;
const option = {
url: gConfig.arcgis_jsapi_hosturl + 'init.js',
css: gConfig.arcgis_jsapi_hosturl + 'esri/themes/light/main.css',
};
loadModules(['esri/WebMap',
'esri/views/MapView',
], option)
.then(([WebMap, MapView]) => {
// 实例化地图
const webmap = new WebMap({
portalItem: {
// autocasts as new PortalItem()
id: gConfig.largeScreenWebMapID,
},
});
const view = new MapView({
container: 'mapViewContent',
map: webmap,
zoom: _self.mapviewLevel,
center: [102.714408, 25.043706],
});
}).catch((err) => {
_self.$message('底图创建失败，' + err);
});
},
// 创建三维地图
_createSceneView: function() {
const _self = this;
const option = {
url: gConfig.arcgis_jsapi_hosturl + 'init.js',
css: gConfig.arcgis_jsapi_hosturl + 'esri/themes/dark/main.css',
};
loadModules(['esri/Map',
'esri/views/SceneView',
], option)
.then(([Map, SceneView]) => {
const map = new Map({
basemap: {
baseLayers: [tiledLayer],
},
});
const view = new SceneView({
container: 'mapViewContent',
map: map,
camera: {
position: [102.492874, 25.236805, 500000],
heading: 0,
},
zoom: 7,
});
}).catch((err) => {
_self.$message('底图创建失败，' + err);
});
},以上代码可看到，我们通过loadModules来引入了JS API中所需的功能模块，而且以上代码是在一个组件中的，可以看到第一个方法中为了创建一个二维地图，我们用loadModules引入了相关的功能模块；第二个方法中为了创建三维场景，我们又用loadModules再次引入了所需的模块，这样在编码方式上就很繁琐。换句话说，如果我们在什么地方要用JS API中的模块，那我们就要在相应的地方用loadModules引入所需的模块。
@arcgis/cli编码方式解决了这一恼火的问题，我们可直接在组件代码顶部引入相应模块，然后在下面的代码任意地方使用它们，示例代码如下：
import ArcGISMap from 'esri/Map';
import MapView from 'esri/views/MapView';
export default {
name: 'web-map',
mounted() {
const map = new ArcGISMap({
basemap: 'topo-vector'
});
this.view = new MapView({
container: this.$el,
map: map,
center: [-118, 34],
zoom: 8
});
},
beforeDestroy() {
// destroy the map view
if (this.view) {
this.view.container = null;
}
}
};以上代码可看到，我们只需要在组件代码顶部引入此件组所需要的JS API相应的模块，然后在下方的代码任意位置都可以使用此模块，就没有必要每次都通过Dojo的模块化加载机制来加载了。
4、项目启动运行和打包部署方面
esri-loader方式开发JS API项目系统后，如果我们不对项目进行相应的配置，基于Vue框架的项目和基于React框架的项目启动命令是不同的，它们的打包命令却是相同。
@arcgis/cli脚手架创建的项目应用，不管是基于Vue还是基于React，启动命令相同，打包命令也相同，所以更加的友好。
两种方式创建的项目，打包后部署流程一致，并无相关的差异。
5、其他方面后续遇到后再更新……
总结
就目前四个方面的简单测评来看，如果是一个还未进行实施的项目，并且其中GIS相关功能模块占比较大的情况下，推荐使用@arcgis/cli脚手架方式搭建项目框架，具体coding感受，只有自己去体会一番了。作者力荐@arcgis/cli脚手架方式。
