Clojurians Log v2

I cannot find much about this besides anecdotal mentions. Was there any concrete attempt at building something akin to Svelte? Concrete attempts to eschew the virtual DOM mania using some macro magic ?

@adam678 check out https://github.com/thheller/shadow-experiments#highly-experimental-code by @thheller

I built and use this nowadays https://github.com/thheller/shadow-experiments

but its nowhere near ready for "public" use. good enough for experiments though 😉

its pretty impressive actually

@mkvlr Thanks, I was aware of shadow.arborist but not all this :)

my library, https://github.com/phronmophobic/membrane/ , does not have a virtual dom

I do use it for all my stuff now but this is the only public repo in case you want to look over it 😛

https://github.com/thheller/shadow-cljs/tree/master/src/main/shadow/cljs/ui/components

It's a bit of a shame you are working on all that alone. You should establish your own team of super heroes and fight JS crime.

I remember reading that 'conarrative/precept' (https://github.com/CoNarrative/precept), which sadly doesn't look much active anymore, could be a hint of a solution towards having a data-driven DOM without the need for a virtual one nor anything sophisticated in that respect. I can somewhat understand why, to some extent on a superficial level. However it pretty much died out from what I see.

This is probably a gross oversimplification, but at first, on a data level it looked like it was about reproducing a reagent-like state management in cross-platform fashion (feel free to correct me). Then I got a bit confused while looking at the Fulcro example. Essentially, how would one use this library in the browser without relying on any React framework?

It did have https://github.com/clyfe/clara-eav.

I have a wrapper for lit-html that accepts Hiccup-style [:div [:span.some-class "text content"]] syntax that I've just pushed to Github https://github.com/shepheb/lit-up

I don't know if whatever lit-html does under the hood counts as a "virtual DOM", but it's fast and powered by pure functions, so it's a very tidy fit in CLJS.

this state management is quite different from reagent.

I don't have a good example project for the web, since I'm primarily focused on desktop, but you can check out https://github.com/phronmophobic/membrane/blob/master/src/membrane/webgltest.cljs#L72 and https://github.com/phronmophobic/membrane/blob/master/docs/webgl.md

which both use webGL

if you do want to render to DOM nodes, there is a backend for https://github.com/exupero/vdom

the idea is that your UI code remains the same regardless of which backend you choose.

Published to https://github.com/shepheb/lit-up not on Clojars yet because I can't spare the time to set that up right now.

is there a cljs cheat sheet for manipulating CSS properties of dom elements?

another goal is that you should be able to mix and max your state management library (reagent, re-frame, fulcro, etc) with your target platform (DOM, webGL, javaFX, swing, skia, etc)

It is probably too soon to ask but would you say that it is bound to remain a research project or do you truly believe that it has a chance for outperforming React-like libs by design?

the membrane fulcro example is using fulcro on desktop

for me it already is

the DOM parts are performant enough and rarely the issue. even in react apps. the issue is mostly in how most react components are written with no concern for performance. (eg. wrapping 10 layers of higher order components to get a dumb div that acts as button)

so yeah you can write bad performing components in pretty much all frameworks, mine included

Hey! I’m using shadowcljs with reagent and I’m trying to display an image in my app like [:img {:src "./public/images/stopwatch-solid.svg"}] but the path is incorrect and am not sure how to set it up. Any pointers appreciated.

Or should I just store the SVG inline in the file as a string? :thinking_face:

perhaps the path public/ is already being hosted by whatever web server you are using (this is common) in which case it might just work if you did [:img {:src "/images/stopwatch-solid.svg"}]

however, baking the SVG into the cljs output is not a bad idea (it saves 1 extra HTTP request which might speed things up under some circumstances)

@peb.brzezinski

Awesome, thanks for your answer!

Changing the URL to images/stopwatch-solid.svg has helped 👍