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

181–190 of 225 posts

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

#181

Post by ryanSrich »

ceedan wrote: post #178
ryanSrich wrote: post #60

Earlier quoted context omitted.

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.

JSX intimidated you?... I find that difficult to believe.

Intimidating was probably a poor choice of words. I guess odd would be better? Idk. It was just a deterrent for me. I can get over the syntax but the installation errors coupled with it being weird was just enough to make me drop the tutorial I was working on.

I do hope to start working with React again. It took me a few times to really get into angular so I'm sure once a guide comes out that really gets the details right I'll be fine. Something like this[1] for React would be amazing.

1. https://www.youtube.com/watch?v=i9MHigUZKEM

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

#182

Post by kbenson »

peteretep wrote: post #21
unknownian wrote: post #10

Earlier quoted context omitted.

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.

I have a feeling that that's correct, but to the same degree that every great Perl, Ruby, and Python developer can write reasonable code in any of Perl, Ruby, and Python given good reference docs. The languages aren't really all that different if you take a macro view (and include lisps, static typed languages, etc).

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

#183

Post by zyxley »

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…

>It looks like a race of whether Atom can become ST3 faster than ST3 can become Atom.

I'd give the advantage there to Atom, given how sparse and irregular the ST3 change logs are.

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

#184

Post by frik »

hondaz54 wrote: post #117

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

One can use contentEditable HTML5 API.

http://caniuse.com/#search=contenteditable

* https://accessgarage.wordpress.com/2009/05/08/how-to-hack-yo...

* https://blog.whatwg.org/the-road-to-html-5-contenteditable

* http://www.quirksmode.org/dom/execCommand.html with test page: http://www.quirksmode.org/dom/execCommand/

The text font rendering in Canvas2D is slow. For example the Canvas based charting library Flot use HTML Divs overlays instead of Canvas font rendering: http://www.flotcharts.org/flot/examples/ (last link)

Another method would be WebGL.

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

#185

Post by frik »

frik wrote: post #153
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…

A WYSIWYG html or text editor with low latency is inbuilt in HTML5 called ContentEditable - though the implementation is in a sad state.

to downvoters: it was not against Atom, it was about the current state of contentEditable API:

* http://caniuse.com/#search=contenteditable

* http://www.quirksmode.org/dom/execCommand.html (and more info: https://blog.whatwg.org/the-road-to-html-5-contenteditable )

Example editor: http://neilj.github.io/Squire/

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

#186

Post by jerf »

ziahamza wrote: post #163
jerf wrote: post #148

Earlier quoted context omitted.

I think the point is not necessarily that "text editors intrinsically require gigabytes of RAM and gigahertz CPUs", but that they have "insane" latency requirements. On the one hand, yes, our computers ought to be able to handle text editing. On the other hand, as long as you meet the latency requirements one way or another it doesn't much matter whether you barely met them or utterly blew them out of the water by fo…

Games in js have had similar requirements, or even tougher. expectation out of a game has been increasing for a long while, and there are games being built on js (even full fledge games using asm.js and webgl), So i dint think the requirement for latency is as insane, you just need good dicipline, which game develers have had for decades

An asm.js game using WebGL drops the slow language problem and drops the vast bulk of the browser layout problems, leaving only the problem that you're still sorta stuck on synchronousness, but games have dealt with that for years. The fact that you reached for those details to justify your point is further evidence of my point, not denial of it.

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

#187

Post by spleeder »

antimatter15 wrote: post #154
hondaz54 wrote: post #117

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

That's actually the approach Mozilla's Bespin/Skywriter project took. It was shuttered when Cloud9/Ace (which render to DOM) supplanted most of its goals. I would be surprised if the performance delta of switching to canvas would actually be that large, given that using the DOM allows you to harness GPU acceleration for things like translation.

Canvas is hardware accelerated.

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

#188

Post by freshhawk »

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…

That is definitely not one those "pick two" situations. The relationship between those 3 things is quite different, in fact having one normally implies a better than average chance of having the others.

You can not release a feature until it is performant, stable and working. You just won't release a lot of features. If you have the testing and release procedures that keep things stable and working - testing for performance regressions is easier, not harder.

The classic "pick 2" situations is time, cost, features. Picking any one of those makes the other two harder to do, not easier.

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

#189

Post by zkhalique »

React and Mithril are for regenerating the entire virtual DOM of a component from scratch every time. Then the dirty-checking / diffing happens in the virtual DOM.

Angular on the other hand does the dirty-checking / diffing in the ViewModel, after a digest cycle, and then does the calculations and updates the DOM elements with markers linked to directives that say they need to be updated ({{ interpolation }} is also done then). Sometimes it just re-sets the innerHTML again, but rarely.

You don't need any of this stuff. Most of your components know how to redraw themselves without re-generating the whole DOM. Your components can just expose a function that you call when you've modified their state atomically.

The question is really about batching all your DOM reads/writes on the next animation frame. For this you should use GSOP or FastDOM and be done with it!

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

#190

Post by ulisesrmzroche »

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…

Mobile and micro-services will change what? Even then microservices are an architectural pattern, it's not inherently tied to a platform, whether it runs native or in the browser.
Post reply on HN