Live data from Hacker News

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

github.com

121–130 of 225 posts

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

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

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

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

#122
post #52
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…

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.

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

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

The hype cycle is a well-known, predictable thing that happens to almost every new technology.

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

#124
post #52
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…

Maybe I am too old to get this, but the idea of keeping bending the browser for native applications just doesn't make sense.

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 think of the browser as something like an X11 server. It doesn't matter how old you are; why don't you think it makes sense?

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

#126

A question from someone who is not a front-end developer: Would it be possible (and faster) to avoid the DOM and use Canvas to make a text editor (assuming we are happy with one font and basic syntax highlighting)?

I think this is a very good question, and the short answer in my opinion is yes, canvas rendering would make it much faster (as the guys at Flipboard have shown [1]). The downside is you would have to implement your own rendering engine from scratch which is quite challenging.

[1] http://engineering.flipboard.com/2015/02/mobile-web/

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

#127

A question from someone who is not a front-end developer: Would it be possible (and faster) to avoid the DOM and use Canvas to make a text editor (assuming we are happy with one font and basic syntax highlighting)?

It certainly would be possible, take a look at what is done with canvas out there! But it would be a LOT of work to get the rendering right, most guys who implement "fast" text editors these days are not super intelligent hyper programmers but simply people who prefer to embed native OS text rendering views instead of inventing 10x odd gui junk on top of them.

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

#128
post #124
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.

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 a bit long to post here. Most of them provided a saner developer experience than HTML/CSS/JavaScript will ever do. Unless we throw DOM away and replace it by something more tailored to applications instead of rendering documents.

Even if the DOM gets replaced, the browser can hardly provide an integrated experience in terms of what any native desktop/mobile environment offers to its users in terms of immersion and interactivity between applications.

It is just no different than using Java with AWT 1.0 in the early years without native widgets and integration to the respective desktop APIs.

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

#129
post #128
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…

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 than Emacs buffers or Smalltalk widgets.

I use browser developer tools a lot for changing scripts and styles interactively, and while it's nowhere near perfect, it's often extremely useful and convenient, and I think the model has lots of potential.

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

#130

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

My first text editor was usable on a machine 300,000 times slower with a million times less RAM. It bothers me that text editor performance is ever considered challenging at all.

http://en.wikipedia.org/wiki/Instructions_per_second#Timelin...

Post reply on HN