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

151–160 of 225 posts

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

#151

Post by bglazer »

seanmcdirmid wrote: post #13
rtpg wrote: post #7

Earlier quoted context omitted.

Atom is very different from other things. The editor component is something that revolves almost entirely about state, and a huge amount of state at that. I think the future is, like many abstractions, one where your tighter loops escape the abstraction (like numpy's C bindings). There's still advantages on a big-picture scale to using declarative frameworks like React EDIT: one thing is that a text editor can know a…

This is why I designed Glitch: http://research.microsoft.com/apps/mobile/showpage.aspx?page... Note that all the live editor examples in the essay are written in Glitch. Think of Glitch as a react like framework that focuses on fixing mutable state through time management rather than avoiding it.

Hi Sean, having skimmed the presentation you linked to, Glitch's programming model seems similar to VHDL and Verilog, in that the "tick" is an explicit construct and statements are not guaranteed to execute sequentially.

I'm not experienced in VHDL, so I might be completely wrong here.

Did you take any design cues or inspiration from hardware design languages?

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

#152

Post by tootie »

zghst wrote: post #68
ryanSrich wrote: post #60

Earlier quoted context omitted.

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.

JSX is simple, it is just simplified HTML. I think you may want to give it another try, sharpen your skills with it. It is not difficult to work with if you try. And on installing things, it is basically what any developer does these days. We install tools for almost anything. Just think of the JSX tools as another tool in your belt to help with the translation. The paradigm shift opens up your palette to new technol…

JSX is XML and it can cause some confusion. For instance the fact that you can only have one root node is not obvious.

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

#153

Post by frik »

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…

A WYSIWYG html or text editor with low latency is inbuilt in HTML5 called ContentEditable - though the implementation is in a sad state.

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

#154

Post by antimatter15 »

hondaz54 wrote: post #117

A question from someone who is not a front-end developer: Would it be possible (and faster) to avoid the DOM and use Canvas to make a text editor (assuming we are happy with one font and basic syntax highlighting)?

That's actually the approach Mozilla's Bespin/Skywriter project took. It was shuttered when Cloud9/Ace (which render to DOM) supplanted most of its goals. I would be surprised if the performance delta of switching to canvas would actually be that large, given that using the DOM allows you to harness GPU acceleration for things like translation.

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

#155

Post by seanmcdirmid »

bglazer wrote: post #151
seanmcdirmid wrote: post #13

Earlier quoted context omitted.

This is why I designed Glitch: http://research.microsoft.com/apps/mobile/showpage.aspx?page... Note that all the live editor examples in the essay are written in Glitch. Think of Glitch as a react like framework that focuses on fixing mutable state through time management rather than avoiding it.

Hi Sean, having skimmed the presentation you linked to, Glitch's programming model seems similar to VHDL and Verilog, in that the "tick" is an explicit construct and statements are not guaranteed to execute sequentially. I'm not experienced in VHDL, so I might be completely wrong here. Did you take any design cues or inspiration from hardware design languages?

There is an inspiration from synchronous reactive languages, which are in turn inspired by hardware design (not sure if they predate or post date vhdl); you can read the related work section of the essay-linked conference paper if you are interested about lineage.

Glitch is a bit weirder in that all statements execute at the same time within a tick, their order isn't just unfixed: they are guaranteed to see all of each other's effects (except event handlers, which execute more hardware-like discretely to do state transitions).

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

#156

Post by seanmcdirmid »

antimatter15 wrote: post #154
hondaz54 wrote: post #117

A question from someone who is not a front-end developer: Would it be possible (and faster) to avoid the DOM and use Canvas to make a text editor (assuming we are happy with one font and basic syntax highlighting)?

That's actually the approach Mozilla's Bespin/Skywriter project took. It was shuttered when Cloud9/Ace (which render to DOM) supplanted most of its goals. I would be surprised if the performance delta of switching to canvas would actually be that large, given that using the DOM allows you to harness GPU acceleration for things like translation.

Doesn't canvas have its own GPU accelerated batched draw operations? All tast needs to be accelerated, really, is font rendering, and I would be very surprised if it wasn't.

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

#157

Post by elektronjunge »

tinco wrote: post #134
mackwic wrote: post #132

Earlier quoted context omitted.

Seems fine on my >500Go aggregated log file. Scroll line by line with no issues. Sed and matching is near instant. What's the issue ?

I'm not sure why you would open a log file with vim, but that's besides the issue. The issue is with 500 line files. Open one up in Sublime and one in Vim. If you only use Vim you'll never discover what it to means to have a performant editor (I've used Vim for ~10yrs and still regularly do).

