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

141–150 of 225 posts

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

#141

Post by seanmcdirmid »

moomin wrote: post #136
seanmcdirmid wrote: post #54

Earlier quoted context omitted.

> 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 compu…

Yes, but immutability means that reference checks are enough to spot unchanged areas. And we're not in HPC land right now, we're writing JavaScript. In that world, Om (immutable) is vastly faster than Backbone, Knockout, Angular, Ember &c (mutable). Partially because, when you can reason more clearly, it's easier to do something about the performance.

Reference checks are conservative in spotting unchanged areas (if true, definitely no change, if false, maybe no change) unless all values are internalized (a bit expensive to do that). Also, diffing is only needed at all when you need to compare values anyways; dirty bits are otherwise sufficient to mark changes.

I'm not really familiar with the web ecosystem, but why would it differ so much from say C#/WPF? or a system based on change propagation instead of diffing?

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

#143

Post by forthefuture »

The problem with anything that has to be compatible with everything is that the overhead will necessarily get to a point that you can't reasonably use it in production code. Not to say people won't still do it anyway, just that if you're looking for a bottleneck, you don't have to look very far. Until "frameworks" start being broken up into modules with individual functionality (kind of like how everyone tells you to learn how to program), there will always be churn like this.

It's kind of sad to me because we'd be a lot farther in the future if there was one library that made dom elements faster than any other library, and one library that made diffing faster than any other library. But we're stuck with these monsters of frameworks that black box so hard for syntax that they completely give up on solving the problems they meant to.

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

#144

Post by amarsahinovic »

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…

>"Free text editor that isn't vim or emacs and is actually powerful enough to replace them"

Maybe not powerful enough to replace them but still worth a look http://foicica.com/textadept/

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

#145

Post by boomlinde »

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…

> Atom is a text editor, and text editors have an insanely high bar to clear in terms of performance and responsiveness.

This "insanely high bar" has been easily cleared by text editors running on humble home computers for 30+ years. I'm not sure it qualifies as being insanely high.

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

#146

Post by PSeitz »

runeks wrote: post #135
PSeitz wrote: post #89

Earlier quoted context omitted.

That killed my facebook tab

function() { Array.prototype.slice.call(document.querySelectorAll('[data-reactid]')).forEach(function(element) { element.style.background = 'rgba(255,0,0,0.1)'; }) } is executed every 500 ms using command in question. So if the above function takes 500 ms or more to execute, the tab will get stuck (I would think). Try just executing this command once: Array.prototype.slice.call(document.querySelectorAll('[data-reacti…

Yes, the attribute selector could be slow and/or the non-opaque drawing, I guess.

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

#147

Post by PSeitz »

runeks wrote: post #135
PSeitz wrote: post #89

Earlier quoted context omitted.

That killed my facebook tab

function() { Array.prototype.slice.call(document.querySelectorAll('[data-reactid]')).forEach(function(element) { element.style.background = 'rgba(255,0,0,0.1)'; }) } is executed every 500 ms using command in question. So if the above function takes 500 ms or more to execute, the tab will get stuck (I would think). Try just executing this command once: Array.prototype.slice.call(document.querySelectorAll('[data-reacti…

Yes, the attribute selector could be slow and/or the non-opaque drawing, I guess.

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

#148

Post by jerf »

boomlinde wrote: post #145
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…

> Atom is a text editor, and text editors have an insanely high bar to clear in terms of performance and responsiveness. This "insanely high bar" has been easily cleared by text editors running on humble home computers for 30+ years. I'm not sure it qualifies as being insanely high.

I think the point is not necessarily that "text editors intrinsically require gigabytes of RAM and gigahertz CPUs", but that they have "insane" latency requirements.

On the one hand, yes, our computers ought to be able to handle text editing. On the other hand, as long as you meet the latency requirements one way or another it doesn't much matter whether you barely met them or utterly blew them out of the water by four orders of magnitude... instant is instant, to a human.

A browser is a tough place to build a text editor. You're running a huge, complicated, sophisticated text rendering and typesetting environment, which you're using only a vanishing fraction of but the browser doesn't know that and can't much optimize for it. (Some, sure, I'm sure it's got special routines for monospaced text, but it still can't know you won't just stick a picture in the middle of it a moment from now.) You're running on top of a fairly slow language, even after all the optimization work on it [1]. You're running in an environment that is deeply structured to be synchronous so if you accidentally write a for loop over anything that turns out to be larger than you expected, you've frozen your environment until you're done, to say nothing of accidentally handing the browser a big rendering job ("did you just open a directory with 20,000 files? here, let me render that for you..."). Any of these things individually might be overcome, but the combination is quite challenging. It's nifty that the browser lets you run "anywhere" but it is also in a lot of ways a crazy place to try to build a programmer-quality text editor.

[1]: I have to justify this every time I say it since somehow the idea that "Javascript is fast!" has sunk into the community, but it's not true. The easiest proof is asm.js... if Javascript was already "C-fast" or even close, it would not even exist. It exists precisely because Javascript is not a fast language. Javascript is much faster than it started out as, but it started out as an extraordinarily slow afterthought meant to run a statement or 4 in response to a mouse click. It has still stabilized on "much slower than C" and appears to have essentially plateaued. The result of speeding up something miserably slow by quite a bit can still result in something slow in the end.

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

#149

Post by taylorwc »

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…

As someone who never really jumped into code until very recently, I find Atom far and away the most accessible text editor. Familiar interface (to a browser) and not overwhelming to set up. I've tried emacs, vim, and sublime. I'm sure that I could come to love emacs or vim, but it just seemed like too much messing with it before I would really enjoy it. Sublime is better, but I just prefer Atom. Guess that makes me some kind of radical minority here :)
Post reply on HN