CoC vs native LSP (mason/lspconfig)

[yuriescl]

I've been wandering around Reddit and some other forums and I noticed some experienced NVIM users prefer using native LSP (through mason/lspconfig) instead of CoC.
Their main arguments against CoC is the dependency on JavaScript, its "slowness" (whatever that means) and it's bloatness (too much included by default).
I have been using CoC for over 2 years and never had any "slowness" or issues using JavaScript.
It's funny that they argue against JavaScript but then proceed to use LSP servers that run on Node, like tsserver and many others.
Nowadays Node is very optimized. There is a reason that TS/JS is being used more and more, even for complex systems like Desktop Environments and some bank applications.

I personally don't see why someone would spend days/weeks messing with native LSP configs instead of using this batteries included software (CoC) that takes care of all the automation of installing and running the LSPs in a non-conflicting way. I use Python mainly so it's super handy to have CoC take care of running mypy/black/pyright all together for me, as well as being easily configurable (python bin path, etc) via coc-settings.json for each project, no need for spending days trying to get a Lua config to do the same thing natively.

I'm opening this discussion mainly to know what @fannheyward thinks about those arguments against CoC, and what you think about this recent preference some devs are developing towards native LSP. Do you think there's any real advantage or is it the old "blue vs red" debate, where it's just a matter of preference instead of actual issues/limitations.

References:

• https://www.reddit.com/r/neovim/comments/rr6npy/question_coc_vs_lsp_whats_exactly_the_difference/
• https://www.reddit.com/r/neovim/comments/m2cxn4/neovim_why_im_switching_to_native_lsp_over_coc/
• https://www.reddit.com/r/neovim/comments/14pvyo4/why_is_nobody_using_coc_anymore/

[kaiuri]

I find coc.nvim to be the snappiest solution, specially for auto-completion.

[kaiuri]

I would like to see a DAP for coc.nvim though.

[trev-dev]

@kaiuri vimspector works!

[fannheyward]

First of all, thank you for your question @yuriescl!

I really don't like the comparison, or those arguments against CoC. Every time I saw posts like "native LSP is better than CoC" or "changed to native LSP because of xxx", I just check the downside of CoC they were talking about, to see if something can be improved in CoC.

I'll try to explain my thoughts on this topic, in my personal opinion, why I'm still using CoC and spending time on CoC and extensions.

I wrote Thoughts on coc.nvim three years ago, in Chinese, you can use Google Translate to read it if you want, I think the point still valid today.

Similar question 能否详细比较一下 nvim-lsp 和 coc.nvim?, in Chinese too

The main difference between CoC and native LSP is, how to talk with language server:

• coc: nvim <-> coc.nvim node process <-> language server
• native LSP: nvim <-> language server

In quick words, native LSP reduced one more RPC request, should be faster than CoC. It's true with some language servers. But I don't think it's a big deal, because the RPC request is very fast, and the language server is the bottleneck. I'll explain why it's not a big deal below.

In CoC, vimL parts (with some Lua too) core task is UX rendering (includes UI highlighting, responding to user interaction, floating windows, etc). We have a separate node process to talk with LS. The process will send requests to LS, receive responses, parse/decode the JSON body, sort or filter the completion results, and notify vimL parts to render UI. The language-client codes are ported from vscode-languageserver-node, can support full features of LSP quickly, consistent with VSCode (I think VSCode is the de-facto standard for LSP clients).

The nvim's native LSP client does all the things UX rending and LSP requests handling, in one place. It's fast with LuaJIT but not perfect in some cases. For example, some LS will result in thousands of completion items in JSON, the decoding work will slow down user's UI. (nvim already added c_json to speed up this, just take it as an example). Nvim is single-thread software, too many tasks in one thread will eventually slow down the UX rending. We can use libuv to async tasks, but it's really hard to perfect it.

Another example is telescope-nvim vs fzf.vim(fzf-lua), they both use rg or fd to find files, filter, and list to pick. But you may saw posts reporting telescope-nvim is slow in big codebases, because telescope-nvim did all the sorting/filtering/rending works in nvim thread, fzf.vim did sorting/filtering in fzf, rending only in vim/nvim.

