Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“Implement text editor DOM updates manually instead of via React”

github.com

Post reply on HN
Print view View original

51–60 of 225 posts

Re: “Implement text editor DOM updates manually instead of via React”

#51

Post by jordwalke »

seanmcdirmid wrote: post #44
jordwalke wrote: post #42

Earlier quoted context omitted.

(I'm on the ReactJS team at Facebook) >> pathological case for something like React. The is absolutely likely to be the case (for now). I admit I haven't looked into the technical issues very much because I've been spending 100% my time on ReactNative which seeks to resolve the deepest issues with the browser environment for React development - it's certainly a different kind of performance work. For this kind of stu…

> Immutable data structures are often the most helpful tool in accomplishing that. This is said often but without much qualification. I've found mutable data structures with change propagation (via observable or what not) to work much better given that the whole diffing thing can be avoided altogether since you know exactly what has changed. It is my understanding that the DOM is broken in how it handles invalidation…

Most of the people that don't believe that immutable, persistent data structures are effective tools to increase performance of reconciliation, only put one foot in (that's my personal experience). That kind of reservation often compels people to "just try immutability on a part of their tree". It doesn't work like that and you often should go all in before you begin seeing the benefits. It's a leap of faith, admittedly.

Almost every application (ever) is a list of lists of lists (and so on). Even text can be broken up into paragraphs/code-blocks etc which form the lists. If these structures form a tree, and that tree is somewhat well balanced, then small changes can be found in log(n) time by comparing reference identity without developer intervention (by either a mixin or Om-like system). log(n) ends up being extremely fast for n in the range of graphical nodes in most UI applications. For everything else, a windowing infrastructure can be used (usually baked into a very sophisticated component - our ReactNative mobile applications use this approach (special component that exploits immutability without developer intervention)).

Re: “Implement text editor DOM updates manually instead of via React”

#52

Post by pjmlp »

adrusi wrote: post #25
Goopplesoft wrote: post #18

Earlier quoted context omitted.

> and to be honest, I think their technical choice of going for Javascript will be their ultimate downfall, but that's a discussion for another day I'd like to see this discussion today ;)

It's not javascript. Modern javascript engines (like v8 which powers Atom) are well beyond fast enough. GC can cause occasional latency if the programmer is lackadaisical with allocations, but with care it's a non-issue. But Atom simply will not achieve performance competitive with Sublime while they are using the DOM. The DOM is too general-purpose for what is almost always just a grid of monospaced text. The overhe…

Maybe I am too old to get this, but the idea of keeping bending the browser for native applications just doesn't make sense.

Re: “Implement text editor DOM updates manually instead of via React”

#53

Post by pjmlp »

mrmondo wrote: post #8

I really don't like the idea of running an editor written in JS - I just tried out the latest stable build and it's still very much slower than Sublime Text 3.

What to expect from something wrapped on a browser playing native application.

Re: “Implement text editor DOM updates manually instead of via React”

#54

Post by seanmcdirmid »

vjeux wrote: post #47
seanmcdirmid wrote: post #44

Earlier quoted context omitted.

> Immutable data structures are often the most helpful tool in accomplishing that. This is said often but without much qualification. I've found mutable data structures with change propagation (via observable or what not) to work much better given that the whole diffing thing can be avoided altogether since you know exactly what has changed. It is my understanding that the DOM is broken in how it handles invalidation…

Highly recommend watching Lee Byron talk about immutability. He covers your doubts very well. http://conf.reactjs.com/schedule.html#immutable-data-and-rea...

> Immutable data unlocks powerful memoization techniques and prohibits accidental coupling via shared mutable state.

Memoization is still more expensive than just tracking changes and avoiding unnecessary recomputations directly (it only starts winning when doing dynamic programming). There is a point on accidental coupling but this is more of a correctness rather than performance issue.

In the high-performance computing field, use of immutable data structures is suicidal; even tries are a magnitude slower than in-place mutable data structures. And he only compares against naked shared mutable state, not against managed mutable state with change propagation.

And that gets to the end of the talk: the real reason is they want to avoid using frameworks that already solve this problem by tracking changes, and React somehow avoids that since you can do just the diff post facto. Ok, I get that.

Re: “Implement text editor DOM updates manually instead of via React”

#55

Post by bolinfest »

For context, here's a discussion from the Atom forum that we had way back in August about the future of React in Atom:

https://discuss.atom.io/t/whats-the-status-of-react-in-atom/...

There are a few issues in play here:

(1) Atom wants to support a world in which every Atom package can install whatever version of a dependency it wants, including React. This is very common in Node (incidentally, this causes problems if you want to use singletons or instanceof in Node), but fairly uncommon on the Web (where React is primarily used). That is, it's rare that you inadvertently load multiple versions of React in your single-page application. If you did, you would likely get an error when adding one React component as a child of another React component because of the way React vends ids. (Solutions are possible, but none is employed today.)

From Atom's perspective, that is a problem. The only way they can work around it is by providing "one true version of React" with Atom core that all packages must use, but then Atom is forcing all packages to use a particular version of React. That would violate Atom's philosophy of letting each package choose its own dependencies.

(2) This is not just an issue for React, but for any UI toolkit whose components are not guaranteed to interoperate across versions. To sidestep this issue, Atom has currently decided to use the DOM API/HTML custom elements. I would call this the "least common denominator approach," which satisfies Atom's design goals, but fails to provide a higher-level abstraction for building UI in Atom. It's a tradeoff.

