Should I Use Experience Builder or the Maps SDK for JavaScript?

JeffreyThompson2

You are someone with some level of programming/web development experience (For this article, I will assume you are at a pretty basic level, but I think this will be useful for experienced devs as well.) and you are about to start on building a new project. You have a good outline for what you need to build. The main question now is how. You need to pick a framework. Are you going to build your application in Experience Builder Developer Edition or in the Maps SDK for JavaScript (AKA: the JavaScript API)? This post is here to help you decide. I'm going to talk about the major concepts, features and issues in both frameworks. If I think it's a point in favor I'll use green text (+), negatives are in red text (-) and we'll stick to black text if it doesn't easily fit into a binary.

Experience Builder

Drag and Drop Interface (+) - The Builder that all the Muggles who can't code use to make their applications is quite powerful. The entire history of web development can be seen as an effort to write as little CSS as possible and this interface can handle most of your CSS needs. You may find you don't need to write any JavaScript either.
Rapid Prototyping (+) - Using the Experience Builder Build Mode, it is possible to make a functional proof of concept application in a matter of minutes. If you can't build it, well now you know you have some coding to do.
Maps SDK for JavaScript (+) - Everything that the JavaScript API can do can be done through Custom Widgets in Experience Builder. This post is just a false choice fallacy.
React - React is the most popular modern framework in the world and for some good reasons. But if you haven't used it (or a similar framework) before the learning curve is steep. Do you really have the time to learn a new framework right now?
Redux (+) - One of the things that makes React hard to deal with is strict one-directional information flow. Redux allows you to send Messages from one part of the application to another giving you much more flexibility. Redux is so woven into Experience Builder that many developers may have no idea they are using it.
Storybook (+) - The Storybook has a ton of pre-built, pleasantly designed UI elements. They are generally easy to use and while the documentation is far from perfect it is generally sufficient.
Bootstrap (+) - You also get Bootstrap classes to help with your UI. Many options. Easy to use. Great documentation.
Documentation of the Functional Bits (-) - The documentation quality for developers in Experience Builder is terrible. TypeScript is almost always the best documentation source and...
TypeScript - Technically, Experience Builder is not written in JavaScript. It's in TypeScript. TypeScript is a superscript of JavaScript that "strictly enforces" typing. (It does not.) Done correctly, TypeScript makes the IntelliSense built into your IDE much better. But Experience Builder typings are frequently wrong, which costs this point it's green text. If IntelliSense gives an error code starting with TS, ignore it and see if it works anyway. It often does.
Flexibility (+) - Want to make a single page map-centered application? You can do that. Want to make a hundred page application without a single map? Maybe consider a different framework, but you can do that.
Inflexibility (-) - Don't want to make an application using TypeScript in React and put it together in a Drag and Drop Interface? Then, get out of Experience Builder. Does this directly contrast with the last point? Yes.
Easy Set-up (+) - Click one button and start building in Node.js, React, Redux, Maps SDK for JavaScript...
Heavyweight (-) - Node.js, React, Redux, Maps SDK for JavaScript... Sounds like a lot of stuff because it is. Experience Builder is a bloated framework and its not easy on your network, hosting server or end-user's computer. You're driving an 18 wheeler, not a Ferrari.
Dynamic Content (-) - Let's say you had a list of 1000 Feature Layers and you needed to generate a page and map focused on each of them. Could you do it? Maybe. But not well. And you'll probably need a lot of custom code.
Responsive Sizing - Experience Builder has three built in screen sizes to handle responsivity. Front-end devs know that really isn't enough, but there really isn't a mechanism for making more breakpoints.
Breaking Changes (-) - Are you expecting to update your application and keep it fresh through product updates? Experience Builder inherits all the breaking changes of React and the JavaScript API and more! And the Experience Builder Team likes to move stuff around and rename stuff, just for the fun of it. Be prepared to fix stuff every single update.
Overall Coding Experience (-) - Between needing to know React and the JavaScript API, the issues with responsiveness, constant breaking changes, and the lack of documentation, coding in Experience Builder is not much fun, especially for beginners. It does get somewhat easier and more fun after you've built a few dozen Widgets, but not much. @Jianxia, I cannot stress enough how much documentation counts in this category.

