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 announcement. They don't have any margin for error there (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).
Also, as it was pointed out, Atom didn't really embrace much of React to start with (which is to their credit: always be very conservative when you're adopting a bleeding edge, unproven technology).
I think React has potential. It's at about the same stage of maturity that Angular was five years ago, and if it's as successful, we can expect it to enjoy five years of being the new darling in the Javascript world, until the Next Big Framework comes around.
I'm really enjoying how fast Javascript frameworks and practices are churning, it makes me feel like I'm witnessing the birth of a brand new software field with my very eyes.
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). Unlike Google with Angular, React is Facebook's baby, the FB team is constantly churning out great additions to React.
I feel though with these JS editors, they should just basically give up for the next 5 years or so. Switching between Atom / Brackets to Sublime or Vim is extremely painful, I can't stand how slow it is. I love adopting new technologies, but I do not have faith in JS applications outside of a browser, they are too slow and lack in features.
setInterval(function() { Array.prototype.slice.call(document.querySelectorAll('[data-reactid]')).forEach(function(element) { element.style.background = 'rgba(255,0,0,0.1)'; }) }, 500)
edit: the snippet is from Pete Hunt who is on the core React team (https://twitter.com/floydophone/status/557348616080076800)
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.
http://en.wikipedia.org/wiki/Instructions_per_second#Timelin...
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.
Another thing is that things do get faster. I think V8 has gotten 10x faster (at least) on real code since its inception. And that's despite JS not having changed.
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.
React is something which stands astride on a line that divides a framework and library. I believe, like all good libraries out there, which do one thing and one thing well, React might stay for a longer period of time. At the first look of it, it might look heavy and bloated but it professes a far simpler view of building UIs.
The best part is, just like jQuery, it didn't take me more than a few hours to get comfortable with React and incorporate it into building something, something that could have taken a few weeks with other frameworks. I am not saying there won't be anything better than this but I am sure it isn't just another hyped fad.
You're talking about a project developed in Coffeescript.
> I think their technical choice of going for Javascript will be their ultimate downfall,
This is debatable. Editors like cloud9 have acceptable performances and webtechs allow one to distribute software right in the browser,which fits a huge number of use cases.
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.
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 four orders of magnitude... instant is instant, to a human.
A browser is a tough place to build a text editor. You're running a huge, complicated, sophisticated text rendering and typesetting environment, which you're using only a vanishing fraction of but the browser doesn't know that and can't much optimize for it. (Some, sure, I'm sure it's got special routines for monospaced text, but it still can't know you won't just stick a picture in the middle of it a moment from now.) You're running on top of a fairly slow language, even after all the optimization work on it [1]. You're running in an environment that is deeply structured to be synchronous so if you accidentally write a for loop over anything that turns out to be larger than you expected, you've frozen your environment until you're done, to say nothing of accidentally handing the browser a big rendering job ("did you just open a directory with 20,000 files? here, let me render that for you..."). Any of these things individually might be overcome, but the combination is quite challenging. It's nifty that the browser lets you run "anywhere" but it is also in a lot of ways a crazy place to try to build a programmer-quality text editor.
[1]: I have to justify this every time I say it since somehow the idea that "Javascript is fast!" has sunk into the community, but it's not true. The easiest proof is asm.js... if Javascript was already "C-fast" or even close, it would not even exist. It exists precisely because Javascript is not a fast language. Javascript is much faster than it started out as, but it started out as an extraordinarily slow afterthought meant to run a statement or 4 in response to a mouse click. It has still stabilized on "much slower than C" and appears to have essentially plateaued. The result of speeding up something miserably slow by quite a bit can still result in something slow in the end.
I'd like to see this discussion today ;)
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 overhead introduced by allowing plugins to render entire webpages inline with the text is just too much.
I want so very much to like Atom --- a Free text editor that isn't vim or emacs and is actually powerful enough to replace them, but the imperceivable latency manifests as a gradual accumulation of stress.
Honestly your first code editor is always the best until you find a killer feature. Familiarity is huge.
I totally agree. A language or technology that doesn't change is dead. The JS world can get a crazy sometimes but we need to understand WHY certain frameworks/patterns may be better and when to apply them.
Kudos to the Atom team on making their product better.
* 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/
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...
I think the future is, like many abstractions, one where your tighter loops escape the abstraction (like numpy's C bindings). There's still advantages on a big-picture scale to using declarative frameworks like React
EDIT: one thing is that a text editor can know a lot better how to edit the DOM after an event (like hitting a character) than React's general algorithm
http://research.microsoft.com/apps/mobile/showpage.aspx?page...
Note that all the live editor examples in the essay are written in Glitch. Think of Glitch as a react like framework that focuses on fixing mutable state through time management rather than avoiding it.
Everything becomes familiar. Then someone tries something new. Sometimes it works, sometimes it doesn't, sometimes it promises more than it can deliver. But all the folks who stick with familiar will take the reasons that people leave, and roll their own solutions.
Sometimes a fad framework really is a bust, but more often than not, it's always a stepping stone and motivation for every project out there.
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.
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.
With the way developers use the DOM for things like text editors, it's no wonder that they may reach the limit of the browser performance. If we add too much stuff to the DOM, the browser does not have the flexibility of just "rendering the visible lines" like we could with the Canvas. The browser has to calculate everything again.
I was recently surprised when I added 100k table rows with 2 columns in a sample, and when I clicked on a button to toggle the visibility of some list items next to the table, the browser would take a few seconds to finish processing it. Since it was a sample test using React, I thought I would try it without React to see whether the slowdown was because of React somehow. But I found out that even without React it was about the same difference.
If you notice, Atom has a hard limit on 2MBs buffers. I just created a test loading almost 2 MBs in an Atom text tab, and it indeed became unresponsive. It took forever to load and then had problem handling text editing at the end of the buffer.
I think Atom would be better with Canvas. But many JavaScript editors use the DOM and for 1,000 lines they tend to work very well. Which is generally enough for running samples and such. Another advantage of the DOM is that they could more easily embed images and have varied size text, I guess. So those WYSIWYG HTML Editors may be better served by some DOM Editor.
I guess in the future Atom could also add a Canvas editor and keep both.
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 progress.
Interesting times.
I'd give the advantage there to Atom, given how sparse and irregular the ST3 change logs are.
I like the look and feel of Atom quite a bit, though, and I'm hopeful that the performance issues get worked out in time.
Project is dead but the program is a pretty fully-fledged text editor from what I have heard.
But, if you need extremely high performance and your problem is small (eg: the text editor part of atom), you can write specialized code that will compute the minimum set of mutations yourself and don't pay the cost of React. That's also why you see so many small benchmarks beating React but those wins don't translate in real applications.
Now, it doesn't mean yet that you should drop React. The great thing is that you can make a React component <TextEditor> that itself uses manual dom operations to be super fast. And the rest if your app uses React for its wins.
In Atom case, they also want to support people writing plugins. Now it's not only technical but becomes political. Do you want to force people to use React for writing plugins? What if they want to use jquery or ember or angular?
You also get into dependency issues. React requirement today is that there can only be one version loaded at the same time, otherwise everything breaks. If you update React in Atom core, you run the risk of breaking all the plugins that were written for a different version of React.
Given those, it makes sense to remove React as a dependency from the core. Fortunately, it's still totally possible to write atom plugins using React
Is this still an issue when you override `ID_ATTRIBUTE_NAME`?
require('react/lib/DOMProperty').ID_ATTRIBUTE_NAME = 'data-myproductid';
It is, I've written some quite impressive widgets and it performs really well.
Underestimating the difficulty of that task (or a structurally equivalent one) is remarkably common. I don't know if it's because devs all think we know better than our neighbor or because we don't accurately gauge the cost of adding new features. In any case, it's depressing.
I suspect that Atom editor is a bit of a pathological case for something like React - a very flat hierarchy with lots of children can result in lots of expensive React renders, then subsequent virtual DOM diffing, for what effectively amounts to appending a character to the text area.
>> pathological case for something like React.
The is absolutely likely to be the case (for now). I admit I haven't looked into the technical issues very much because I've been spending 100% my time on ReactNative which seeks to resolve the deepest issues with the browser environment for React development - it's certainly a different kind of performance work.
For this kind of stuff, most people create a highly custom React base class that "cuts right to the chase" as far as updating small pieces that change in large lists. Immutable data structures are often the most helpful tool in accomplishing that. I'm sure they have totally legitimate reasons to go with this approach in the mean time, and most of all I want their project Atom to succeed because it's such a great idea. I hope we can help the Atom team soon to resolve these other issues though.
This is said often but without much qualification. I've found mutable data structures with change propagation (via observable or what not) to work much better given that the whole diffing thing can be avoided altogether since you know exactly what has changed.
It is my understanding that the DOM is broken in how it handles invalidation/re-rendering (doing it for each modification rather than batching), but again, I don't see how immutability helps fix that problem any better than just doing it the right way with a mutable virtual DOM?
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.
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.
I do think Atom has the potential to really go beyond what emacs has accomplished b/c more people know js/coffee than elisp, but emacs is also a moving target and has become a lot better than it was 10 years go.
Overall it looks like React guided them in the right direction for how to design their view code, but they don't actually need most of React's functionality.
Was it just a relatively constant amount of overhead that everything using React will experience regardless of how much of React is "used"? Why is the overhead so high?
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.
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.
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.
<div>Hey, <span class="myapp-name" /> how are you!</div>
controller.onStateChanged("name").set(function () {
$(".myapp-name", container).html(state.name);
});
React kind of encourages building the components the second way. It eschews two-way binding in favor of a code-based rendering approach. IoC pattern isn't the same as embracing a declarative style where static data contains instructions.
So, React is more efficient and mitigates the code-based rendering by introducing JSX inside JS. Basically, the templates are declared inside your JS files. Same as in Angular you'd have directives.
But then the question becomes, why do you need to do all the fancy DOM diffing, also? Just fire events when an attribute of some ViewModel changes. Attach event listeners to recompute some values and then do DOM updates using a library like FastDOM. I guess React could help in the diffing by storing copies of your DOM snippets, but that's usually not the biggest bottleneck. You usually ALREADY store the previous state in JS and can see what changed, before rendering. With libraries like Fastdom or GSAP updates are plenty fast to the point of powering 60fps animations!
<div>Hey, {{name}} how are you!</div>
now if you're really smart you'll write a compiler that desugar and inline everything so you get the best of both world: A declarative syntax and production speed.
I wonder if they'll be switching back to whatever editor they used before Atom.
Why, I can't speak to the reasons in this case but I suppose when you allow any user to make up anything for a title, they sometimes inject their own opinion or otherwise make the title not properly reflect the intent of the original title. Not saying this is what happened here.
Of course it can go the other way. Sometimes original titles are not clear, and the HN title can get preserved or changed for clarity or neutrality.
So React taught them how to update the DOM manually ;) I suspect the case of a text editor is systematic enough so that they can have a specialized and minimal DOM update algo, without too much maintenance cost (which would be high if you try to implement specific minimal DOM update in a random app).
It's kind of sad to me because we'd be a lot farther in the future if there was one library that made dom elements faster than any other library, and one library that made diffing faster than any other library. But we're stuck with these monsters of frameworks that black box so hard for syntax that they completely give up on solving the problems they meant to.
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!
The big caveat is that we're using it on Phonegap where javascript operations are much more expensive. I.e. something that takes 5ms on my laptop takes up to 50-100ms on the phone. So, unfortunately, the "Pure React" approach didn't work on some page because there were too much comparisons.. 95% of the app use Pure React and is much faster than before, but in some very specific cases, we have to use mutation and mutate the DOM manually. I think it's a totally fair tradeoff for all the benefits we got from using React.. Similar to using Python but having some optimization in C when necessary.
Atom was already at a disadvantage on both counts on account of it being a Javascript app running inside chromeless Chrome. Making a browser do large things fast is difficult, and having React's paradigm of diffing a now huge virtual DOM running on every single keystroke can't really work.
React still works great for smaller and more demanding sites, though - but it does hit limits on large and complex DOM diffs at high frequencies with low latency demands.
React isn't a magic bullet without using shouldComponentUpdate, and shouldComponentUpdate really works best with immutable data. Immutable data works best all in... See where this all in keeps going? Basically atom didn't wanr react to dictate their entire app and dictate how the plugins would all have to be rendered.
https://discuss.atom.io/t/whats-the-status-of-react-in-atom/...
There are a few issues in play here:
(1) Atom wants to support a world in which every Atom package can install whatever version of a dependency it wants, including React. This is very common in Node (incidentally, this causes problems if you want to use singletons or instanceof in Node), but fairly uncommon on the Web (where React is primarily used). That is, it's rare that you inadvertently load multiple versions of React in your single-page application. If you did, you would likely get an error when adding one React component as a child of another React component because of the way React vends ids. (Solutions are possible, but none is employed today.)
From Atom's perspective, that is a problem. The only way they can work around it is by providing "one true version of React" with Atom core that all packages must use, but then Atom is forcing all packages to use a particular version of React. That would violate Atom's philosophy of letting each package choose its own dependencies.
(2) This is not just an issue for React, but for any UI toolkit whose components are not guaranteed to interoperate across versions. To sidestep this issue, Atom has currently decided to use the DOM API/HTML custom elements. I would call this the "least common denominator approach," which satisfies Atom's design goals, but fails to provide a higher-level abstraction for building UI in Atom. It's a tradeoff.
(3) React does not currently support the shadow DOM or custom attributes, which is the new direction that Atom has chosen. As React has not yet been evicted from Atom core, I recently upstreamed a change (https://github.com/atom/react/pull/1) to add one-off support for Atom's primary custom elements, <atom-text-editor mini> and <atom-panel>, in the fork of React bundled with Atom. As I develop Atom packages using babel (formerly 6to5) http://blog.atom.io/2015/02/04/built-in-6to5.html, which has default support for JSX, building UI in React has been a lot of fun. However, the lack of support for custom attributes makes it difficult to do things like add an appropriate onChange handler to an <atom-text-editor> to update the React component's state as shown in http://facebook.github.io/react/docs/forms.html.
(4) React is still version 0.x.x, which means it has not yet committed to a stable API. This makes choosing a version of React to bundle with Atom an even more uncomfortable decision for the Atom team, assuming they were willing to do so in the first place.
None of these items implies that there is something fundamentally broken about React's model. It just means that the React team has some work to do in order to support Atom's use case. The performance graphs cited in the original post are also significant (and of interest to the React team), but even if the performance problems were fixed tomorrow, that alone would probably not be enough for Atom to pull React back into core right now.
Let's not forget how kick ass React is y'all.
More seriously: maybe sometimes, late optimization can be a bad thing. That's where one should talk about performance design concerns.