Hacker News Reader

Comment by nyanpasu64 | Hacker News Reader

I don't like React: https://news.ycombinator.com/item?id=31981947

> In Cocoa, scroll position is part of the view's state, a mere property of the view. This is simple because the UI itself is stateful.

> In React, scroll position is typically not part of the state from which we project the view. Instead this state is attached to the projection itself (e.g. a HTML node) and we are dependent on the "Memoization Map" to preserve it. So this memoization is now required for the correct functioning of the app. The "pure function" abstraction is leaking.

View on HN

I struggle to understand what you are saying here.

What do you mean when you say "this memoization is now required for the correct functioning of the app"? I agree that there can be some issues with scroll restoration in routing, but it doesn't seem like a big issue to me and certainly doesn't seem to reveal some fundamentally flawed architecture.

Haven't written React, but it relies on memoization to preserve hidden state (like text carets and item scrolling) not tracked by your application. If you change the tree structure of your GUI (add/remove/move elements), and don't give scrollable UI items a key if they move, React will delete the scrollable DOM element and create a new one scrolled to the top, losing the user's scroll progress. The same goes for text fields with horizontal (or vertical) scrolling and active cursor position, perhaps text field contents (unsure), etc.

Again, I am not sure if I am just misunderstanding something but that doesn't sound right to me.

>it relies on memoization to preserve hidden state

It relies on the DOM to keep that state. It's not hidden, you are just not forced to deal with it or think about it.

>If you change the tree structure [...] and don't give scrollable UI items a key if they move, React will delete the scrollable DOM element [...]

Yes, if you have an array of elements, you need to give them a unique identifier. This is a fundamental property of any diff-algorithm which the virtual DOM relies on. I don't think that is unreasonable, and IMO it is not something that adds significant cognitive load.

React definitely has quirks and especially optimizing for performance can be quite complex. But out of all the GUI frameworks I have tried (including Win32, WinForms and GTK as well as other web ones), React is the most intuitive to me.

> This is a fundamental property of any diff-algorithm which the virtual DOM relies on. I don't think that is unreasonable, and IMO it is not something that adds significant cognitive load.

I think it's a leaky abstraction nonetheless, regardless if it causes issues in practice. But if it's not a significant issue to users, that's fine; personally I'd prefer to work in UI frameworks that avoid redundant diffing work by design (outside of cases like lists where it's difficult to avoid).

> I think it's a leaky abstraction nonetheless, regardless if it causes issues in practice.

The abstraction is intentionally leak to meet a very valuable design goal: React plays well with other libraries that are manipulating the dom. This is a hard requirement for many businesses because libraries written without React in mind would often cost years to replicate.

So far as I can tell there's no reason someone couldn't apply the general approach to UIs React takes while also making it a less leaky abstraction. In a native scenario this makes a lot more sense because there's less components you might want to reuse vs the web.

This got me reading up on leaky abstractions. Wikipedia credits https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a... for the term, where he claims: "All non-trivial abstractions, to some degree, are leaky."

If leaky abstractions are unavoidable, we're left with debates about which leaky abstractions are justifiable given the constraints and goals of the design.

I agree that this is an annoying issue. I don't think it's inherent in the FRP UI design, but I think it might very well be somewhat impractical to avoid, especially on the web. The fact is, the DOM already has sort-of 'hidden state' that can't be 'managed.' If you designed a UI framework from the ground up, without worrying about the web, you could avoid some of these pitfalls, for example by making the underlying UI nodes (equivalent to the DOM) completely stateless.

The scroll position, in this case, would just be props.

However, at some point a UI framework usually encapsulates some kind of state somewhere. I'm not sure if a design exists that 100% doesn't encapsulate any internal state. (Maybe immediate mode GUIs?) Though, removing hidden state in the underlying UI components would at least solve the problem of needing to care about underlying node identity for them. But, it wouldn't solve it for components that compose them. I think this is unavoidable in a system that allows state encapsulation.

I think you could make an FRP UI framework that in fact, does not have state encapsulation, but it would be a lot more cumbersome to use, because you'd have to "bubble" the underlying state of any component anywhere all the way up the tree to the root.

Reply on news.ycombinator.com