Maps SDK for JavaScript

It Makes Maps - It makes maps and a few related things like tables and editing tools. That's it. If that's all you want, it does that. If you want to put something else on the page or make it look nice, you will need something else to do the job.
Flexibility (+) - It's up to you to pick what components you use with the JavaScript API. Want to use React or Vue or Angular? Sure, you can do that. Want to write raw HTML? You're a madman, but no one is stopping you. My first big project was in Django, which is a Python based framework. I had Python, JavaScript and HTML all happily (and grossly) co-existing on the same page.
Lightweight (+) - Because the JavaScript API only does one thing, it's much lighter weight than Experience Builder and it's pretty easy to pop into some other framework.
No Easy Set-up (-) - Well, you wanted to make a Django/React/Material-UI stack. So...you have to make it.
Components (+) - What if you could just write one line of code and have a fully functional Legend on your map? That would be pretty neat. That's what Components do. (Or Widgets, but you really shouldn't be using Widgets anymore. They are going away.) Hey, that sounds a lot like Experience Builder Widgets. Because they are and many Experience Builder Widgets are little more than loaders for JavaScript API Widgets/Components. If you are building a simple application, you may find Components can do all the work for you. Oh, and part of the reason Components are replacing Widgets is that Components are better designed to work in React-like frameworks.
Calcite (-) - Another part of switching to Components is to encase everything in Calcite. And unfortunately we are not talking about CaCO3. Calcite is ESRI's official UI design system. Working in the Maps SDK for JavaScript, you are expected but not required to use it. But it's going to get in your application whether you like it or not. I find Calcite confusing to use, it makes traditional CSS targeting impossible and the documentation is obtuse. Personally, every time I have tried to design something in Calcite, it has come out at least somewhat compromised. And, I don't think it looks all that good either. Calcite is getting into Experience Builder, too. But, you are at least one more step removed from it and you have the far superior Layout Widgets and Storybook to pull from to build your UI. If I could drench Calcite in 0.1 molar HCl and watch it slowly fizz away, I would.
Documentation of the Functional Bits (+) - The general quality of the JavaScript API is excellent. The properties and functions are clearly explained and there are many examples, even for some fairly complex builds. Although, they need to do some work to get the Component side of the documentation up to their overall standard.
Secret (+) - There is at least one thing you can do in the JavaScript API that can't be done in Experience Builder and it's Secret. I am not allowed to tell you what Secret is. Please do not ask about Secret. But Secret is a really good reason to pick the API over Experience Builder.
Dynamic Content - I can't give the JavaScript API green text on this because it can't really do dynamic builds on it's own, but with just about any modern framework, you can make it happen pretty easy.
Responsive Sizing - See above. There isn't anything in the API specifically to help you make dynamic screen sizes, but there isn't anything stopping you either.
Breaking Changes - Yeah, the JavaScript API team breaks stuff pretty often, Calcite and Components are causing a lot of issues, but at least they change stuff for a clear reason and communicate changes well. They're even changing the numbering system, so they can tell you when they're going to break stuff.
Overall Coding Experience (+) - Your milage may vary, but overall, using the JavaScript API is a fairly pleasant experience. There is a fairly low barrier to entry and the learning curve flattens out pretty fast.

Ultimately, I can't tell you which framework is better. The answer will depend on your goals and ability, but here is a workflow:

Think about what you need your final project to do and look like.
Have an honest conversation with yourself about your coding ability, capacity to learn, and time (or any other) constraints.
Try an Experience Builder prototype, no code yet. If you hit a wall early, maybe switch to the JavaScript API. If the wall comes near the end, try sticking it out in Experience Builder.