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

161–170 of 225 posts

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

#161

Post by j42 »

tootie wrote: post #152
zghst wrote: post #68

Earlier quoted context omitted.

JSX is simple, it is just simplified HTML. I think you may want to give it another try, sharpen your skills with it. It is not difficult to work with if you try. And on installing things, it is basically what any developer does these days. We install tools for almost anything. Just think of the JSX tools as another tool in your belt to help with the translation. The paradigm shift opens up your palette to new technol…

JSX is XML and it can cause some confusion. For instance the fact that you can only have one root node is not obvious.

I will say though that when it comes to abstracting elements, this behavior seems to be implicit across the board (angular directive templates require the same, though they include a somewhat-informative error state).

As someone who has only begun to feel out React/JSX after developing some large, semi-complex enterprise UI's in Angular (with the respective back-end, usually an abstracted REST API) I'm finding the React model to be a lot more intuitive and scalable.

Angular is fantastic until you run up against problems with complex tasks that either must run outside of the digest loop or require manual control of painting/rendering to compensate for the abysmal binding performance.

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

#162

Post by joewood1972 »

seanmcdirmid wrote: post #141
moomin wrote: post #136

Earlier quoted context omitted.

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.

Reference checks are conservative in spotting unchanged areas (if true, definitely no change, if false, maybe no change) unless all values are internalized (a bit expensive to do that). Also, diffing is only needed at all when you need to compare values anyways; dirty bits are otherwise sufficient to mark changes. I'm not really familiar with the web ecosystem, but why would it differ so much from say C#/WPF? or a sy…

If everything is immutable then a reference check is all you need. They key is to avoid deep copies. Observables are problematic when changes can ripple through your model/view-model - resulting in multiple DOM changes. This equally applies to WPF.

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

#163

Post by ziahamza »

jerf wrote: post #148
boomlinde wrote: post #145

Earlier quoted context omitted.

> Atom is a text editor, and text editors have an insanely high bar to clear in terms of performance and responsiveness. This "insanely high bar" has been easily cleared by text editors running on humble home computers for 30+ years. I'm not sure it qualifies as being insanely high.

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

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

#164

Post by Guvante »

taylorwc wrote: post #149
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…

As someone who never really jumped into code until very recently, I find Atom far and away the most accessible text editor. Familiar interface (to a browser) and not overwhelming to set up. I've tried emacs, vim, and sublime. I'm sure that I could come to love emacs or vim, but it just seemed like too much messing with it before I would really enjoy it. Sublime is better, but I just prefer Atom. Guess that makes me s…

> As someone who never really jumped into code until very recently

Honestly your first code editor is always the best until you find a killer feature. Familiarity is huge.

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

#165

Post by kakuri »

I'm seeing a lot of criticism of Atom's speed and responsiveness, and not much support. I wonder how many of these people are actually using it, and what computers they are using it on?

I tried Atom early, and repeatedly every month or three for a while, and the issue that prevented me from giving it a good trial was poor font rendering (on Windows at least). This issue has been fixed for about a month or more.

I've been using Atom full-time for just about a month now (having previously used Sublime Text 3 and Notepad++) and have no problems. As a programmer the quality of my workstation is fairly important to me, but I think my computer is not a powerhouse: Core i5-4570S 2.9GHz and 16GB RAM. I am fairly sensitive to editor responsiveness - I've tried dozens of editors over the years, and discount most of them for issues that some might consider to be minor, but are important to me - autocomplete responsiveness is a big one.

Atom may not load as quickly as Sublime, but once it's running I haven't had any issues with its performance. I use it for JavaScript and TypeScript programming, and for those purposes it is excellent.

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

#166

Post by taylorwc »

Guvante wrote: post #164
taylorwc wrote: post #149

Earlier quoted context omitted.

As someone who never really jumped into code until very recently, I find Atom far and away the most accessible text editor. Familiar interface (to a browser) and not overwhelming to set up. I've tried emacs, vim, and sublime. I'm sure that I could come to love emacs or vim, but it just seemed like too much messing with it before I would really enjoy it. Sublime is better, but I just prefer Atom. Guess that makes me s…

> As someone who never really jumped into code until very recently Honestly your first code editor is always the best until you find a killer feature. Familiarity is huge.

Actually Sublime was the first one I tried. And I liked it quite a bit more than vim or emacs, perhaps due to being a noob. But I still preferred Atom to Sublime.

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

#167

Post by snappy173 »

tootie wrote: post #152
zghst wrote: post #68

Earlier quoted context omitted.

JSX is simple, it is just simplified HTML. I think you may want to give it another try, sharpen your skills with it. It is not difficult to work with if you try. And on installing things, it is basically what any developer does these days. We install tools for almost anything. Just think of the JSX tools as another tool in your belt to help with the translation. The paradigm shift opens up your palette to new technol…

JSX is XML and it can cause some confusion. For instance the fact that you can only have one root node is not obvious.

it's very much not XML. it's closest to javascript.

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

#168

Post by mattmcknight »

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…

If the DOM itself is mutable, a primary philosophical problem I have with layering an immutable abstraction on top of it is that the inevitable leaks from things that lie outside of the immutable abstraction are hard to deal with.

It certainly makes sense to me to use immutable approaches in pure abstractions, but the world is mutable, so you have to be extremely clever to abstract that away.

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

#169

Post by taeric »

fumonko wrote: post #85
grandalf wrote: post #31

Atom is awesome, but it feels like they are reinventing emacs only without terminal support and much slower. I use both editors but find myself continuing to go back to emacs b/c of a few features that I can't do without.

likewise. Out of curiosity, which features are you referring to?

Speaking for myself, of course. TRAMP (especially with eshell and grep), IDO, magit, effortless buffer splits, org-mode, inline execution of elisp.

I am also rather used to the command set now. To the point that it just feels natural to jump around a file with emacs. ace-jump-mode is also good. Even something as simple as subword-mode is awesome.

Really, TRAMP has been the killer feature for me lately. The way it enhances grep results is ridiculously useful.

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

#170

Post by nine_k »

DennisP wrote: post #130
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.

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

It's probably possible to build a text editor using JS that would be usable in Netscape 4 on a 8 MB machine under Windows 3.1.

What Atom's authors aim is not just being usable; the try to make it comfortable. This a rather higher bar.

Post reply on HN