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.
“Implement text editor DOM updates manually instead of via React”
31–40 of 225 posts
Re: “Implement text editor DOM updates manually instead of via React”
#32well, that was quick. =)
Re: “Implement text editor DOM updates manually instead of via React”
#33I 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.
Re: “Implement text editor DOM updates manually instead of via React”
#34I remember when Atom first started to Fork and I left it. I could handle the clunkiness and performance. I find that with React and my vim editor, I'm happy coding again. If React could just borrow a few more ideas from Angular I think it would be on the right track to gain even more widespread momentum.
Re: “Implement text editor DOM updates manually instead of via React”
#35well, 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 faster than the latter, its just hard to find good coders.
Re: “Implement text editor DOM updates manually instead of via React”
#36That 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...
They're using an approach that is absolutely inspired by React, for a use case that is inhospitable, pathalogical even, to a "generic web" approach to performance.
Choosing to not use React itself to implement the editing component of a text editor? Not a big deal at all.
This is not a solid "everyone moving away from React" example at all.
Re: “Implement text editor DOM updates manually instead of via React”
#37Some of the React devs were using Atom during the React Conf. I assumed they did so to have more interaction with apps that use their library to find more opportunities for improvement.
I wonder if they'll be switching back to whatever editor they used before Atom.
Re: “Implement text editor DOM updates manually instead of via React”
#38I 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.
It might have something to do with the demographics. Text editor users are developers, power users, or at the very least, very tech savvy (there is also the other extreme of the spectrum, people who know nothing better, but you get my point). With that demographics, we (at least I know I do) tend to be more picky.
The majority of people are content with coffee-making-loading-time for their OS, and the slug that is called Microsoft Word or Adobe Reader.
Re: “Implement text editor DOM updates manually instead of via React”
#39I 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…
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…
Do you know of a large open source react application that I can take a look at?
Re: “Implement text editor DOM updates manually instead of via React”
#40Earlier quoted context omitted.
> and to be honest, I think their technical choice of going for Javascript will be their ultimate downfall, but that's a discussion for another day I'd like to see this discussion today ;)
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…
Just curious - why replace vim or emacs?