4 ms·

I don't know... even if the DOM was super fast, would it really be ergonomic to keep all your state in the DOM tree and only work with that? I kinda doubt it.

I don't know... even if the DOM was super fast, would it really be ergonomic to keep all your state in the DOM tree and only work with that? I kinda doubt it. So then you'd have to store some state in JS, and some in the DOM, and again you get a syncing problem, since you lost your single source of truth. Or did I misunderstand your comment?

hinkley 3y ago
At peak jquery, I argued successfully for storing the metadata on DOM, because then you have a system of record, upon which you can build a straightforward source of truth. React does a ton of work to solve that architectural puzzle another way. The thing I have run into over and over again is that when we try to pretend the system is Y when it is in fact X, inevitably the impedance mismatch results in 1) bugs that should be easy to reason about but are difficult to fix, and 2) a form of pulling the ladder up behind you. If I want to continue to work on interesting things I have to be able to carve out chunks of my code to gift to #3 on the bus number list, so I have the bandwidth to double down on some other topic or expand into another. I know which side my bread is buttered on. Many don’t. Which is why I have a more consistent supply of mentees than many of my peers.
- hombre_fatal 3y ago
  > I argued successfully for storing the metadata on DOM Who did you convince?
  - hinkley 3y ago
    A team working on an AJAX webapp that typically was meant to comfortable manage around 1000 blocks of state at a time. Somewhere on the order of 6-10 pieces of data per block (Which we just changed as a unit of work because 1000 was already hard enough). And when you're dealing with 10^3 you need a couple of different ways to visualize the same data or you're getting nowhere, so we had one or two other views that dealt with different levels of detail.
- stickfigure 3y ago
  Data comes from the server as JSON. Data comes from the user as DOM events and changes. There's always going to be an impedance mismatch. The DOM API sucks, so React et al went all in with state-as-objects. IMO it was the right call.
  - hinkley 3y ago
    I just don't think DOM->JSON->server->microservice->DB->microservice->server->JSON->DOM is sustainable long term. It's had a good run, but it's a big part of the reason I'm looking at Phoenix for a personal project. React is predicated upon solving the wrong problem. Talk about impedance mismatches.
    - robertoandred 3y ago
      I'm not sure switching to DOM->JSON->server->microservice->DB->microservice->server->DOM will make much of a difference.
      - hinkley 3y ago
        Complexity is usually quadratic or factorial. Only a tiny number of systems are logarithmic. 20% reduction in parts can often be a 40-70% reduction in cognitive load. But the funny thing with fractions is that if go above a threshold and come back from the brink, the path back is a smaller number than the path out. So if you go from 8 to 10 steps that's 25% worse and if you undo that bad decision you are getting 20% better. So you want to be careful to compare sustainable to unsustainable and not the other way around, if you follow me.
emorning3 3y ago
>> 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.

hinkley 3y ago

At peak jquery, I argued successfully for storing the metadata on DOM, because then you have a system of record, upon which you can build a straightforward source of truth. React does a ton of work to solve that architectural puzzle another way. The thing I have run into over and over again is that when we try to pretend the system is Y when it is in fact X, inevitably the impedance mismatch results in 1) bugs that should be easy to reason about but are difficult to fix, and 2) a form of pulling the ladder up behind you. If I want to continue to work on interesting things I have to be able to carve out chunks of my code to gift to #3 on the bus number list, so I have the bandwidth to double down on some other topic or expand into another. I know which side my bread is buttered on. Many don’t. Which is why I have a more consistent supply of mentees than many of my peers.

hombre_fatal 3y ago
> I argued successfully for storing the metadata on DOM Who did you convince?
- hinkley 3y ago
  A team working on an AJAX webapp that typically was meant to comfortable manage around 1000 blocks of state at a time. Somewhere on the order of 6-10 pieces of data per block (Which we just changed as a unit of work because 1000 was already hard enough). And when you're dealing with 10^3 you need a couple of different ways to visualize the same data or you're getting nowhere, so we had one or two other views that dealt with different levels of detail.
stickfigure 3y ago
Data comes from the server as JSON. Data comes from the user as DOM events and changes. There's always going to be an impedance mismatch. The DOM API sucks, so React et al went all in with state-as-objects. IMO it was the right call.
- hinkley 3y ago
  I just don't think DOM->JSON->server->microservice->DB->microservice->server->JSON->DOM is sustainable long term. It's had a good run, but it's a big part of the reason I'm looking at Phoenix for a personal project. React is predicated upon solving the wrong problem. Talk about impedance mismatches.
  - robertoandred 3y ago
    I'm not sure switching to DOM->JSON->server->microservice->DB->microservice->server->DOM will make much of a difference.
    - hinkley 3y ago
      Complexity is usually quadratic or factorial. Only a tiny number of systems are logarithmic. 20% reduction in parts can often be a 40-70% reduction in cognitive load. But the funny thing with fractions is that if go above a threshold and come back from the brink, the path back is a smaller number than the path out. So if you go from 8 to 10 steps that's 25% worse and if you undo that bad decision you are getting 20% better. So you want to be careful to compare sustainable to unsustainable and not the other way around, if you follow me.

emorning3 3y ago

>> 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.