I have no idea what you are talking about. I opened a 26,000 line file (no I don't want to talk about it). In vim it opened instantly and my scrolling was only limited by my key repeat rate. The scrolling isn't as smooth looking because vim doesn't animate the scrolling between lines. Sublime took 2 seconds to open the same file, and scrolling was smooth.

Maybe you are using to many vim plugins? I'll admit vim plugins are a real problem, the gui rendering desperately needs to be moved to its own thread.

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

#158

Post by boomlinde »

jerf wrote: post #148
boomlinde wrote: post #145

Earlier quoted context omitted.

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

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

What about the latency requirements is insane, then? I can't think of what "insane" could possibly mean in this context other than technically challenging or infeasible.

> A browser is a tough place to build a text editor.

I agree. To some extent I'd call that in itself an "insane requirement". The merge request proves, however, that you can attain reasonable performance by avoiding additional abstractions on top of the already very abstracted platform. Looking at the call graphs, Javascript itself or even the DOM obviously were far from being the bottlenecks.

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

#159

Post by jerf »

boomlinde wrote: post #158
jerf wrote: post #148

Earlier quoted context omitted.

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

> 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. What about the latency requirements is insane, then? I can't think of what "insane" could possibly mean in this context other than technically challenging or infeasible. > A browser is a tough place to build a text editor. I agree. To some extent I'd c…

"I can't think of what "insane" could possibly mean in this context other than technically challenging or infeasible."

Apparently, responding to keystrokes by putting a character on the screen in less than a couple hundred milliseconds is still technically challenging, or at least, doing everything we want to do within that time frame is still technically challenging for a high-powered editor. Which is less silly if you think about it. A single keystroke in "notepad" is one thing, a single keystroke in a programmer editor is quite another.

"Looking at the call graphs, Javascript itself or even the DOM obviously were far from being the bottlenecks."

If Javascript really was a fast language on par with C++ or something, that amount of abstraction would not have been a problem. The fact that Javascript is slow really is a problem. It is not necessarily the problem, because many other things are contributing, but it is a very significant part of the problem.

You can bring a Java or C++ program with its knees with too much abstraction too, but it takes a lot, lot more work than that. (Many have managed to leap this bar and more, though!)

It's one of the reasons I'm really trying to get the 1990s-style dynamic scripting languages out of my professional life. It really isn't that hard to reach a point where you simply can not have both of "a good design" and "sufficient response time" because you literally want to do more work than the language can get done on one core in 100ms unless you essentially manually inline everything, but that's not practical for its own reasons.

In fact, on that note, note that this is it for Atom. This is the fastest they can go with this layer. Should they end up pushing the editor a bit farther and should they end up needing a bit more performance to do something else properly, they won't be able too, because they just tapped out this well.

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

#160

Post by moron4hire »

tinco wrote: post #125
couchand wrote: post #77

Earlier quoted context omitted.

vim has been all three for twenty years.

Vim is not performant. Try scrolling in Vim, then try scrolling in Sublime.

Vim itself is fine, but the plethora of plugins that a lot of people install can drag it down. Firefox has the same problem with extensions. And it's really not the fault of the base package. It's the plugin developers not doing due diligence, and it's the shear number of plugins making it impossible to test all combinations.
Post reply on HN