Support clangd in the browser

[thegecko]

Based on the great work over at https://github.com/guyutongxue/clangd-in-browser I've been working on a VS Code extension which runs clangd entirely in the browser. This is useful for server-less environments such as https://vscode.dev.

Is there any interest in bringing this support into vscode-clangd?

The only drawback is the clangd wasm file is currently weighing in at 90mb and it will need to be shipped with the extension to allow it to be served from the VS Code marketplace.

cc @HighCommander4

[HighCommander4]

That's pretty neat!

My first thought is that this is a different enough use case that it makes sense as a separate plugin. (If there's significant code to be shared, we could consider something like a different plugin living in the same repository, though I think the pace at which vscode-clangd changes is slow enough that a downstream model is not likely to be much overhead.)

Curious to hear others' thoughts as well. cc @hokein, @sam-mccall

[JVApen]

@thegecko Do you have any idea of the performance impact on a regular environment using wasm compared to standard clangd executable?

Are there features that no longer work with wasm and/or serverless? I'm mainly thinking of loading of an index (both using remote server and file indexes)

[thegecko]

@JVApen I'm sure there are going to be limitations regarding certain features, especially calling out to the outside world.
Performance impact should be negligible.

The repo I linked above has a demo at https://clangd.guyutongxue.site/

[JVApen]

I was just reading up on how to publish extensions when I noticed this: https://code.visualstudio.com/api/working-with-extensions/publishing-extension#platformspecific-extensions
So it seems that for a specific platform, for example web, you can upload a different extension. This might be a good solution to include the wasm in the extension without influencing the regular desktop users.

[thegecko]

Yeah that's right, it's a pattern my team use for other vscode extensions (e.g. a webusb polyfill library only shipped for desktop).

With that in mind, maybe a Poc is the next step?

[JVApen]

Mainly putting my thoughts into text for future reference. Previously it was said:

My first thought is that this is a different enough use case that it makes sense as a separate plugin. ...

This could be an argument to integrate it into this extension. Leaving up to @HighCommander4 to decide next steps as he's the code owner.

My understanding is that you already have something working (https://clangd.guyutongxue.site/) so I feel the concept is already proven.

[thegecko]

My understanding is that you already have something working (https://clangd.guyutongxue.site/) so I feel the concept is already proven.

This isn't my work, so can't take credit. The difficulty is bundling the WebAssembly in such a way that it deploys and works correctly as a VS Code extension, this just needs me to commit some time to it.

[HighCommander4]

Previously it was said:

My first thought is that this is a different enough use case that it makes sense as a separate plugin. ...

This could be an argument to integrate it into this extension. Leaving up to @HighCommander4 to decide next steps as he's the code owner.

I'm happy to elaborate on my rationale for the above statement.

Note that I'm not the only maintainer of vscode-clangd; folks on the Google team such as @hokein, @kadircet, or @sam-mccall may have thoughts as well.

When deciding whether to accept a new feature, one consideration from a maintainer's point of view is what sort of effort and expertise will be needed to maintain / support the feature going forward. At the moment, this is not clear to me; my vague sense is that browser support will involve technologies / areas of expertise that are new to the existing maintainers, but I'm not sure whether we're talking about a small amount of glue code or something more significant.

On the other hand, vscode-clangd is a low-velocity project (it gets a handful of commits per month, if that), which makes downstream forks fairly cheap to maintain (meaning, even if a downstream fork is trying to stay up to date with upstream vscode-clangd, the amount of integration work over time would be minimal). We already have such forks in the community, with https://github.com/eclipse-cdt-cloud/vscode-clangd being a notable one.

This is why it seems to me that a version of vscode-clangd with browser support would initially make more sense in a downstream fork published as a separate plugin. Such a plugin could be published and made available to interested users without being blocked on any upstreaming work. It would also allow us to see what the browser support code looks like, what is the size of the user community that's interested in it (based on plugin downloads), what volume of bug reports / issues it gets, etc.

Once that's in place, if we feel upstreaming the functionality will bring concrete benefits (e.g. easier discoverability for users), we can have a conversation about that.

[JVApen]

That looks to me like a reasonable approach. If I summarize:

• create an downstream fork that adds this functionality
• publish it as a plugin
• gather information about downloads and number of issues as well as how to best support it and amount of required code changes
• evaluate after some time (1-2 years?) if integration makes sense, having a maintainer who has experience with wasm sounds like a requirement

[HighCommander4]

I think that's a good summary. (The incubation time doesn't need to be measured in years, it could be sooner.)

[thegecko]

Maintaining a downstream fork may be more burden than maintaining the feature as part of this repo. I guess the crux of the decision is whether the feature is of interest: we don't want to add a feature to maintain only to find it isnt used and its difficult to remove again.

How about I see what the code difference is once a PoC is completed (even as a draft PR) and take it from there?

BTW, I'd be happy to assist in maintenance on this repo.