I am not sure how widespread this is, and maybe it's only me currently doing this, but another option is full-stack ClojureScript. Compiling using Clojure tooling (shadow-cljs) and producing .js artifacts for both the front-end and the backend, and then running the backend on Node instead of JVM. This is very much a viable approach (I have several sites in production with thousands of users), but if it's only me working this way perhaps not noteworthy at this point in time. 😅 If you would like more information about this approach let me know.

No mention of Fulcro

@UUSQUGUF3 You're too modest by not even mentioning https://github.com/chr15m/sitefox 😄 I already suggested it in the #clojure-doc thread and Sean reacted with 👍

@U4C3ZU6KX Someone else mentioned that (in #C03S1KBA2) so I've added it to the frontend section but happy to expand that -- I know zero about Fulcro/Pathom/etc.

@UUSQUGUF3 Where does sitefox belong in that page? I'll put it in frontend for now with Fulcro etc but the project page sounds more like a backend framework? • https://github.com/chr15m/sitefox - full-stack ClojureScript development on node.js

@U04V70XH6 Sitefox is a backend framework so maybe it belongs in the Frameworks section, although the "full stack" section where you have it now is probably fine. Thanks for including it!

If you change your mind, PRs are welcome:rolling_on_the_floor_laughing:

edit: moved here https://clojurians.slack.com/archives/C02M6N5C137/p1697146721350319?thread_ts=1696912504.243649&cid=C02M6N5C137

A client of mine switched to simply sass as a drop-in replacement for the old node-sass package and it is working well for them. > https://github.com/sass/dart-sass, compiled to pure JavaScript with no native code or external dependencies. https://www.npmjs.com/package/sass

I also use the above. Just via its CLI, by shelling out.

Mhm, I see. Thanks you both for the input. We'll check it out.

At an old job we used node-sass but at my current job we simply use sass from npm. When editing any stylesheets, you just invoke sass with watch mode. The webserver built-in to shadow-cljs is able to live reload CSS, so this works excellently for us

The nice part about this setup is that all you need to work with CLJS and Sass in our frontend is just npm and nothing more. We have a few scripts so that you can e.g. npm run sass to get live-reloading stylesheets. And both CIDER and Calva are capable of automatically detecting shadow-cljs projects and launching them via npx shadow-cljs … So it’s really easy to set up the frontend and have both live-reloading clojurescript and live-reloading stylesheets.

If you're using leiningen, there is https://clojars.org/lein-sass/versions/1.0.0 which relies on dart-sass.

Yep, we use leiningen. We'll definetly check this out, thanks!

What does "interactive" mean exactly?

@U2FRKM4TW Hi! I mean that it's a graph view that can be modified and not static E.g. nodes in the graph can be moved around, hover events on nodes/edges are accessible, click events can be accessible, etc.

Quite some time ago when Python was my main language, I was pretty much in love with Bokeh. Back then, I have studied all alternatives that I could find and settled on Bokeh for a lot of reasons. While it's main goal is to be able to create interactive web-based charts with bidirectional client-server communication, it can be used from JS, without Python at all. However, it's somewhat of an advanced usage: https://docs.bokeh.org/en/latest/docs/user_guide/advanced/bokehjs.html I would definitely recommend it if you want to find something you'd like to keep on using for a long time. But if you just need something that works for your current simple case, I'd try finding a D3 example that seems to be the closest to what you need and adapting it to your exact needs.

Re: BokehJS, "I would definitely recommend it if you want to find something that you'd like to keep on using for a long time" The following note on their docs website does not inspire confidence in me that I should be using its JS API: "The BokehJS APIs is still in development and may undergo changes in future releases."

Re: D3 I was always scared away from it after looking at its homepage. It does so many things. It does all sorts of fancy charts, some of them are static, some are dynamic/interactive. I'd rather have one library focused on doing this one thing. Having too many other things makes me think that at some point they'll decide to change everything and migration will be painful

> The following note on their docs website does not inspire confidence in me that I should be using its JS API: Updating a dependency is always a choice, never an obligation. ;) (Unless it's a security hole, but we're talking about a frontend-only library here).

i know of sigma.js (http://sigmajs.org) but it uses WebGL and they themselves recommend d3 for smaller graph projects (https://www.sigmajs.org/#usecases) . have never used it myself though

@U04TQR7C24D that's an interesting choice! and also @U2FRKM4TW thanks for the D3 recommendation. I'm gonna give D3 a try

It might be helpful to browse the collection of tools here: https://scicloj.github.io/docs/resources/libs/#vega-rendering

If you're willing to relax the <canvas> requirement this might meet your needs: http://reactflow.dev

I see two approaches.. 1. One <canvas> element, manipulated by JS through either Canvas API or WebGL API [vis.js, sigma.js] 2. An <svg> element for edges and edge labels, and optionally <div> elements floating on top as nodes and node labels [d3, react-flow] I suppose the first approach has higher performance potential (particularly if WebGL is used), which is beneficial when rendering a huge graph. The second approach has greater flexibility potential since SVGs/DIVs are easier to programmatically manipulate, when the number of DOM elements created this way is small enough to not cause big performance issues.