> Is there any reason to use LSP, rather than simple JSON messages passed between the front-end and back-end
Yes, there's a reason to use a documented open standard supported by multiple servers and clients that passes JSON back and forth rather than an ad hoc, client specific mechanism that also passes JSON back and forth.
In fact, the reason is exactly the problem LSP addresses, labeled as “The Matrix” at https://langserver.org
In short, a problem with N+M cost is better than N×M when both N and M are >2.
Because LSP is a widely used protocol for language tooling that's not coupled to any particular editor.
I'm surprised xi didn't just add an LSP client to leverage the existing ecosystem. The benefits of in-house language server implementations seem marginal at best.
Most LSP work is just simple JSON messages passed with HTTP-like headers for Content-Type and Content-Length, presumably to future proof it against other payload formats.
Yes, there's a reason to use a documented open standard supported by multiple servers and clients that passes JSON back and forth rather than an ad hoc, client specific mechanism that also passes JSON back and forth.
In fact, the reason is exactly the problem LSP addresses, labeled as “The Matrix” at https://langserver.org
In short, a problem with N+M cost is better than N×M when both N and M are >2.