“Implement text editor DOM updates manually instead of via React” • Hacker News Board

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

#191

Post by shurcooL » Fri, Feb 27, 2015, 7:30 PM UTC

methyl wrote: post #104

shurcooL wrote: post #29

Meanwhile, a new Sublime Text 3 Dev build today added enhancements to its minihtml module. It looks like a race of whether Atom can become ST3 faster than ST3 can become Atom. The main competitive advantage that Atom has over ST3, IMO, is that it's open source. If Sublime Text 3 were to become open source, that would be a huge win. Also, that open source ST3 clone limetext [1] written in Go seems to be making progres…

Can you add something more about what is the minihtml module? Google says nothing.

Grep the ST3 dev channel changelog [1] for "minihtml".

[1] http://www.sublimetext.com/3dev

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

#192

Post by chipotle_coyote » Fri, Feb 27, 2015, 7:39 PM UTC

bdcravens wrote: post #100

forrestthewoods wrote: post #57

Earlier quoted context omitted.

Sublime Text is all three.

I love ST; I happily bought a v2 license a while ago, and will buy v3 when it's an option. I just get nervous about the resources being allocated to its development, so I've run Atom almost exclusively for a few months as a hedge.

It's worth noting that if you haven't checked in recently, ST3 development appears to be back on track and proceeding at a pretty good clip. (Having said that, I'm keeping my eye on Atom myself. My big concern with ST3 is that the combination of closed source and single developer gives it a bus factor of 1. I'm hoping Jon follows through on his vague plan to get another developer in this year.)

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

#193

Post by natch » Fri, Feb 27, 2015, 7:40 PM UTC

spleeder wrote: post #56

Who changed the title of this post and why?

It's pretty common for post titles to be changed (by HN admins). The most frequent change I see is they change the title to match the title of the original linked article/story/whatever, which seems to be the case here.

Why, I can't speak to the reasons in this case but I suppose when you allow any user to make up anything for a title, they sometimes inject their own opinion or otherwise make the title not properly reflect the intent of the original title. Not saying this is what happened here.

Of course it can go the other way. Sometimes original titles are not clear, and the HN title can get preserved or changed for clarity or neutrality.

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

#194

Post by grandalf » Fri, Feb 27, 2015, 7:43 PM UTC

fumonko wrote: post #85

grandalf wrote: post #31

Atom is awesome, but it feels like they are reinventing emacs only without terminal support and much slower. I use both editors but find myself continuing to go back to emacs b/c of a few features that I can't do without.

likewise. Out of curiosity, which features are you referring to?

I like indent-region and the simplicity of C-x b to switch buffers.

I do think Atom has the potential to really go beyond what emacs has accomplished b/c more people know js/coffee than elisp, but emacs is also a moving target and has become a lot better than it was 10 years go.

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

#195

Post by d0m » Fri, Feb 27, 2015, 7:46 PM UTC

Just chiming in. Switched from Angular to React, and saw massive improvement on any fronts. Maintainability, Speed of development, performance, etc.

The big caveat is that we're using it on Phonegap where javascript operations are much more expensive. I.e. something that takes 5ms on my laptop takes up to 50-100ms on the phone. So, unfortunately, the "Pure React" approach didn't work on some page because there were too much comparisons.. 95% of the app use Pure React and is much faster than before, but in some very specific cases, we have to use mutation and mutate the DOM manually. I think it's a totally fair tradeoff for all the benefits we got from using React.. Similar to using Python but having some optimization in C when necessary.

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

#196

Post by d0m » Fri, Feb 27, 2015, 7:46 PM UTC

Just chiming in. Switched from Angular to React, and saw massive improvement on any fronts. Maintainability, Speed of development, performance, etc.

The big caveat is that we're using it on Phonegap where javascript operations are much more expensive. I.e. something that takes 5ms on my laptop takes up to 50-100ms on the phone. So, unfortunately, the "Pure React" approach didn't work on some page because there were too much comparisons.. 95% of the app use Pure React and is much faster than before, but in some very specific cases, we have to use mutation and mutate the DOM manually. I think it's a totally fair tradeoff for all the benefits we got from using React.. Similar to using Python but having some optimization in C when necessary.

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

#197

Post by dcherman » Fri, Feb 27, 2015, 7:58 PM UTC

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…

Instead of using a timer or a one time selector, just add a new CSS rule via a style tag

(function() { var style = document.createElement( "style" );

   style.innerHTML = "[data-reactid] { background: rgba(255,0,0,0.1); }";
   document.head.appendChild( style );

}());

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

#198

Post by seanmcdirmid » Fri, Feb 27, 2015, 9:14 PM UTC

joewood1972 wrote: post #162

seanmcdirmid wrote: post #141

Earlier quoted context omitted.

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

If everything is immutable then a reference check is all you need. They key is to avoid deep copies. Observables are problematic when changes can ripple through your model/view-model - resulting in multiple DOM changes. This equally applies to WPF.

WPF has a retained scene graph, so no diffs are necessary, all changes are just O(1).

Reference equalities only work to know what really hasn't changed, they of course can't tell you that two values are still equal even if their references are different (unless compketely internalized, of course). For react, that's fine: it's just some extra work if false inequality is encountered, there are other applications where its not ok.

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

#199

Post by tracker1 » Fri, Feb 27, 2015, 10:46 PM UTC

jerf wrote: post #159

boomlinde wrote: post #158

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

Does it really need to happen on one core? The platform supports webworkers and serializing certain events across channels wouldn't take much... if you look at, for example some of the cross channel rendering with react that has been experimented with, there's merit there.

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

#200

Post by tracker1 » Fri, Feb 27, 2015, 10:53 PM UTC

lmm wrote: post #121

michaelt wrote: post #78

Earlier quoted context omitted.

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

Qt only requires funny multi-stage compiling in C++. If you use it from Python it all just works.

And there's no reason someone couldn't create similar bindings for atom/node/iojs etc...