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

71–80 of 225 posts

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

#71

Post by Skinney »

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…

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

The problem with this though, is that the entire framework would have to be written around this idea, and everyone who uses the framework would have to use these datastructures correctly. That being said, it will probably be both more efficient and relatively easy to use once Object.observe lands in Ecmascript 7.

In the meantime React works with every datastructure out there, which is a big plus.

Immutable datastructures, while more expensive to change, could be very cheap to diff, because you know if two objects have the same pointer, they're equal.

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

#72

Post by pmontra »

vbit wrote: post #40
adrusi wrote: post #25

Earlier quoted context omitted.

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…

Just curious - why replace vim or emacs?

Don't tell me, because I use both (mainly emacs), but maybe is to do something like this https://confluence.atlassian.com/display/BITBUCKET/Edit+onli...

It can be strategic even if limited to quick edits and for some subsets of the repository now. Anyway I can think of a GitHub augmented with an IDE and integrated with a CI and CD system with deployment to a Heroku. It could let you write code from pretty everywhere, occasionally even on a tablet or a large phone. Somebody will use it.

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

#73

Post by polskibus »

e1g wrote: post #62
zghst wrote: post #27

Earlier quoted context omitted.

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…

>Over 1 Billion people use a React application everyday (Facebook + Instagram web) It's fun to actually see which parts of public websites are written with react by running this in the browser console: setInterval(function() { Array.prototype.slice.call(document.querySelectorAll('[data-reactid]')).forEach(function(element) { element.style.background = 'rgba(255,0,0,0.1)'; }) }, 500) Some pages to try it on: https://i…

You can download react tools for chrome and check react usage by just launching developer tools.

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

#74

Post by zghst »

jsprogrammer wrote: post #39
zghst wrote: post #27

Earlier quoted context omitted.

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…

Do you know of a large open source react application that I can take a look at?

Check this list on on the React repo: https://github.com/facebook/react/wiki/Examples

Noteworthy, Flipboard's React Canvas - https://github.com/Flipboard/react-canvas

Webpack also has great examples - https://github.com/webpack/react-starter

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

#75

Post by couchand »

pmontra wrote: post #72
vbit wrote: post #40

Earlier quoted context omitted.

Just curious - why replace vim or emacs?

Don't tell me, because I use both (mainly emacs), but maybe is to do something like this https://confluence.atlassian.com/display/BITBUCKET/Edit+onli... It can be strategic even if limited to quick edits and for some subsets of the repository now. Anyway I can think of a GitHub augmented with an IDE and integrated with a CI and CD system with deployment to a Heroku. It could let you write code from pretty everywhere,…

GitHub has been slowly tricking me into doing more and more of those quick edits on their site. If they can work Atom in as seamlessly as their other updates I'm sold. Somehow I'm still circumspect.

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

#76

Post by jordwalke »

seanmcdirmid wrote: post #58
jordwalke wrote: post #51

Earlier quoted context omitted.

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…

It's a great question. All of this (immutability) only makes sense to even attempt if you believe that immutability is easier to reason about than mutability. If we don't agree there, then I have nothing more to add really. But assuming we agree, then there is the question of performance.

In most applications, we have three tiers of time durations.

Tier One: During an interaction/animation you must update the screen every 16ms. Code may not run longer than 16ms (less in practice).

Tier Two: You are not interacting, but may begin interacting with something at some unknown time. Code may not block the UI thread for longer than about 50ms so that there is a guarantee of not introducing perceivable delays into the interface.

Tier Three: Long running tasks which should be executed in parallel with the UI thread/process.

If going from O(1) to O(log(n)) still allows you to meet your deadlines for whichever latency tier you are targeting in whichever supported device classes you want to support, then it's worth it in order to program with better abstractions. Blocking for 1ms is as good as blocking for 13ms in Tier 1. Blocking for 25.5 is as good as blocking for 40ms in Tier 2. (This is helped by a decent event loop/task scheduler etc).

Again, all of this assumes you genuinely value immutability as a programming paradigm over mutability. If you'd really rather mutate, then you should just be using mutations/observables. I would not rather. Sometimes, I still perform mutations for the most critical parts of a UI abstraction (such as a scroller animation etc) - but I am up front about it being a compromise of what I'd rather do.

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

#77

Post by couchand »

forrestthewoods wrote: post #57
rtpg wrote: post #48

Earlier quoted context omitted.

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.

vim has been all three for twenty years.

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

#78

Post by michaelt »

pjmlp wrote: post #52
adrusi wrote: post #25

Earlier quoted context omitted.

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.

Browsers give you cross-platform windowing.

Without having installers that include adware (Java) or that seem borderline-unsupported (X11/Quartz) or that require funny multi-stage compiling (Qt).

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

#79

Post by amelius »

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…

The problem with React is that it doesn't improve the computational complexity of the problem. In fact, it makes the situation worse, since every little update is now O(n).

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

#80

Post by couchand »

vjeux wrote: post #43

Modifying the DOM is usually the bottleneck in web apps. To get a fast app (extreme simplification), you need to only apply the minimum set of mutations. It turns out that in a large codebase this is extremely hard to do. React asks the developer for a virtual representation and computes the diff between the previous one. In most situations, the time it takes to compute the set of mutations is negligible compared to…

It turns out that in a large codebase this is extremely hard to do.

Underestimating the difficulty of that task (or a structurally equivalent one) is remarkably common. I don't know if it's because devs all think we know better than our neighbor or because we don't accurately gauge the cost of adding new features. In any case, it's depressing.

Post reply on HN