Clojurians Log v2

some context from article: > https://www.sketch.com/ wrote about https://www.sketch.com/blog/2022/07/22/what-is-a-parallax-effect/ and spoke about how they implemented a subtle parallax scrolling effect on the homepage of their website. They chose to use a JS framework called https://stimulus.hotwired.dev/: > And it was simple from a development standpoint, too — as Richárd explains. “We use a super tiny JS framework called https://stimulus.hotwired.dev/. It lets us create small JavaScript components that are controlled by HTML data attributes,” he continues. With just a few extra HTML data parameters, the team could control horizontal and vertical velocity based on the speed of scrolling. “So larger objects and elements can move slower and the smaller ones can move faster in the virtual space,” Richárd concludes. > I think it is important to understand that no framework or JavaScript is required! If this blog post was my first introduction to the parallax effect, I could be led to believe that I should implement it with a JavaScript framework too. > Development teams may opt for JavaScript because they are already using a framework and can achieve the same outcome with just a little extra JavaScript. I don’t want to admonish anyone for doing that, it may be justifiable. However, it can be easy to make a habit of shipping more and more JavaScript as you add independent features over time. > Also, remember that it is not a mutually exclusive choice, you can use mostly CSS with some JavaScript. The https://twitter.com/keyframers did an interesting example of this in https://youtu.be/vatBdNK-OiQ.

Ah, I see. The example here seems simple: https://stimulus.hotwired.dev/ I see two wins for Web/MX, both the fine-grained state maintenance, and the fine DOM maintenance. Where VDOMers try to get by with smart diffing, Web/MX simply knows exactly which DOM to modify. Funny this came up now. I was just testing out this morning what I call "family values" 🙂 . Unlike the React "always have a key", in Web/MX we worry about that when it matters, then spell out the handling, which crucially does not involve generating anything unnecessarily:

(div {:style   {:display        :flex
                                :flex-direction :row 
                                :flex-wrap      :wrap
                                :max-width      "200px"}
                      :onclick (cF (fn []
                                     (mswap! me :kid-values conj (+ 10 (rand-int 500)))))}
                  {
                   :kid-values  (cI (range 10))
                   :kid-factory (fn [parent fake-id]
                                  (span {:style {:padding "4px"}}
                                    {:fake-id fake-id}
                                    (str fake-id)))
                   :kid-key     (fn [k]
                                  (:fake-id @k))}
                  (md/kid-values-kids me _cache))

Cool! I figured the fine-grained-ness would be nice when essentially you are basing ui state of other ui state, not necessarily some higher-level semantic schema model. Kind of like a constraint rules system. It always seemed weird to me though you could not easily code layout dynamically based on actual element width state in html.

"essentially you are basing ui state of other ui state" My favorite trick is having a dynamic background color, then having the color switch from black to white when the background RGB luminance gets too low. Two separate formulas if we use make-css-style to create an entire model for the style attribute. Just showin' off! 🙂

Nice!

But, hubris aside, I think we make better U/X when niceties such as auto-selecting color based on bkg color is no harder than a fun lookup of how to calculate RGB luminance, and then we can see it working with 15 minutes of work.