Fork me on GitHub
#clojurescript
<
2021-01-26
>
Helins19:01:04

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 ?

thheller19:01:13

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

thheller19:01:31

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

Helins19:01:43

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.

😂 2
Helins21:01:31

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?

thheller21:01:37

for me it already is

thheller21:01:18

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)

thheller21:01:44

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

dgb2319:01:46

its pretty impressive actually

Helins19:01:48

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

phronmophobic19:01:52

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

👍 2
Helins20:01:51

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?

phronmophobic21:01:34

this state management is quite different from reagent.

phronmophobic21:01:38

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

phronmophobic21:01:45

which both use webGL

phronmophobic21:01:54

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

phronmophobic21:01:43

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

phronmophobic21:01:48

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)

phronmophobic21:01:41

the membrane fulcro example is using fulcro on desktop

Helins20:01:47

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.

Braden Shepherdson21:01:30

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.

sova-soars-the-sora21:01:05

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

Piotr Brzeziński22:01:01

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.

Piotr Brzeziński22:01:17

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

blak3mill3r22:01:02

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"}]

blak3mill3r22:01:09

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)

Piotr Brzeziński22:01:06

Awesome, thanks for your answer!

Piotr Brzeziński22:01:02

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