Every ExB power user knows the moment. You're 80% done and the last 20% is impossible. Not hard — impossible. The configuration surface just ends. There's a wall and you're standing in front of it.
I spent years assuming that wall was the limit of what I could build. It's not. It's the limit of the no-code layer. The actual ceiling is much higher.
What the ArcGIS JavaScript SDK is
Esri built Experience Builder on top of something. That something is the ArcGIS JavaScript SDK — the full toolkit that powers Esri's own products. It runs inside any webpage. A single HTML file. No server. No npm required. Any map, any layer, any interaction you can describe, with no ceiling.
Same AGOL org. Same OAuth tokens. Same private layers. Same security policies. Nothing under the hood changes. You're just driving the engine directly instead of through the configuration layer.
The catch was always the learning curve. A 500-page API surface. Async initialization order that breaks in non-obvious ways. Edge cases in null handling, mobile sizing, popup timing. Years of accumulated complexity that kept it in the hands of full-time developers.
That catch is gone.
A brief history
The ArcGIS JavaScript API launched in 2007. It was powerful, complex, and designed for specialists.
Version 4 arrived in 2016. Still powerful. Still specialist-only. The kind of thing organizations hired a developer for.
Then AI happened. The SDK didn't change. Its complexity didn't shrink. What changed is who gets to use it.
Where Experience Builder actually stops
Six walls I've hit personally, repeatedly:
Widget config is fixed. The last 20% — the thing that would make it right — is always behind the wall. You can feel it. You know what you need. You can't get there from the config panel.
Dashboard round-trips. Data in a Feature Layer. Dashboard references a Web Map that references that layer. Change anything, update the chain. Every time. For every change.
Large datasets freeze the browser. Load 50,000 features client-side in EB. Watch it pause. The SDK has server-side pagination built in. EB doesn't expose it.
Custom interactions require React anyway. Click event that updates three things at once. EB's widget interactions are limited. You end up in the custom widget SDK — which is a full React + webpack development environment. You've gone around the long way.
Branding is Esri's, not yours. Theme settings get you part of the way. Not all the way. The template is the template.
Embed auth is painful. Preview URLs behind auth gates. CORS issues that appear without warning. Getting a thin HTML app talking to AGOL from inside an EB iframe requires specific patterns that aren't documented in one place.
What changed
Describe the map you need. AI translates it into complete, working SDK code. Not a snippet — a deployable file that opens in a browser.
The SDK is as complex as it ever was. Every class, every async initialization order, every edge case — all still there. What changed is that you don't need to hold that complexity in your head. AI holds it. You describe outcomes.
A prompt structure that works consistently:
- Name the toolkit and version: "ArcGIS JS SDK 4.29"
- Describe the data: "US county disaster counts, hosted Feature Layer, item ID X"
- Describe the visual: "choropleth, 4 class breaks, red color ramp"
- Describe the UI: "dark basemap, legend bottom-left, click popup"
- Describe the constraints: "single HTML file, no npm, AGOL OAuth"
What comes back is a file. You open it. It runs.
The thin HTML pattern
The deployment model is the part nobody talks about.
- Describe what you need
- Get complete working HTML
- Rename to
index.html - Push to GitHub
- Connect to Vercel
- Live URL in under 8 minutes
Why Vercel over GitHub Pages: the URL. something.vercel.app reads as a product. franzenjb.github.io/something reads as a personal project. Same code. Different perception. In organizations that evaluate tools by how they look before they look at what they do, this matters more than it should.
That URL is an iframe. It embeds in SharePoint, Confluence, Teams, or Experience Builder via the Embed widget. Add ?arcgis-auth-origin=https://experience.arcgis.com when embedding in EB — this passes the SSO token and eliminates the second login.
Security — nothing changes
This is the first question in every GIS org. Is this approved? Is this secure?
The security model is identical to everything else in your Esri environment. OAuth 2.0. No credentials in code. Private layers stay private — governed by AGOL sharing settings, the same as always. Your ArcGIS Online license covers this. There's no additional licensing to use the SDK.
I'm hyper security-conscious — every tool I build assumes breach and minimizes blast radius. The thin HTML pattern is the most secure architecture I've found: no server, no database, no credentials at rest. The attack surface is the auth layer that Esri maintains.
Speed
| Task | Before AI | With AI + SDK | |------|-----------|---------------| | Custom choropleth with popups | 2 days | 25 minutes | | Full layout control, ExB-style | 4 hours | 20 minutes | | Live query dashboard (no Web Map) | 3 hours | 1 conversation | | Embed in SharePoint with auth | Half a day | One HTML file | | Custom popup with conditional logic | 1 hour | One prompt |
These are real numbers. Actual projects built at the American Red Cross.
Who this is for
You don't need to be a developer. You need to be able to describe what you want.
If you've spent years in Experience Builder, you already understand layers, popups, filters, queries. That domain knowledge is exactly what the prompts need. You bring the GIS expertise. AI brings the SDK.
The SDK hasn't changed. The security hasn't changed. The data hasn't changed.
What changed is who gets to use it.
Next: The Lego Principle — How Modern GIS Tools Actually Fit Together