Besides LSP client, coc.nvim node process provides an extension host, you can write extensions in Node.js with the same/similar APIs as VSCode extensions, or non-LSP related extensions like coc-yank. People may complain about the bloatness because coc.nvim itself is a plugin and provides a plugin mechanism, not very K.I.S.S or Unix philosophy. My thought: extensions like coc-tsserver are must-have, the best TS/JS support in vim/nvim, extensions like coc-pyright extend LS features to add inlayHints/semanticTokens highlighting/codeAction for un-import modules, some like coc-git are optional, you can choose to use or not.

For the slowness, the most intuitive experience is the latency from user input to completion items popup. coc.nvim waits for a delay of suggest.triggerCompletionWait, debounces to request after last input. The latency is noticeable in some cases.

I wrote some pros of coc.nvim, nvim's native LSP client has some pros too:

• built-in, no need to install Node.js, no one more Node.js process
• more customizable, you can write your own "textDocument/hover" handler with Lua. CoC provides configurations to custom, but not as flexible as the native one
• more plugin integration support, for example fzf-lua can display diagnostics from native LSP

The last part, Lua and nvim configuration in Lua. Lua is a full-featured programming language than vimL, more readable and maintainable. It's a great experience to write plugins in Lua, especially since nvim makes it first-citizens language, provides more native Lua APIs. But Lua is not designed as DSL to do configuration. I use several Lua plugins but still setup nvim with vimL. I see people move their init.vim to init.lua with more lines of code, sometimes not working as expected, it's a little bit of doing for the sake of doing it.

Thank you for reading, my own two cents.

[yuriescl]

@fannheyward Thank you so much for your feedback!
I perfectly agree with you, Lua is a hassle to deal with most of the time as it's untyped. I can't count how many types I had unexpected nil issues.
And about the debate. Well, I spent years using CoC and then months trying to get the equivalent setup in Lua/native LSP. I couldn't even get close to be feature-paired with CoC, and also I wasted so much time trying to config things.
I think that's what it comes to, configuring things. It takes time, effort, and knowledge of Neovim API/Lua/LSP. Most of us have things to do and need to get work done, so we can't afford to learn all the internals. But still we need the modern LSPs to be productive, that's where CoC comes into place for me.
Since going back to normal IDEs is not an option for me as my setup is too tightly integrated with tmux and bash, then being able to get all the goodies from VSCode plugins via CoC is fantastic!

Like I said, I really tried the native LSP approach to see if it makes any sense for me, and it doesn't. The "performance" improvement is completely relative, some things are probably quicker in CoC as you mentioned.

With CoC I have my global coc-settings.json and then my per-project coc-settings.json configs, and that's it. Nothing else to worry about.

So I settled with CoC and there's no reason to look out for alternatives at the moment, it's simply too good.

Thank you so much for putting up such a great tool and allow us to get VSCode plugins to work with Neovim with no hassle.

TL;DR: If you want to be productive, use CoC. If you want to spend hundreds of hours fiddling with Lua and still lack a significant amount of features that CoC gives you for free, then use native LSP.

[hexh250786313]

@yuriescl

I personally don't see why someone would spend days/weeks messing with native LSP configs

I think one reason people prefer to use built-in LSP is that it provides lsp apis or hooks to customize their neovim features. This aspect, compared to coc.nvim, gives a more Vim-like feeling of being able to customize everything you want (even though they can't really customize everything).

As for performance and speed, I've never felt any practical difference when comparing the lsp speed between builtin and coc.nvim, so I don't think performance and speed are key factors in this comparison.

Leaving aside the part about LSP, I also prefer to use coc for developing my own plugins.

For me personally, I also like to develop some personal plugins, including those for coc, Lua, and VSCode. Based on my experience in plugin development, working with untyped languages like JavaScript and Lua gives me a feeling that the code I write is 'dangerous'. So, regardless, I find typed languages to be superior to untyped ones. Lua is great, but it's not for me. I'm only willing to use it to configure my nvim settings rather than to actually develop a plugin with it.

One of my interests is porting plugins from VSCode to nvim, and coc makes this task much simpler. This is perhaps the biggest reason why I use coc :)