I don't know if you prefer this feedback elsewhere, but this snippet from the tutorial:

(let [elem (ui/on
            ;; return nil for any mouse-down event
            :mouse-down (fn [_] nil)
            (ui/button "Big Red Button"
                       (fn []
                         [[:self-destruct!]])))]
     (ui/mouse-down elem [20 20]))
>>> ()

...actually evaluates to ([:self-destruct!]) , not ()

(as a minor nitpick, the next exampe evaluates to nil, not (), but I don't suppose that matters much?)

a more general comment on the tutorial: it seems to assume that reagent-like atom-based reactive behavior is well-known to readers, which is perhaps fair in Clojureland. but the simple-ugly-checkbock-without-using-any-framework example made me wonder how does membrane actually perform the update. it seems to be rerunning the thunk we pass to skia/run, but how does it know when to do that? I guess on every event? so if I update the atom programmatically without having any events triggered I won't get any refresh? what gets rerendered? the whole window, I guess?

I also noticed that there is some lag between the time I click and I see updates in the screen, especially the very first click

which makes me wonder a bit about what overhead is involved in event handling and response

not to sound negative, the overall idea sounds great to me

yes, it the window will update on every event, or every 3 seconds. generally, speaking the whole window gets updated. there are a few optimizations to reduce draws, but very few at the moment. there is a way force the window to refresh, but it's not documented at the moment

another bit that is not explicitly explained is that when testing out the component definitions leading to the final example plain clojure data is used, but in the final example itself we pass an atom to the component. somehow the framework seems to handle that case especially. it would be nice if the tutorial briefly explained (not only demonstrated) the semantics of that

the delay is quite hit-and-miss; it's more noticeable in some runs than in others

not a big deal, I guess, since it only happens noticeably in the first click

is the delay apparent in the example code, or are there changes where the state might not have been updated before the function returns?

the delay is noticeable in the tutorial example code as is, but only if I cilck ~quickly after launching the window. if I wait a few seconds and then click then I notice no delay

I think I'm more likely to get a small delay if I press and hold the mouse button (although the code seems to be clearly reacting to presses, not press-release sequences)

but I may be just being fooled by randomness

right. most of the tutorial code just responds to mouse down events

from a performance perspective, I've done optimizations as I run into bottlenecks and I'm currently building medium size apps that feel pretty responsive, but there's still lots of optimizations that haven't been implemented yet

as a phrasing nit, I had to read this sentence a few times before I understood it: "To run a component, simply call your implementation's run function with ...". In retrospect, that clearly means the implementation I chose (e.g., skia), but initially it seemed to refer to something I wrote

maybe that's just coffee not having kicked in yet 🙂

hmmm, a better wording might be: > To run a component, simply call the backend's (eg. skia) run function with...

one of the ideas that I think is interesting, but haven't had time to try is that the methods for optimizing draw calls could probably be used across skia, webgl, and even vdom backends