IDK what you mean by "deal with OpenAPI", OpenAPI is a spec not a technology like graphql.
In all honesty (and sorry for the directness), you don't really seem to understand these concepts and how relevant or not they are to this conversation
It's a JS framework thing. Every mainstream JS framework has server actions or equivalent.
> Having a wrapper around HTTP isn't really a compelling reason to choose a technology for the very large majority of people: probably the opposite actually.
It is way more convenient to write a server action and be able to immediately use it in a client component than having to write an HTTP endpoint in a separate back-end project, and then regenerate your client via OpenAPI, or whatever else you use.
> IDK what you mean by "deal with OpenAPI"
I mean dealing with tooling to generate an HTTP client from OpenAPI schema.
> In all honesty (and sorry for the directness), you don't really seem to understand these concepts and how relevant or not they are to this conversation
Wrong
No. "Server actions" are a React concept, it has little to do with backend technology (the backend still speaks HTTP). This concept is completely irrelevant to most big frameworks like Express, NestJS, Koa, Hapi. Next is barely a "backend" framework: it's rather a React server framework that has a few basic backend functionalities.
Yes, there is nothing that works better than server actions. None of what you listed really makes sense to me. I have never had any runtime performance problems with TypeScript and wasn't JavaScript the most popular programming language in the world (the talent pool argument)?.
And then you would have to solve the problem of how to communicate with the client.
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.
The problem is that, unlike when using server actions, when using HTTP APIs, there is nothing that automatically generates bindings.
> If you really want to use OpenAPI for whatever reason
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.
> But it's not like using OpenAPI or GraphQL are the only two options
What are other options?
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.
What do you mean by this?
Add a route on the back end.
RPC means just call it! don't worry about REST, GQL etc.
"Vibe coding" as a concept is a fun joke, not a workflow you employ for doing serious engineering. It was a tiny experiment that somehow people thought was a suggested way of developing software, which obviously it isn't. Read the code yourself, otherwise it'll be really hard to call yourself any sort of engineer.
Well I guess making Next.js apps isn't really "serious engineering"
> Read the code yourself, otherwise it'll be really hard to call yourself any sort of engineer.
I do read the code but I barely write any code by hand.
Where did I say that?
> I do read the code but I barely write any code by hand.
Right, so you use the words "vibe coding" yet you don't actually understand the concept? A lot of things make sense now. The description "vibe coding" is explicitly about "programming" with a LLM without reading or writing any code at all, for any purpose. If you read the code, you're not really vibe coding as originally described by Karpathy.
You replied to a comment that says "Yep, Next.js has the best support for vibe coding."
> Right, so you use the words "vibe coding" yet you don't actually understand the concept? A lot of things make sense now.
You can stop arguing that if one glances at the code one is no longer vibe coding, because in practice by looking at the code or even the LLM's thoughts you can catch things you don't want early.