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

171–180 of 225 posts

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

#171

Post by addicted44 »

taylorwc wrote: post #166
Guvante wrote: post #164

Earlier quoted context omitted.

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

If you will be programming professionally (or for significant amounts of time) learning either of emacs or vim is absolutely worth the effort.

You will be very glad you did.

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

#172

Post by nine_k »

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.

Vim can be blazingly fast and maddeningly slow — it all depends on the plugins you have activated.

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

#173

Post by dlisboa »

kakuri wrote: post #165

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…

> but I think my computer is not a powerhouse: Core i5-4570S 2.9GHz and 16GB RAM.

SSD would be more important for editor evaluation, but I'm willing to bet you're in the top 1% as far as personal workstation performance goes. That's an absolute machine. If you can't make a responsive editor with those specs, just give up.

I know a lot of programmers, however, and some who use Atom while enjoying specs much more humble than yours. They seem to manage alright. I wouldn't, but startup time and lags are more important to me than to others. As evidenced by the multitude of Atom users performance isn't that big of a deal to a lot of people.

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

#174

Post by pjmlp »

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.

HTML is anything but general purpose.

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

#175

Post by atonse »

ProAm wrote: post #35
AdrianRossouw wrote: post #32

well, that was quick. =)

It's not really a surprise that if you manually code something (with someone who knows what they are doing) that its better than a framework. Frameworks are there to help eliminate duplication (DRY), and to help people who are new to coding advance quicker than if they learned on their own, it also helps to add consistency to results. I'd always say doing something without a framework well would almost always be fast…

As others have said, this is a unique situation for the text editor component.

In a lot of more conventional situations, it's very likely that React's diffing code is highly tuned for performance over years and will do as good a job as you manually writing the JS, while saving you a ton of time in having to worry constantly about the DOM.

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

#176

Post by mmgutz »

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.

i tried but sublime doesn't work in SSH :(

You're right. Editing a large file with syntax coloring and vim slows to a crawl. I just can't get away from Vim though as it works so well in terminals.

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

#177

Post by zghst »

e1g wrote: post #83
zghst wrote: post #66

Earlier quoted context omitted.

Fake test. React Components don't always return a DOM element, also not every element shows up all the time, instead you should download the React dev tools. There are at least 30-40 top level components on Facebook. Nice try though.

You are of course correct that some React components will not be caught by this single-line test. It is impossible to truly know unless you are the author of the app, and that's the case even with React tools (e.g. you would not be able to identify my server-rendered components that are not mounted on the front-end). The intent was not to provide a debugging tool - it's just to provide people with limited exposure to…

I'm sorry I attacked you, thought you were saying different

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

#178

Post by ceedan »

ryanSrich wrote: post #60
zghst wrote: post #27

Earlier quoted context omitted.

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…

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.

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

#179

Post by ceedan »

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 is obvious, because when you use a component, it's usage is as a single root node.

should not render multiple root nodes.

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

#180

Post by CJefferson »

pjmlp wrote: post #52
adrusi wrote: 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.

Is it any more insane than effectively running applications over telnet (that is, a fixed width text terminal)? :)
Post reply on HN