How to Tame your Web App - The Plan

Blog Post created by jpeterson-esristaff Employee on Mar 7, 2017
First, a couple links:

Crowdsource Reporter Repo:

My Migration Repo:



In this blog series, I go through the process of “migrating” an existing Dojo/JSAPI app to use a more modern tooling infrastructure. I did this for real, then wrote about my experience. I added in ES6 (including modules), Webpack, ESLint, Babel, and a few other goodies. If you want to skip my write-up and just look at the code – go here.


Since I'm a *GIS* developer...

I have to throw some geography around. I enjoy exploring new places in the real world just as much as I love exploring new ideas in web development. Each post in this series is going to have a destination. I'm gonna share photos I've taken there. It's gonna be sweeeet.


Today's place: Paris

Header: Paris from the terrace rooftop of Printemps Haussman.


Eiffel Tower

The Eiffel Tower


What's the point of this?

Web development is full of rainbows and unicorns these days. While attending conferences, reading blog posts, and scrolling your social media feed, it’s easy to get excited about the new ideas being implemented in our industry. Unfortunately, a lot of us who get excited by these ideas go back to our offices and must deal with more pressing matters; maintenance, deadlines, profitability, clients... the list goes on.


Adopting new ideas into one’s workflow is difficult – it requires a real effort, and there is always the possibility that it just won’t work. Most of us decide we’ll try something new on that next app. The promise of a more streamlined workflow is worth the risk. The reason I went through this exercise (and documented it) is because I think adopting modern tooling is a worthwhile endeavor, and I hope this will help give someone the inspiration to take the plunge.


One last note on the point of this exercise. This post was created as a companion to an Esri International Developer Summit technical session with Gavin Rehkemper in March 2017. We love tools and the modern web development ecosystem so much that we talk about it every year at Dev Summit, but we’ve received feedback that while people get excited by our talks, there is a large gap between some of the things we talk about and the “real world problems” people go home to. Hopefully this post will bridge that gap so everyone can take advantage of the modern web.


Grand Arche

La Grande Arche de la Défense (my favorite Parisien arche)


Aren't you just hyping this year's crop of shiny objects?

I hear this concern a lot. I pontificate about the modern web quite often – to ArcGIS users, to my Esri coworkers, sometimes even to my dog (if only he would embrace tree-shaking). There is a lot of negativity surrounding the proliferation of tools and frameworks on the web. While I empathize with the point being made there, I see this explosion of new things as a sign of progress. Sure, the waters are muddied, but it’s important to remember that these tools and frameworks (or at least the good ones) are aiming for the same target: to make the web a better place for both developers and users.


Anyway, the point I’m trying to make is that you shouldn’t get distracted by the names of the hottest new tools and frameworks. Rather, try to see through the kitschy names and shiny websites to the fundamental progress being made; things like writing idiomatic JS, faster websites and apps, a more efficient development cycle. Also try to remember what you’re doing – if you are building a robust web-GIS application, that is a far different endeavor than making a content-driven website, so you can ignore the folks yelling about how everyone is over engineering the simplest websites.


The LouvreThe Louvre


Get to the goods, what did you actually do?

I chose Esri’s popular Crowdsource Reporter web app for this exercise because it is a well-written Dojo/JSAPI centric application that is like those belonging to many Esri customers I have worked with. It is a medium-sized application that doesn’t use many tools (i.e. no build system, CSS Preprocessors, linting, etc), so it provides a relatively blank slate to work with.


My plan was to modernize the toolchain used with this application with a twofold goal: (1) make the developer experience more efficient and (2) optimize the user experience by increasing performance.


By “modernize”, here's what I mean:

  • Migrate from AMD to ES6 modules, and sprinkle in some other ES6 syntax
  • Add a module-bundling system (Webpack) to optimize everything the client’s browser will have to download
  • Implement intelligent linting (error-checking)
  • Branch our build workflow so that we can achieve the best possible developer experience while maintaining the most optimized production version of our app
  • Maintain support for legacy browsers


I did my best to approach this effort one piece at a time. I went through the whole process in a git repository, and mirrored the list above to Pull Requests. If you want to correlate the list to the actual commits I made, here’s a good place to start.


This was originally intended to be a single blog post, but I quickly realized that post would be way too long. So I made it a series instead. Here's how I ended up breaking it down:


  1. The Plan (you are here)
  2. ES6 and Modern Modules
  3. Module Bundling 101
  4. Module Bundling 201 - Optimization
  5. Linting
  6. UX and DX: The Best of Both Worlds
  7. Legacy Support - coming soon


If you’re ready to dive in, head to the second post in the series: ES6 and Modern Modules.