3 ms·

>> Or did I misunderstand your comment? Well, I can see now that while I expressed my dislike for change detection I didn't paint a good picture of why I think

>> Or did I misunderstand your comment? Well, I can see now that while I expressed my dislike for change detection I didn't paint a good picture of why I think we'd be better off without it :-). While I appreciate React's declarative programming style I dislike the fact that React (and all the change-detecting alternatives) force me to interact with the DOM through their APIs. JQuery allowed me to do whatever the hell I wanted to the DOM, but the resulting screens updates were very ugly. And yes, JQuery resulted in ugly and unmaintainable code but that's not on JQuery, there are rational ways to apply transforms to a DOM. I want to "do whatever the hell I want" to the DOM because I want to apply cross-cutting, adaptive transforms to my application, like I could with JQuery. And I think that we'd all be better off for it. In the transition to React-like frameworks we have lost that ability The view transition API lets me start a transition, do whatever the hell I want to the DOM, and then update the browser smoothly. So what I'm imagining is a component-oriented framework like React that doesn't lock me into a component-only API. A framework that, when rendering occurs, starts a transition, let's me do whatever the hell I want to the DOM, and then updates the browser smoothly without doing change detection. And the reason I would like that is because, while React's declarative, component-oriented development approach is nice and all, it's also very restrictive. Reacts prevents me from directly traversing and mutating the DOM, and it's own virtual DOM, because if it did then it can't efficiently do change detection. If we replace change detection with transitions then we can "do whatever the hell we want" (hopefully not in an unmaintainable JQuery way) and still have smoothly updating displays. We'd have a framework with all the benefits of React and without the restrictions. Anyway, that's my best shot at explaining myself :-).

deleted 3y ago
[deleted]
dgb23 3y ago
I‘ve written a UI a few months ago with only lithtml and direct DOM manipulation and it worked pretty well. I needed to do calculations and reading bounding boxes from the DOM initially and on resize. Basically a hack to get around CSS limitations. It was crucial that this is fast enough to avoid flickering. I wouldn’t have attempted this with react. I think it would still be possible with useEffect, but I tried the most lightweight and fast by default approach that was feasible. Have a look at lithtml.
- shaunxcode 3y ago
  in the cljs/reagent world anytime you need to do direct dom stuff you just use a ref - that must me the same for react proper?
  - dgb23 3y ago
    You can pretty much do anything with a combination of refs, events and useEffect. It’s often fiddly and cumbersome though. Aside: That’s why I‘ve been gravitating towards approaches that have much simpler execution models. You can still do declarative and functional. But you have more control when needed, create _much_ smaller bundles, have fewer dependencies, better default performance, allocate less garbage and you can reason about your code in more fundamental ways. In cljs this would mean to not use a react wrapper. However I personally try to avoid using any deps for frontend, and that includes cljs. Any dep needs a justification IMO. That justification is often not good enough, since I’m mostly writing „interactive documents with some fancy parts“. If you’re writing something like nextjournal, roam, data rabbit or similar then it’s a different story.

deleted 3y ago

[deleted]

dgb23 3y ago

I‘ve written a UI a few months ago with only lithtml and direct DOM manipulation and it worked pretty well. I needed to do calculations and reading bounding boxes from the DOM initially and on resize. Basically a hack to get around CSS limitations. It was crucial that this is fast enough to avoid flickering. I wouldn’t have attempted this with react. I think it would still be possible with useEffect, but I tried the most lightweight and fast by default approach that was feasible. Have a look at lithtml.

shaunxcode 3y ago
in the cljs/reagent world anytime you need to do direct dom stuff you just use a ref - that must me the same for react proper?
- dgb23 3y ago
  You can pretty much do anything with a combination of refs, events and useEffect. It’s often fiddly and cumbersome though. Aside: That’s why I‘ve been gravitating towards approaches that have much simpler execution models. You can still do declarative and functional. But you have more control when needed, create _much_ smaller bundles, have fewer dependencies, better default performance, allocate less garbage and you can reason about your code in more fundamental ways. In cljs this would mean to not use a react wrapper. However I personally try to avoid using any deps for frontend, and that includes cljs. Any dep needs a justification IMO. That justification is often not good enough, since I’m mostly writing „interactive documents with some fancy parts“. If you’re writing something like nextjournal, roam, data rabbit or similar then it’s a different story.