jQuery supports a feature called promises. The idea being that you have have a number of actions pending like multiple API calls and get an action implemented when they are all done. I think this is an example of letting edge cases complicate a core simple design. I have never written code that has required the promises feature of jQuery. I find the concept confusing and I think it adds to the complexity of code.
When my team was porting our code away from using jQuery to using the new code to call apis the question came up about what to do with the code that was using promises for chaining several API calls. Looking at the code together it became obvious that each usage was typically signaling an underlying design problem with the code. For example
There was permissions checking code at one point where the design was to check if a user has the permission to do something before calling an API that needed permission for. But this was a problem because a hacker could call the API directly and bypass the permission.
In other projects I have seen people use promises to get a template and some data and combine the results together. The design problem to be solved there is a better way to get templates to eliminate this complexity.
Getting ID of the “primary node” before sending information to it. This is really an implementation detail of the backend which shouldn’t be something the front end is dealing with.
In conclusion I would say it’s really good thing not to have a Javascript library which supports promises. It’s an example of not letting edge cases complicate a core simple design. Your code is simpler and faster without them.