ClojureScript use in Calva's source

[bpringe]

I'm opening this discussion so it can serve as a reference point (for example, to point people to when they ask about it) as well as a conversation around this subject.

Calva uses cljs for some pure logic and also for managing state. In the past @PEZ and I have had issues expanding the use of cljs in Calva. While I think a complete all-at-once rewrite of Calva is not a good idea, I did intend to start using it for new features and possibly incrementally port parts of Calva to cljs over time.

However, I spent a significant amount of time as I ran into issues with using both the existing js from cljs and compiled cljs from ts, and I put the endeavor aside in favor of continuing to develop and maintain Calva mostly in ts.

Related PRs and issues:

• Fix cljs js interop release issue
• Translate clojure-lsp integration to cljs (This was reversed in this PR, maybe because of some issue(s) mentioned in the other linked PRs or issues.)
• State issue with released cljs/js interop
• Use :npm-module shadow target
• Use cljs for state (mentions an unresolved issue with using the compiled cljs in ts)

[leifericf]

Adding my input from the related Slack thread:

If the TypeScript does not impose any significant limitations (or if ClojureScript doesn’t offer any significant benefits), then it’s probably better to leave it as is, and focus all efforts on functional improvements.

However, it might be a good idea to write more ClojureScript for new code going forward.

And I think this comment from Lukas is something we should keep in mind as well:

I’m sure there are other people that would want to contribute but would rather write Clojure in their spare time.

Here are some suggestions for questions to ask when deciding whether to rewrite some part of the codebase:

• Will it make the development workflow smoother, allowing for quicker iteration on new functionality?
• Will it reduce system complexity, making the code more robust and easier to change?
• Will it reduce bugs and other technical problems in a particular area of the code?
• Will it encourage other developers to contribute to the codebase?

One might also make a more idealistic argument: That a tool for Clojure developers ought to be written in Clojure as much as possible. This could allow more users to also help with development. I don't know if this is a particularly good argument, because it doesn't have a direct effect on the affordances and usability of the end product itself. But it could be a motivating factor for some people to contribute to the project (referring to Lukas's comment above). If someone is motivated to contribute because they want to make the product more "pure Clojure," then perhaps that should be encouraged as well. 🤔 Something to think about…

[bpringe]

I've thought about that idealistic argument as well as the motivation argument in the past, and they were part of my drive in trying to add more ClojureScript to Calva.

it might be a good idea to write more ClojureScript for new code going forward.

I think I mentioned this in one of the linked PRs or issues, and @PEZ was on board with that idea, or at least with trying it out and seeing how it goes. Unfortunately we ran into issues with that, at least in terms of adding code that isn't just pure (and maybe even with pure code as well). Those issues can be seen in the linked content.

I don't think there's so much of a question around whether more ClojureScript should be used in Calva, but how to go about doing that in a way that works.

[leifericf]

I don't think there's so much of a question around whether more ClojureScript should be used in Calva, but how to go about doing that in a way that works.

Perhaps we could try to solicit input from some of the Clojure veterans at Cognitect. To get some more eyeballs on the problem, and hash out an approach that would work for future development using ClojureScript.

VS Code has gathered a large following, and many people use it as their default editor for all things. Calva makes Clojure way more accessible to a broader audience, which is a critical factor for increased exposure and adoption of Clojure.

@bpringe: Do you know if we have a more detailed overview of the specific problems? If we could summarize that in this discussion, we could bounce it around in the community via Slack, etc. And try to find a happy path ☺️

Edit: Oh! I didn't notice that you included links in the original post above, with more details about each issue.

[PEZ]

Personally I feel I have spent all too much time on this, sacrificing user value. Perhaps guided by this feeling: as much as I love Clojure, I don't see it as a big problem with Calva written in TypeScript. I think TypeScript is a pretty nice language, tbh.

[PEZ]

That said. ClojureScript gives reach into the Clojure ecosystem, so there is always a reason to consider placing and moving code to calvaLib (the part of Calva currently written in ClojureScript, for anyone not familiar). I see it a bit like this:

• The code needs to integrate with a Clojure library? -> use ClojureScript
• The code needs to integrate with vscode? -> Use TypeScript

Of course most often it is both and it is a matter of deciding how thin/thick one or the other part should be. I think going for thin TS layer is good.

Then there are also the cases where:

• Code needs to integrate with mutating things in Calva, like the TokenCursor stuff -> TypeScript
• Pure functions -> TypeScript or ClojureScript

The latter is mostly a matter of that the :node-library that calvaLib uses (and is the only one we have gotten to work, despite huge efforts) makes for a totally flat interface to calvaLib, and it might not scale very well/be a bit too much boilerplate to put lots of tiny functions there.

[Cyrik]

I don't like pushing my own projects/efforts too much, but I think it fits in here:
#1442 + all the efforts building on top of it will make it possible to add more functionality to Calva from Clojure.
This only helps for things that should happen at runtime, but that's a lot of surface area, and a lot of the things that should happen outside the runtime are probably better placed inside LSP anyway.
Another nice effect of this is that we are actually using Clojure, not ClojureScript, which makes some things easier.

Personally I feel I have spent all too much time on this, sacrificing user value.

I think you are correct. Since this is apparently a very hard problem that has already cost a lot of time it should probably be touched because someone is interested in the problem itself (me probably at some point ...).
I've just started helping with Calva and haven't touched Typescript before and it was pretty easy to get the first two PR's done, so it's not as big a hurdle as I feared it would be.

[bpringe]

I've been working on finding a good way to write more of Calva in cljs again. I've been using the calva-cljs-testbed repo for experimenting. Details about a couple of different approaches are in the readme in two branches:

1. Using CLJS at the top level and building the whole extension with shadow-cljs
2. Continuing to use TS at the top level

Thomas Heller has been helping me in this issue, after experimenting with each approach and talking to him, it seems that using shadow-cljs to build the whole extension might involve rewriting the TS unit tests in cljs if we want to keep those tests (which of course we do), which isn't something I care to spend time doing all at once (there are over 500 TS unit tests).

I'm still learning an experimenting, but wanted to give an update here.