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

131–140 of 225 posts

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

#131

Post by seanmcdirmid »

pjmlp wrote: post #128
mbrock wrote: post #124

Earlier quoted context omitted.

Why not? The browser is something like a mechanism for delivering text, images, layouts, and interactive scripts. It's highly cross-platform. Quite perfect for many uses, and the popularity of web apps is almost evidence in itself. CSS is a bit annoying, but with evergreen browsers and flexbox it's getting very good—and even as annoying as it is, it's still mostly easier to work with than most GUI toolkits. I often t…

> Quite perfect for many uses, and the popularity of web apps is almost evidence in itself. Mobile and micro-services will change that. > why don't you think it makes sense? Because I went through the evolution of using text based GUIs, Amiga, Atari and PC GUI toolkits, drawing UIs with the likes of Visual Basic, Turbo Pascal, Delphi and C++ Builder. To the modern ones of XAML, Cocoa, QML and so on. The list is just…

The DOM's main advantage is supposed to be accessibility and portability to different form factors; otherwise, just roll your own UI using Canvas (like I do using WPF canvas anyways for my editor work). It's not clear to me how accessibility could be preserved while allowing for more flexibility.

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

#132

Post by mackwic »

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.

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 ?

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

#133

Post by lobster_johnson »

pjmlp wrote: post #103
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).

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

> Since when is Quartz unsupported?

I think he was referring to X11.app — aka XQuartz — which has not been supported or included in OS X since 10.6 (Mountain Lion).

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

#134

Post by tinco »

mackwic wrote: post #132
tinco wrote: post #125

Earlier quoted context omitted.

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

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

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

#135

Post by runeks »

PSeitz wrote: post #89
e1g wrote: post #62

Earlier quoted context omitted.

>Over 1 Billion people use a React application everyday (Facebook + Instagram web) It's fun to actually see which parts of public websites are written with react by running this in the browser console: setInterval(function() { Array.prototype.slice.call(document.querySelectorAll('[data-reactid]')).forEach(function(element) { element.style.background = 'rgba(255,0,0,0.1)'; }) }, 500) Some pages to try it on: https://i…

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-reactid]')).forEach(function(element) { element.style.background = 'rgba(255,0,0,0.1)'; })

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

#136

Post by moomin »

seanmcdirmid wrote: post #54
vjeux wrote: post #47

Earlier quoted context omitted.

Highly recommend watching Lee Byron talk about immutability. He covers your doubts very well. http://conf.reactjs.com/schedule.html#immutable-data-and-rea...

> Immutable data unlocks powerful memoization techniques and prohibits accidental coupling via shared mutable state. Memoization is still more expensive than just tracking changes and avoiding unnecessary recomputations directly (it only starts winning when doing dynamic programming). There is a point on accidental coupling but this is more of a correctness rather than performance issue. In the high-performance compu…

Yes, but immutability means that reference checks are enough to spot unchanged areas. And we're not in HPC land right now, we're writing JavaScript. In that world, Om (immutable) is vastly faster than Backbone, Knockout, Angular, Ember &c (mutable). Partially because, when you can reason more clearly, it's easier to do something about the performance.

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

#137

Post by TeMPOraL »

lmm wrote: post #122
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.

Most native applications use a language runtime and most GUI ones use a general-purpose declarative layout engine. Put those together and you basically have a browser.

Except their GUI (if well made) is much better at interop, handles tons of shortcuts that are forgotten in webapps, and native apps don't have to bother with crazy amount of limits browsers have "because security". Like Chrome not letting you bind to half of the Emacs shortcuts because some evil actor could use them on a webpage to phish you.

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

#138

Post by pjmlp »

mbrock wrote: post #129
pjmlp wrote: post #128

Earlier quoted context omitted.

> Quite perfect for many uses, and the popularity of web apps is almost evidence in itself. Mobile and micro-services will change that. > why don't you think it makes sense? Because I went through the evolution of using text based GUIs, Amiga, Atari and PC GUI toolkits, drawing UIs with the likes of Visual Basic, Turbo Pascal, Delphi and C++ Builder. To the modern ones of XAML, Cocoa, QML and so on. The list is just…

Hmm, interesting. I've used a few GUI toolkits, written bindings for GTK+, worked with Java and Swing, etc. Modern web development, especially using React, is in many ways the sanest thing I've come across. It reminds me of stuff like Emacs, Lisp systems, Smalltalk, etc. Inspectable environments using dynamic languages... But React's model for components and DOM elements seems to me in many ways easier and better tha…

> It reminds me of stuff like Emacs, Lisp systems, Smalltalk, etc. Inspectable environments using dynamic languages

In a way yes, but only if we can get rid of DOM and have 1:1 parity with desktop APIs.

One ends up piling div elements with CSS and JavaScript, to imitate something that looks like native widgets, but don't behave like them nor can interact with the desktop environment.

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

#139

Post by wtf_is_up »

elinchrome wrote: post #120
PlzSnow wrote: post #94

Earlier quoted context omitted.

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

Isn't the main complaint about sublime that it's slow once you add enough plug-ins to make it useful?

I don't think so.

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

#140

Post by sigzero »

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…

Until it opens files bigger than 2MB, it's a non-starter for me to even look at.
Post reply on HN