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

91–100 of 225 posts

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

#91

Post by aikah »

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…

> I enjoy seeing the latest fad being burned at the stake as much as the next guy

You're talking about a project developed in Coffeescript.

> I think their technical choice of going for Javascript will be their ultimate downfall,

This is debatable. Editors like cloud9 have acceptable performances and webtechs allow one to distribute software right in the browser,which fits a huge number of use cases.

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

#94

Post by PlzSnow »

aikah wrote: post #91
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…

> I enjoy seeing the latest fad being burned at the stake as much as the next guy You're talking about a project developed in Coffeescript. > I think their technical choice of going for Javascript will be their ultimate downfall, This is debatable. Editors like cloud9 have acceptable performances and webtechs allow one to distribute software right in the browser,which fits a huge number of use cases.

Why have "acceptable" performance, when I can have "stunning" performance (Sublime Text). I am a professional, and my tools should reflect this.

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

#95

Post by antihero »

ryanSrich wrote: post #60
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…

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.

Thing is with React though, is that whilst it's initially a bit weird, once you get the hang of component lifecycle, there's very little conceptually left to learn, whereas with angular it just keeps getting more complicated.

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

#96

Post by robmcm »

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…

Your argument seems to stem from immutability is easier to reason, therefore you are willing to give up performance to accommodate it.

You stated that in some cases it doesn't matter if you use 1% or 100% of processing time in the current frame which I would argue is risky.

The more complex your application the more expensive handling wholesale changes becomes, unless you have something like react managing change detection you are going to suffer. From my point of view this is the interesting part of react, you hand off the task of change detection to generic, tested code. However it's still going to be slower than the alternative for fine grain changes.

It's also worth noting that on larger applications where you modularise common components, you typically push complexity down the chain. Take a data grid for example, do you process the data for every cell up front, or do you do it only when the cell is rendered. If it's the latter mutability of that data structure is really important, otherwise one little change is going to cost you far too much.

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

#97

Post by PlzSnow »

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

But that means the technology is being chosen to suit the developer, and not the end-user.

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

#98

Post by antihero »

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…

The true speed of using an immutable library for your data in React comes from shouldComponentUpdate. Using immutable structures is really fast as the most deepest comparisons are always O(1) because all you're doing is comparing memory addresses, thus a component can very cheaply work out whether the data given to them has changed, and as little as possible can be recalculated.

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

#99

Post by seanmcdirmid »

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…

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

Ok, that makes a lot of sense. I spend a lot of time trying to make mutability easy to reason about (my research), so I agree on the problems but disagree on solution strategies (fixing mutability with managed time vs. avoiding it). There are plenty of differing and evolving opinions in this field (e.g. back in the early 90s, constraints were going to save us).

I see as the main benefit of React is that there is no need for change propagation, just do a fast diff at the end. That's interesting and could be an overall win given the constant overhead of change propagation (O(1) with lots of bookkeeping), but I'm not sure how that would scale in practice. One of the reasons I moved on from declarative UIs (I did my dissertation on one called SuperGlue) was because the paradigm is difficult to scale in expressiveness (let alone performance) beyond simple examples; e.g. I couldn't build interactive compilers bolted onto seamlessly onto editors for richer programming experiences.

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

#100

Post by bdcravens »

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.

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.
Post reply on HN