I don’t believe that they’re actively maintained, and I would not recommend them! They are still in use in codebases, but probably mainly as legacy code -I can speak from experience here 🙅

The ideas of Om lives on strong in https://fulcro.fulcrologic.com/

Very grateful for the answers thank you very much

or some js engine embedded in jvm?

It renders hiccup to html on the server-side, once it is loaded on the client, the html is enhanced to connect to a react component

So it only does SSR for the first page load, if the user than interacts with JS components that will use react on the client side

> It renders hiccup to html on the server-side Is react relevant to this? Sounds like SSR is all about Clojure (hiccup) stuff. My initial impression was, SSR sounds like running react on the server side to pre-generate the html needed.

Well, react is relevant in that the rendered HTML from Rum can connect to a react component on the client side. So it's still an interactive page, just the first render is done on the server

If you don't need interactivity (beyond what HTML can do), you can just use Hiccup directly, no need for anything else, and you don't even need JS and thus Clojurescript

Technically Rum can be used instead of Hiccup, it has its own renderer for Hiccup that's supposedly claimed to be faster. So it can be used without React for just standard HTML SSR without interactivity, but a lot of the features won't be useful, it's just a way to organize hiccup basically.

Generally people want to create a highly interactive web page powered by React, and also have SSR so the first page load is faster and search engine can index the content. That's where Rum shines as it can render the first page and then let React take over for interactivity.

SSR with rehydration is a React thing. SSR with Rum is interesting because it doesn't force you to use JS on the server like doing it directly in React would, i.e. if you're rehydrating React components then you're probably using JS on the sever too, but with Rum you can just use JVM Clojure and get the regular Clojure backend experience.

You can definitely run some JS code within JVM, but that would mean bringing in some extra dependencies for compile-time. This is the commit where shadow-cljs removed similar functionality: https://github.com/thheller/shadow-cljs/commit/6daffeae50d0b7f029aad8e975997b20223955dc It might be tricky to make it work with an NPM dependency, although documentation suggests that it should be straightforward: https://www.graalvm.org/22.1/reference-manual/js/Modules/

FWIW, a similar wrapper went with a direct approach - all the symbols are already there in the code: https://github.com/arttuka/reagent-material-ui Apart from being the most straightforward implementation, it also gives its user all the static code inspection niceties. And you don't have to write everything by hand - you can have a CLJS script that generates those (def ...)s for you, which you would then commit into a repo.

Amazing @U2FRKM4TW !! This is exactly what I needed. Thank you!

Actually, definitely go with the second approach. Because if you gather everything under a single umbrella namespace, DCE will not be possible. An NPM dependency, once required in a loaded namespace, will not be removed - even if you don't use it.

In the case of arttuka/reagent-material-ui, notice how the author puts every components in its own namespace. You don't want to load a million of icons or whatever just because you needed a single number input field.

interesting, that makes sense. in this case all components live in a single file: https://github.com/ChristopherChudzicki/mathbox-react/blob/main/src/components/components.tsx

@U2FRKM4TW how would you deal with an import of this components.tsx to allow DCE?

for example maybe one namespace per components, but then ["mathbox-react/path/to/components" :refer [SpecificComponent]] in each namespace? would that do it?

or is this a change that the mathbox-react library author should address upstream, with separate files for each component

> how would you deal with an import of this components.tsx to allow DCE? As far as I know, that would not be possible without refactoring the mathbox-react library. :refer doesn't cut it. It has to be its own namespace. When you use :refer, the whole mentioned JS file is still loaded.

As a piece of reference: https://shadow-cljs.github.io/docs/UsersGuide.html#_using_npm_packages Specifically, the rest of the section starting at "Notice that previously we were stuck using bundled code".

okay I can push that upstream, that is helpful. I’ll do the right thing in this library and then get that change pushed up. you noted that I could write a cljs script to generate each def; that will let me pull in docstrings too so that’s actually quite nice. the idea is to have the script actually populate the file tree yeah?

Yep!

Could even put it into a Git hook and make sure that there are no changes to the generated files before you commit.

Just to guarantee that your CLJS code is always in sync with whatever NPM library version you depend on.

💥

FINAL QUESTION while I have you: I named the library mathbox-cljs, which is a touch awkward. My thought was that, because there is an npm dependency pulled in with the name “mathbox”, that it would be good to disambiguate. If I DID make namespaces like (ns mathbox.blah) , would the compiler become confused with the "mathbox" dependency? typing this out I guess that would only be a problem with a bare mathbox namespace at the top level.

so maybe this is actually a question about “is there any good reason to add that suffix”, since it would be definitely clearer for the user to remove it

I don't think there's a good reason, unless, as you say, you decide to use a single-level mathbox namespace. Just to be sure, I'd check that mathbox.blah doesn't intersect with "mathbox/blah" (of course, you have to find what JS package you can import, and then create a corresponding CLJS namespace). And you'd also have to check with different build tools since AFAIK they resolve or might resolve NPM dependencies differently. But I'm 90% certain that it's not an issue at all.

yeah, that would be the issue I’d anticipate, that if I want to mirror mathbox’s tree I’ll end up with clashes. But now that I look, mathbox has all of those nested under “primitives/types”: https://github.com/unconed/mathbox/blob/master/src/primitives/types/operator/grow.js so I won’t clash.

Even if there was a name clash, my intuition suggests that mathbox would be first checked at mathbox.cljs and "mathbox" would be first checked at mathbox.js. But maybe it's wrong, although I'd be surprised.

My first step would be to consider very carefully whether I truly need a bit mask or whether some other approach would work, like a map with boolean values. If the conclusion is that a bit mask is the only approach, then I'd probably use js/BigInt with CLJS and BigInteger with CLJ.

In Java, https://docs.oracle.com/javase/8/docs/api/java/util/BitSet.html is probably good to consider, not sure if there is a js equivalent

Ah, thanks. I kept thinking that there was a specific class for this but couldn't remember it. And seems like there are a few JS libraries to mimic that functionality.

Thank you guys! I want a single implementation for both languages, so it seems like int with fallback to int-array is the only option.

It'd still go with BigInt and BigInteger then because they both support bitwise operations. Ints are different between JS and Java - you can't just use them without writing at least some platform-specific code.

> writing at least some platform-specific code. Yeah, I know. Svelte is a reference implementation for my problem. Have checked and they are using arrays of *ints, not even bigints.

Of course just with regarding int size (in js int is 32 bits, and they use 31 bits).