ArcGIS Javascript API for client apps?

I develop web maps and applications for clients that do not currently have an Esri account nor do they wish to invest in the platform. The majority of my maps have been created using Leaflet since it does not require any type of licensing. However, with the introduction of the revamped ArcGIS Developer programs is the ArcGIS API a viable alternative to Leaflet? Or is the ArcGIS API only suitable for Esri platform users. Having trouble grasping how this works. Any insight is greatly appreciated!!

As far as I know there's nothing stopping you from creating applications with the JS API using either the esri-hosted source code or downloading the source code from the developer site and hosting it yourself. A caveat here is that the source code is only publicly distributed in a minified form.

My feeling is that the JS API is suitable for client apps, although the majority of developer users seem to be Esri platform users. If you use the API this way, you'll be using Esri's public (and free) basemaps. Apparently these basemaps do have a request limit, but for most users 50 million transactions per year is probably fine.

Everything else can be done in the client, like adding graphics (features) and layers, handling user-input, click events, and so on. The API also includes a geometry engine that contains some helpful functionality, all performed in the client.

One pitfall I could see is that a lot of the widgets in the API rely on an Esri back-end. For example, the geocoder will make requests to the ArcGIS Online geocoder. Parts of this service are free, but parts are not (more information).

If you can explain a little bit about what kind of functionality you're looking for I can go into more detail.

Thanks for the quick reply Thomas and thoroughly addressing my question. I've always had the inclination to think that the JS API would be suitable for client apps. Client functionality can very greatly based on the end-users requirements ranging from basic point or thematic maps to others which rely on back end geoprocessing. However, if one of my clients required back end functionality couldn't I just sign them up for a developer account which would allow them to purchase credits if and when needed?

Also, do you have any recommendation as to the best resources to learn more about development for client facing apps? I know that Rene Rublecava is in the process of writing a book for the ArcGIS 4 API, but wasn't certain if it was focused more on server development?

However, if one of my clients required back end functionality couldn't I just sign them up for a developer account which would allow them to purchase credits if and when needed?

My feeling is yes, although I don't know a lot about the credit system having never used it.

Also, do you have any recommendation as to the best resources to learn more about development for client facing apps? I know that Rene Rublecava is in the process of writing a book for the ArcGIS 4 API, but wasn't certain if it was focused more on server development?

Looking at the table of contents, it looks pretty client-focused. It should be since the subject is the JS API.

I would say that client-based app development should be similar to app development with the API in general. The caveat is pretty straightforward: layers and graphics need to be constructed in the client, either from user input, or from third party servers that will be accessible from wherever your app is hosted. (For example, lots of cities have APIs that share transit information. It would be easy to use these services to add symbols representing buses to a map and poll/update every 5 seconds).

My general impression is that the Esri JS API is more complicated, but also more powerful, than other JS mapping APIs. If you're not familiar with promises, the 4.XX version is hard to pick up. Some selling points are the free world-elevation layer, 3D maps, multiple views of the same map, and the geometry engine (which lets you do a lot of things in the client that might ordinarily be done on a server).