@arcgis/core build is unacceptably big using ESM modules

[D_R_]

Good afternoon,

I have made quite a few ArcGIS API for JavaScript, OpenLayers, Leaflet apps before and I was always happy with their output size (often few hundred kB, rarely above 1 MB).

A week ago I was "forced" to work with `ArcGIS Maps SDK for JavaScript` using ESM modules.

All I used was just:

import Basemap from '@arcgis/core/Basemap.js';
import Map from '@arcgis/core/Map.js';
import MapView from '@arcgis/core/views/MapView.js';
import TileLayer from '@arcgis/core/layers/TileLayer.js';
import * as intl from '@arcgis/core/intl.js';

I made app build with Vite.. And I see that app is about ~ 6-7 MBs. Why is it sooo big? It is just a simple app which has a simple map div with TileLayer...

Is this a new norm for ESRI web apps to weigh so much? Are there any techniques to reduce this weight, to shake unnecessary stuff?

All I could find was YT video "Quick look at custom builds with ArcGIS JSAPI" by Rene Rubalcava, but it doesn't help...

[AndyGup]

The ArcGIS Maps SDK for JavaScript offers significantly more capabilities. At runtime, your application will only load a portion of the on-disk bundles depending on which @ArcGIS/core modules are used in your project. More info: https://github.com/Esri/jsapi-resources/tree/main/esm-samples#bundle-size-and-performance.

[D_R_]

Thank you for reply.

I see my app loads https://js.arcgis.com/4.29/@arcgis/core/assets/esri/geometry/support/pe-wasm.wasm file which is almost 3 MB. Is this file really necessary for a simple app with a simple map with one simple TileLayer in it??

So you don't see there a problem that a simple app with a simple @ArcGIS/core map weighs more than 6 MB, right?

[AndyGup]

@D_R_  can you provide a simple codepen, GitHub repo or StackBlitz?

The presence of the wasm file is related to something in the app doing client-side spatial reference conversions. I'm guessing the TileLayer is triggering the API to load the projection module. The size of that module is a known issue that we are working on. A hello world map app using a web mercator basemap doesn't load that module, for example: https://developers.arcgis.com/javascript/latest/sample-code/intro-mapview/live/.

[D_R_]

Thank you.

Hmm.. Maybe my problem is related with Vite itself or Nuxt I use 🙂

Here is my repo: https://github.com/denisrom88/nuxt-3-arcgis-core-build

Just try to build that app and access it in web browser. It seems that too many dependencies are loaded and I don't understand where is the problem as my app is very minimalistic 🙂

Do you see a problem there or no?

[AndyGup]

Thanks for providing the repo. We don't see any problems.

Since the app contains a framework (Nuxt), it doesn't quite qualify as a vanilla JS implementation, even though its only using hello world map functionality. The framework does create and consume additional files. The application is initially loading1.8 MB (Gzip) of JavaScript which includes both ArcGIS JS SDK and Nuxt/Vue. The on-disk build output of 11 MB includes 2.3 MB of Nuxt. Also, since Vite uses Rollup for production builds, the on-disk build size and main bundle size are some of the most optimized bundler outputs that we track.

We compare those stats to our stand-alone Rollup sample app which has a main bundle size of 1.29 MB and on-disk build size of 7.56 MB. That can give insight on the amount of overhead created by a framework. More information on how and why these values can vary is available here: https://github.com/Esri/jsapi-resources/tree/main/esm-samples#bundle-size-and-performance.

To recap, the performance metrics we track include:

- Initial application load - we make a distinction between JavaScript/CSS/HTML files, and service request data (e.g. tile and query data).

- on-disk build output - most of these files are not used on initial load. We do monitor and take into consideration the main bundle size, as well as the size and number of total bundles.

[D_R_]

Thank you a lot!

My "metrics" (fresh app load with empty browser cache) can be seen in esri.PNG attachment.

Please compare it with the same basic map, made with Openlayers... (ol.PNG)...

Openlayers is so light and so fast in that simple scenario.

Why ArcGIS Maps SDK for JavaScript must be so fat and heavy in that simple scenario? Any plans to improve it? If no, sadly, but Openlayers is much more tempting for simple maps when bandwidth is an issue...

-

Also please look at unnecessary.PNG

Why are these libs loaded at all if I created just a simple Map with simple basemap in it. No indications from my code that I will ever need a Popup or FeatureLayer...

-

Regarding excessive https://js.arcgis.com/4.29/@arcgis/core/assets/esri/geometry/support/pe-wasm.wasm -> Yeah, maybe it was loaded because TileLayer's service was in another spatial reference (3346)... Not an excuse to load this monster 🙂