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

101–110 of 225 posts

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

#101

Post by methyl »

mlangenberg wrote: post #87
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…

React requirement today is that there can only be one version loaded at the same time, otherwise everything breaks. If you update React in Atom core, you run the risk of breaking all the plugins that were written for a different version of React. Is this still an issue when you override `ID_ATTRIBUTE_NAME`? require('react/lib/DOMProperty').ID_ATTRIBUTE_NAME = 'data-myproductid'; I am wondering if React is usable for…

> I am wondering if React is usable for writing a JS Widget, for example Disqus.

It is, I've written some quite impressive widgets and it performs really well.

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

#102

Post by seanmcdirmid »

Skinney wrote: post #71
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…

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

> 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 is the problem, and one of the reasons why I haven't ported Glitch (works in C#) to Javascript yet (instead, opting to wrap it up in a new language).

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

Yes, I use this property a lot in my own code; I'm pragmatic and use both mutable/immutable data structures. That being said, I find it easy to trace changes and do change propagation on a mutable data structure (that can change) vs. an immutable one (which obviously require diffing since you can't know exactly what changed). Using immutable data structures actually make that problem much harder from my point of view, but I see its utility as an easy way to integrate with existing code and programming practices (something I can't offer).

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

#103

Post by pjmlp »

michaelt wrote: post #78
pjmlp wrote: post #52

Earlier quoted context omitted.

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

> Without having installers that include adware (Java)

Only for developers that aren't savvy enough to know the multiple options to bundle the runtime or compile to native code.

Or the users that don't install Java from http://www.oracle.com/technetwork/java/javase/downloads/jre8... or can't be bothered to read a dialog box.

> or that seem borderline-unsupported (X11/Quartz)

Since when is Quartz unsupported?

> or that require funny multi-stage compiling (Qt).

Since when do users compile GUI frameworks?

Cross platform UI is nothing new, there are much more options to choose from than those you listed, and browsers can hardly offer more than a 90's GUI experience.

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

#104

Post by methyl »

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.

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

#105

Post by crazychrome »

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?

emacs doesn't have decent support of jsx: the jsx-mode is actually for another tech with same name, the js2-mode is great except xml support.

i love vim a lot (use evil in emacs), except vimscript. I hope oneday I could use neovim with atom/st2 as frontend.

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

#106

Post by crazychrome »

jordwalke wrote: post #42
kylec wrote: post #4

This is really interesting. In the summer of last year, I was looking into various JS libraries to use for an upcoming project at work when I saw the story that Atom was moving to React for their UI, so I decided to take a look. The philosophy really clicked with me and that's what we ended up going with. I don't regret that choice - it's worked out really well for us so far - but it's interesting that it hasn't for…

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

One question: when can we have a real look at react-native ?

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

#107

Post by TimJRobinson »

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…

Cloud9 manages to pull off all 3, and in javascript to boot. I honestly don't notice any difference in performance between it and ST3 (other than initial loading, which is a given seeing as it's web based).

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

#108

Post by mlangenberg »

methyl wrote: post #101
mlangenberg wrote: post #87

Earlier quoted context omitted.

React requirement today is that there can only be one version loaded at the same time, otherwise everything breaks. If you update React in Atom core, you run the risk of breaking all the plugins that were written for a different version of React. Is this still an issue when you override `ID_ATTRIBUTE_NAME`? require('react/lib/DOMProperty').ID_ATTRIBUTE_NAME = 'data-myproductid'; I am wondering if React is usable for…

> I am wondering if React is usable for writing a JS Widget, for example Disqus. It is, I've written some quite impressive widgets and it performs really well.

Do you load it into an iframe?

If not, how do you make sure you are not conflicting with an existing version of window.React?

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

#109

Post by burntcaramel »

jordwalke wrote: post #76
seanmcdirmid wrote: post #58

Earlier quoted context omitted.

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…

Also as an application gets more complex, it may be harder to keep the juggling act of mutable structures going, and keeping them as fast as they were before.

Mutable structures have a tax that you often must pay with complexity. Immutable structures and React’s declarative approach have more of a flat tax, with means complexity and performance are much more predictable.

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

#110

Post by veidr »

NhanH wrote: post #38
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.

It might have something to do with the demographics. Text editor users are developers, power users, or at the very least, very tech savvy (there is also the other extreme of the spectrum, people who know nothing better, but you get my point). With that demographics, we (at least I know I do) tend to be more picky. The majority of people are content with coffee-making-loading-time for their OS, and the slug that is ca…

I'm not a fan, but Microsoft Word 2013 is massively more performant than Atom, at any basic task that both programs do (launching, opening files, find/replace, etc).
Post reply on HN