(3) React does not currently support the shadow DOM or custom attributes, which is the new direction that Atom has chosen. As React has not yet been evicted from Atom core, I recently upstreamed a change (https://github.com/atom/react/pull/1) to add one-off support for Atom's primary custom elements, and , in the fork of React bundled with Atom. As I develop Atom packages using babel (formerly 6to5) http://blog.atom.io/2015/02/04/built-in-6to5.html, which has default support for JSX, building UI in React has been a lot of fun. However, the lack of support for custom attributes makes it difficult to do things like add an appropriate onChange handler to an to update the React component's state as shown in http://facebook.github.io/react/docs/forms.html.

(4) React is still version 0.x.x, which means it has not yet committed to a stable API. This makes choosing a version of React to bundle with Atom an even more uncomfortable decision for the Atom team, assuming they were willing to do so in the first place.

None of these items implies that there is something fundamentally broken about React's model. It just means that the React team has some work to do in order to support Atom's use case. The performance graphs cited in the original post are also significant (and of interest to the React team), but even if the performance problems were fixed tomorrow, that alone would probably not be enough for Atom to pull React back into core right now.

Re: “Implement text editor DOM updates manually instead of via React”

#57

Post by forrestthewoods »

rtpg wrote: post #48
forrestthewoods wrote: post #33

Earlier quoted context omitted.

"and text editors have an insanely high bar to clear in terms of performance and responsiveness" For some reason that sentence really bothers me. Not because our standards are so high for text editors. But because they're so low for damn near everything else.

For this sort of thing, with a fixed amount of developer time: - Performance - Stability - Actually working you can pick 2. Also, if you pick performace, 50% of the time you can only pick 1. Everything is a tradeoff but it's a lot easier to sell something slow than to sell something that doesn't work, and a lot of the performance costs are due to general techniques encoded in these frameworks that reduce bugs. Anothe…

Sublime Text is all three.

Re: “Implement text editor DOM updates manually instead of via React”

#58

Post by seanmcdirmid »

jordwalke wrote: post #51
seanmcdirmid wrote: post #44

Earlier quoted context omitted.

> Immutable data structures are often the most helpful tool in accomplishing that. This is said often but without much qualification. I've found mutable data structures with change propagation (via observable or what not) to work much better given that the whole diffing thing can be avoided altogether since you know exactly what has changed. It is my understanding that the DOM is broken in how it handles invalidation…

Most of the people that don't believe that immutable, persistent data structures are effective tools to increase performance of reconciliation, only put one foot in (that's my personal experience). That kind of reservation often compels people to "just try immutability on a part of their tree". It doesn't work like that and you often should go all in before you begin seeing the benefits. It's a leap of faith, admitte…

Thanks for your reply!

I work in this field and have written lots of code, both mutable and immutable, declarative, OO and functional, to solve a variety UI problems. I've also written my own language-enabled editors using multiple techniques (see comment https://news.ycombinator.com/item?id=9117234 for the one I'm working on right now, but you can see https://www.youtube.com/watch?v=SAoRWmjl1i4 for an Eclipse-based one I did in 2007), so I've definitely got multiple feet in the game.

I don't work in Web, most of my UI code was written for Swing, SWT (Eclipse), and these days WPF in immediate mode. It seems like React is solving a bunch of JS/DOM problems, so maybe my experience doesn't transfer, but I've found that for my work, it is much easier to just go with mutable data structures that support change propagation, so you make a change that affects a line in a block (my current editor architecture, block - lines - more blocks - more lines - etc...), the change is just...O(1) because the line can be damaged/repaired directly! So why would I give that up for O(log(n))?

Re: “Implement text editor DOM updates manually instead of via React”

#59

Post by kansface »

rdtsc wrote: post #2

That is a nice speedup! On a funny note. My coworker called it. He said a month or so ago -- In couple of months you'll start seeing articles about "Why we moved away from React". Wonder what's next. Maybe it wraps around back to jQuery...

Atom already wraps jQuery - they wrote their own DSL for mutating the DOM called space-pen[1]. They tried to get rid of it later (and rightfully so), but its too late now.

1. https://github.com/atom/space-pen

Re: “Implement text editor DOM updates manually instead of via React”

#60

Post by ryanSrich »

zghst wrote: post #27
zak_mc_kracken wrote: post #16

I enjoy seeing the latest fad being burned at the stake as much as the next guy, but I don't think we should blow this out of proportions. Atom is a text editor, and text editors have an insanely high bar to clear in terms of performance and responsiveness. Users will abandon a text editor if the cursor takes a bit too long to move. On top of that, Atom has been criticized about its slowness since the very first anno…

React is so much different from other frameworks, I feel. Someone that doesn't know React can basically come in and start working on a large app from Day 1. It is so much less frustrating than Angular, Backbone + Ember + handlebars, etc. You can continue to add features to a React application and not slow down. Also React isn't unproven. Over 1 Billion people use a React application everyday (Facebook + Instagram web…

I had the opposite impression when looking at the React docs. JSX was intimidating and getting the quick examples to work resulted in several errors. JSX is of course optional, but the way that Angular just worked, without any non sense of installing anything, is what really drew me into the framework.
Post reply on HN