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

21–30 of 225 posts

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

#21

Post by peteretep »

unknownian wrote: post #10
mrmondo wrote: post #8

I really don't like the idea of running an editor written in JS - I just tried out the latest stable build and it's still very much slower than Sublime Text 3.

I get that they have a lot of JS devs and there's a big community but if they went with Ruby I would have been so much more inclined to stick with it. Performance-wise perhaps it would not have been better. Emacs it is for me.

I have a suspicion that every great Perl, Ruby, and Python developer can write reasonable JS, which actually makes it an even bigger community still.

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

#22

Post by mcbutterbunz »

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'm really enjoying how fast Javascript frameworks and practices are churning, it makes me feel like I'm witnessing the birth of a brand new software field with my very eyes.

I totally agree. A language or technology that doesn't change is dead. The JS world can get a crazy sometimes but we need to understand WHY certain frameworks/patterns may be better and when to apply them.

Kudos to the Atom team on making their product better.

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

#23

Post by xahrepap »

jsprogrammer wrote: post #15
plorkyeran wrote: post #6

It looks like they weren't actually using React for much. The diff is +230 lines, and there's close to that much of just new tests. Most of the actual changes are trivial (e.g. @isMounted() to @mounted) and there's not all that much DOM manipulation logic in the end result. Overall it looks like React guided them in the right direction for how to design their view code, but they don't actually need most of React's fu…

I haven't looked at the code, but since you have, why were they experiencing so much overhead if it wasn't being used for much? Was it just a relatively constant amount of overhead that everything using React will experience regardless of how much of React is "used"? Why is the overhead so high?

I haven't read the code, but I can make an guess as to why (at least one reason): Atom is using one web-renderer. React supports many version of many renderers/browser. Drop all that cruft and just go directly to the 'native' code.

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

#25

Post by adrusi »

Goopplesoft wrote: post #18
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…

> 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 overhead introduced by allowing plugins to render entire webpages inline with the text is just too much.

I want so very much to like Atom --- a Free text editor that isn't vim or emacs and is actually powerful enough to replace them, but the imperceivable latency manifests as a gradual accumulation of stress.

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

#26

Post by mrbtie »

xahrepap wrote: post #23
jsprogrammer wrote: post #15

Earlier quoted context omitted.

I haven't looked at the code, but since you have, why were they experiencing so much overhead if it wasn't being used for much? Was it just a relatively constant amount of overhead that everything using React will experience regardless of how much of React is "used"? Why is the overhead so high?

I haven't read the code, but I can make an guess as to why (at least one reason): Atom is using one web-renderer. React supports many version of many renderers/browser. Drop all that cruft and just go directly to the 'native' code.

This change doesn't seem to be about removing boilerplate to support multiple browsers, though. They're not implementing their own virtual dom diff their "one web-renderer", but moving away from this technology.

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

#27

Post by zghst »

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…

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). Unlike Google with Angular, React is Facebook's baby, the FB team is constantly churning out great additions to React.

I feel though with these JS editors, they should just basically give up for the next 5 years or so. Switching between Atom / Brackets to Sublime or Vim is extremely painful, I can't stand how slow it is. I love adopting new technologies, but I do not have faith in JS applications outside of a browser, they are too slow and lack in features.

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

#28

Post by jlongster »

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…

So much this. The DOM is absolutely going to be the bottleneck more than JavaScript. I can't really provide any concrete benchmarks to support this because its a very complex topic, and you can really only come to that conclusion after trying to optimize the DOM for something as critical as a text editor.

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

#29

Post by shurcooL »

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

Interesting times.

[1] http://limetext.org/

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

#30

Post by prapam2 »

rdtsc wrote: post #2

That is a nice speedup! On a funny note. My coworker called it. He said a month or so ago -- In couple of months you'll start seeing articles about "Why we moved away from React". Wonder what's next. Maybe it wraps around back to jQuery...

At least until something better comes along i am going with React. React makes lot easier and cleaner to build apps. I have built a stock ticker app with changing values and highlighting the change. Initially there were few performance issues, but using immutable data and shouldcomponentupdate those were resolved.
Post reply on HN