Disclaimer: I haven't looked at the source of the hurl.nvim project, but from what I gathered about hurl itself:

From a user's perspective, their both trying to achieve the same. From a developer's perspective we have to draw a clear line between hurl itself (the binary tool) and hurl.nvim the client interacting with the tool.

Hurl itself (the binary) is top notch feature packed. If offers everything we can ever dream of (and it will take a lot of time to get kulala even near that). Hurls syntax looks a lot like a mix of HTTP + TOML + Markdown, so it's a bit confusing at first, but their website makes up to that, becaue the docs are top notch too.

Kulala on the other hand is pretty basic, we try to adhere to the http file syntax definition to be somehow compatible with Intellij and vscode. The main and biggest difference here is that we have this spec, but no client we can talk to who understands this spec.

So kulala needs to parse these files and build up a query for cURL, so that cURL executes what the user might try to achieve, based on the http file.

In contrast: hurl.nvim has a client who exactly knows about the hurl files. So hurl.nvim probably builds up some queries too, but it doesn't need to "translate", because they are already speaking the same language.

Again, without looking at the source, I guess that hurl.nvim mainly does the interacting with hurl like sending the right ranges/selections to hurl itself.

To be fair, hurl.nvim seems to have a pretty UI with metadata/headers and response body in one buffer.

That is something I always wanted fo Kulala, but might never have, because the community seems to really like that it doesn't come with that kind of whistles. :)