Because there are other options available that might be better? Personally I'd chose Clojure for anything I have a choice with. Cargo culting a language like that does no one any favors.
I dunno, HTTP works pretty well for me as a transport layer to communicate with clients. Otherwise Websockets. Not sure why you'd think that be a difficult thing?
> Not sure why you'd think that be a difficult thing?
You aren't suggesting to handwrite an HTTP API client, right? You would have to set up either OpenAPI which is a mess, or GraphQL which is also a mess. LMK if you have a better solution.
What exactly is the problem you're encountering when trying to interact with HTTP APIs? If you really want to use OpenAPI for whatever reason, there are plenty of ways of doing that even in Clojure/Java, so I'm sure it's possible in other languages as well. But it's not like using OpenAPI or GraphQL are the only two options, if you're of that opinion I'm afraid you've drank way too much of the koolaid.
> when using HTTP APIs, there is nothing that automatically generates bindings.
Is that really the biggest problem you face when programming? How many endpoints do you have? Even with projects with ~30 endpoints, it doesn't seem problematic to me, but maybe people regularly work on projects with 100s of endpoints, then it kind of makes sense. But I'm not sure that's typical enough.
> No, I don't. But people use OpenAPI to avoid having to handwrite an HTTP client. This is especially relevant if you are developing a public API.
People do a lot of stuff for a lot of nonsense reasons, doesn't mean that's the best way to approach things. The JS/TS ecosystem seems extra easy to fall into cargo culting too.
Yes, you have to waste time handwriting it and making sure that you actually wrote a proper binding. Then you also probably need to deal with API versioning. All of this goes away with server actions.
