38 ms·

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

339 points by spleeder 12y ago

rdtsc 12y ago
That 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...
- Untit1ed 12y ago
  Haha, it was only a matter of time (measured in weeks) until React was over. The new hotness is evidently manually setting innerHTML.
- rtpg 12y ago
  Atom is very different from other things. The editor component is something that revolves almost entirely about state, and a huge amount of state at that. 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
  - seanmcdirmid 12y ago
    This is why I designed Glitch: http://research.microsoft.com/apps/mobile/showpage.aspx?page=/en-us/people/smcdirm/managedtime.aspx 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.
    - warkid 12y ago
      I believe that the page you referenced to is broken. I.e. no videos or code samples on, see screenshot - http://snag.gy/lMAp8.jpg http://snag.gy/lMAp8.jpg
      - seanmcdirmid 12y ago
        Ugh...mobile link, this should work: http://research.microsoft.com/en-us/people/smcdirm/managedtime.aspx http://research.microsoft.com/en-us/people/smcdirm/managedti...
    - bglazer 12y ago
      Hi Sean, having skimmed the presentation you linked to, Glitch's programming model seems similar to VHDL and Verilog, in that the "tick" is an explicit construct and statements are not guaranteed to execute sequentially. I'm not experienced in VHDL, so I might be completely wrong here. Did you take any design cues or inspiration from hardware design languages?
      - seanmcdirmid 12y ago
        There is an inspiration from synchronous reactive languages, which are in turn inspired by hardware design (not sure if they predate or post date vhdl); you can read the related work section of the essay-linked conference paper if you are interested about lineage. Glitch is a bit weirder in that all statements execute at the same time within a tick, their order isn't just unfixed: they are guaranteed to see all of each other's effects (except event handlers, which execute more hardware-like discretely to do state transitions).
- michaelchisari 12y ago
  After having watched so many frameworks come and go, the pattern I've noticed is that it's not just about hotness. It's that the new ideas that the frameworks provide push everyone else into better directions. 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.
- quadratini 12y ago
  He's missing the point of Declarative vs Imperative and Virtual DOM vs Data Binding if he thinks it will circle back to jQuery.
- prapam2 12y ago
  At least until something better comes along i am going with React. React makes lot easier and cleaner to build apps. I have built a stock ticker app with changing values and highlighting the change. Initially there were few performance issues, but using immutable data and shouldcomponentupdate those were resolved.
- jdub 12y ago
  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.
- cmpb 12y ago
  Given the huge feature gains in vanilla JS over the past few years (and in particular, the past year via ES6), I think we'll see more people shedding frameworks altogether. At least for the common tasks that were accomplished / made simpler by jQuery.
- kansface 12y ago
  Atom already wraps jQuery - they wrote their own DSL for mutating the DOM called space-pen[1]. They tried to get rid of it later (and rightfully so), but its too late now. 1. https://github.com/atom/space-pen https://github.com/atom/space-pen
- lmm 12y ago
  The hype cycle is a well-known, predictable thing that happens to almost every new technology.
kylec 12y ago
This is really interesting. In the summer of last year, I was looking into various JS libraries to use for an upcoming project at work when I saw the story that Atom was moving to React for their UI, so I decided to take a look. The philosophy really clicked with me and that's what we ended up going with. I don't regret that choice - it's worked out really well for us so far - but it's interesting that it hasn't for Atom. 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.
- jordwalke 12y ago
  (I'm on the ReactJS team at Facebook) >> 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.
  - seanmcdirmid 12y ago
    > Immutable data structures are often the most helpful tool in accomplishing that. 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?
bostonvaulter2 12y ago
Is there a chance that they'll get bogged down tracking exactly what HTML needs to change for each update?
- bostonvaulter2 12y ago
  Is this really worth being downvoted? It is an honest question.
plorkyeran 12y ago
It looks like they weren't actually using React for much. The diff is +230 lines, and there's close to that much of just new tests. Most of the actual changes are trivial (e.g. @isMounted() to @mounted) and there's not all that much DOM manipulation logic in the end result. 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.
- jsprogrammer 12y ago
  I haven't looked at the code, but since you have, why were they experiencing so much overhead if it wasn't being used for much? 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?
  - xahrepap 12y ago
    I haven't read the code, but I can make an guess as to why (at least one reason): Atom is using one web-renderer. React supports many version of many renderers/browser. Drop all that cruft and just go directly to the 'native' code.
    - mrbtie 12y ago
      This change doesn't seem to be about removing boilerplate to support multiple browsers, though. They're not implementing their own virtual dom diff their "one web-renderer", but moving away from this technology.
mrmondo 12y ago
I really don't like the idea of running an editor written in JS - I just tried out the latest stable build and it's still very much slower than Sublime Text 3.
- unknownian 12y ago
  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.
  - rurounijones 12y ago
    Just in case you don't know about it. If you are looking for an editor written, and extensible, in (j)ruby then there is always http://redcareditor.com/ http://redcareditor.com/ Project is dead but the program is a pretty fully-fledged text editor from what I have heard.
  - peteretep 12y ago
    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.
    - kbenson 12y ago
      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).
- noarchy 12y ago
  Much slower, indeed. You don't have to introduce a very large file before Atom starts to crawl. And good luck executing a search on such a file. 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.
deleted 12y ago
[deleted]
- kin 12y ago
  When React Native gets released you'll definitely see the hype train start up again.
- girishso 12y ago
  It's really easy to dismiss React. My suggestion would be to give it a try... it's very easy to pick up (unlike Angular) and would suit most of the use cases where you would use Angular. Writing a state heavy code editor in React is definitely not a best use case for React.
zak_mc_kracken 12y ago
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 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.
- Goopplesoft 12y ago
  > 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 ;)
  - adrusi 12y ago
    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 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.
zghst 12y ago
One editor barely using React doesn't mean it's going to swing back the other way now. React actually has good ideas and breathes fresh air into the JS community. Let's not forget how kick ass React is y'all.
shurcooL 12y ago
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 progress. Interesting times. [1] http://limetext.org/ http://limetext.org/
- methyl 12y ago
  Can you add something more about what is the minihtml module? Google says nothing.
  - unfamiliar 12y ago
    I came here wondering the same thing. Based on the comments above, and what I know of the two editors, and the fact that there were some improvements to minihtml and suddenly today the sublime text changelog popped in HTML format, I would guess that minihtml is a light html renderer that can be used by plugins inside of sublime text. Atom already has this ability by design, so it can do things like draw a usage graph in a side panel, while previously sublime text could only have text-based panels produced by plugins. If I am correct, minihtml should allow plugins to display more complex user interfaces and data through the a minihtml pane.
  - shurcooL 12y ago
    Grep the ST3 dev channel changelog [1] for "minihtml". [1] http://www.sublimetext.com/3dev http://www.sublimetext.com/3dev
    - budrick 12y ago
      All well and good, but that doesn't explain what it is, only that it's been worked on.
- zyxley 12y ago
  >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.
grandalf 12y ago
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.
- fumonko 12y ago
  likewise. Out of curiosity, which features are you referring to?
  - taeric 12y ago
    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.
  - grandalf 12y ago
    I like indent-region and the simplicity of C-x b to switch buffers. 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.
AdrianRossouw 12y ago
well, that was quick. =)
- ProAm 12y ago
  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.
  - atonse 12y ago
    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.
somanim 12y ago
I 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.
xtrumanx 12y ago
Some 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.
- vjeux 12y ago
  Nop, sticking with Atom :) it's awesome because it lets us write plugins with web technologies. Even though they pull React off of the core, it's still possible to use React to write plugins :)
vjeux 12y ago
Modifying the DOM is usually the bottleneck in web apps. To get a fast app (extreme simplification), you need to only apply the minimum set of mutations. It turns out that in a large codebase this is extremely hard to do. React asks the developer for a virtual representation and computes the diff between the previous one. In most situations, the time it takes to compute the set of mutations is negligible compared to the cost of the unneeded dom mutations it removed. 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
- couchand 12y ago
  It turns out that in a large codebase this is extremely hard to do. 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.
- mlangenberg 12y ago
  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. Is this still an issue when you override `ID_ATTRIBUTE_NAME`? require('react/lib/DOMProperty').ID_ATTRIBUTE_NAME = 'data-myproductid'; I am wondering if React is usable for writing a JS Widget, for example Disqus.
blt 12y ago
"Text editor has moved away from 10,000x performance overhead to 1000x"
- elcct 12y ago
  If you work at web scale you should have some spare cores in the cloud to throw at the tasks ;)
bolinfest 12y ago
For context, here's a discussion from the Atom forum that we had way back in August about the future of React in Atom: https://discuss.atom.io/t/whats-the-status-of-react-in-atom/11456 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 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 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 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.
spleeder 12y ago
Who changed the title of this post and why?
- natch 12y ago
  It's pretty common for post titles to be changed (by HN admins). The most frequent change I see is they change the title to match the title of the original linked article/story/whatever, which seems to be the case here. 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.
gorm 12y ago
From an user experience this optimization seems to have little effect I would guess. When you type, 2ms isn't noticeable. But it's a sign of good engineering and focus on details.
EGreg 12y ago
Angular touted its declarative syntax, but really what does that give you? It saves a few strokes over something like <div>Hey, <span class="myapp-name" /> how are you!</div> And then in your javascript: controller.onStateChanged("name").set(function () { $(".myapp-name", container).html(state.name); }); The latter is more explicit and also declarative. It also gives you a lot more flexibility and is much more efficient than dirty-checking. 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!
- aikah 12y ago
  <div>Hey, {{name}} how are you!</div> When one has 500+ states to manage, it's not just a matter of saving a few strokes anymore. 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.
  - zkhalique 12y ago
    What would be the syntax of the declarative code in the template?
ntoshev 12y ago
They saw an improvement when they introduced React too... http://blog.atom.io/2014/07/02/moving-atom-to-react.html http://blog.atom.io/2014/07/02/moving-atom-to-react.html 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).
jokoon 12y ago
Sounds like premature optimization. /s More seriously: maybe sometimes, late optimization can be a bad thing. That's where one should talk about performance design concerns.
sudhirj 12y ago
In 20/20 hindsight, using React for a text editor isn't a very good choice. Text editors, especially ones geared towards fast typists / programmers, are a double whammy in terms of being latency sensitive and needing to open large files. 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.
PSeitz 12y ago
So is it fast now? I doubt that Atom will ever expect my performance needs, but will give it a try.
z3t4 12y ago
I hope they implement function parameter help and function list for JavaScript.
antihero 12y ago
I wonder if we'll ever see a React Curses module for React Native.
scotty79 12y ago
Too bad that they didn't just improve React to better handle their use case. Tossing it an hacking DOM updates manually seems like a cop out.
hondaz54 12y ago
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)?
- spleeder 12y ago
  I think this is a very good question, and the short answer in my opinion is yes, canvas rendering would make it much faster (as the guys at Flipboard have shown [1]). The downside is you would have to implement your own rendering engine from scratch which is quite challenging. [1] http://engineering.flipboard.com/2015/02/mobile-web/ http://engineering.flipboard.com/2015/02/mobile-web/
- dingdingdang 12y ago
  It certainly would be possible, take a look at what is done with canvas out there! But it would be a LOT of work to get the rendering right, most guys who implement "fast" text editors these days are not super intelligent hyper programmers but simply people who prefer to embed native OS text rendering views instead of inventing 10x odd gui junk on top of them.
- antimatter15 12y ago
  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.
  - seanmcdirmid 12y ago
    Doesn't canvas have its own GPU accelerated batched draw operations? All tast needs to be accelerated, really, is font rendering, and I would be very surprised if it wasn't.
  - spleeder 12y ago
    Canvas is hardware accelerated.
forthefuture 12y ago
The problem with anything that has to be compatible with everything is that the overhead will necessarily get to a point that you can't reasonably use it in production code. Not to say people won't still do it anyway, just that if you're looking for a bottleneck, you don't have to look very far. Until "frameworks" start being broken up into modules with individual functionality (kind of like how everyone tells you to learn how to program), there will always be churn like this. 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.
marijn 12y ago
Vaguely related: CodeMirror's story http://marijnhaverbeke.nl/blog/display-updates-in-codemirror.html http://marijnhaverbeke.nl/blog/display-updates-in-codemirror...
kakuri 12y ago
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.
- dlisboa 12y ago
  > 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.
- VeejayRampay 12y ago
  How is a Core i5 2.9GHz with 16GB RAM not considered a "powerhouse"?
zkhalique 12y ago
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!
d0m 12y ago
Just chiming in. Switched from Angular to React, and saw massive improvement on any fronts. Maintainability, Speed of development, performance, etc. 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.
d0m 12y ago
Just chiming in. Switched from Angular to React, and saw massive improvement on any fronts. Maintainability, Speed of development, performance, etc. 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.
nickstefan12 12y ago
It seems like they never really gave react a real chance. although react is just a view render, to really get its red line performance requires going all in. I think it would have been worth it. a unidirectional data flow is worth the pain. It's so much easier to design something that only ever has to "rerender". 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.

339 points by spleeder 12y ago

rdtsc 12y ago

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

Untit1ed 12y ago
Haha, it was only a matter of time (measured in weeks) until React was over. The new hotness is evidently manually setting innerHTML.
rtpg 12y ago
Atom is very different from other things. The editor component is something that revolves almost entirely about state, and a huge amount of state at that. 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
- seanmcdirmid 12y ago
  This is why I designed Glitch: http://research.microsoft.com/apps/mobile/showpage.aspx?page=/en-us/people/smcdirm/managedtime.aspx 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.
  - warkid 12y ago
    I believe that the page you referenced to is broken. I.e. no videos or code samples on, see screenshot - http://snag.gy/lMAp8.jpg http://snag.gy/lMAp8.jpg
    - seanmcdirmid 12y ago
      Ugh...mobile link, this should work: http://research.microsoft.com/en-us/people/smcdirm/managedtime.aspx http://research.microsoft.com/en-us/people/smcdirm/managedti...
  - bglazer 12y ago
    Hi Sean, having skimmed the presentation you linked to, Glitch's programming model seems similar to VHDL and Verilog, in that the "tick" is an explicit construct and statements are not guaranteed to execute sequentially. I'm not experienced in VHDL, so I might be completely wrong here. Did you take any design cues or inspiration from hardware design languages?
    - seanmcdirmid 12y ago
      There is an inspiration from synchronous reactive languages, which are in turn inspired by hardware design (not sure if they predate or post date vhdl); you can read the related work section of the essay-linked conference paper if you are interested about lineage. Glitch is a bit weirder in that all statements execute at the same time within a tick, their order isn't just unfixed: they are guaranteed to see all of each other's effects (except event handlers, which execute more hardware-like discretely to do state transitions).
michaelchisari 12y ago
After having watched so many frameworks come and go, the pattern I've noticed is that it's not just about hotness. It's that the new ideas that the frameworks provide push everyone else into better directions. 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.
quadratini 12y ago
He's missing the point of Declarative vs Imperative and Virtual DOM vs Data Binding if he thinks it will circle back to jQuery.
prapam2 12y ago
At least until something better comes along i am going with React. React makes lot easier and cleaner to build apps. I have built a stock ticker app with changing values and highlighting the change. Initially there were few performance issues, but using immutable data and shouldcomponentupdate those were resolved.
jdub 12y ago
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.
cmpb 12y ago
Given the huge feature gains in vanilla JS over the past few years (and in particular, the past year via ES6), I think we'll see more people shedding frameworks altogether. At least for the common tasks that were accomplished / made simpler by jQuery.
kansface 12y ago
Atom already wraps jQuery - they wrote their own DSL for mutating the DOM called space-pen[1]. They tried to get rid of it later (and rightfully so), but its too late now. 1. https://github.com/atom/space-pen https://github.com/atom/space-pen
lmm 12y ago
The hype cycle is a well-known, predictable thing that happens to almost every new technology.

kylec 12y ago

This is really interesting. In the summer of last year, I was looking into various JS libraries to use for an upcoming project at work when I saw the story that Atom was moving to React for their UI, so I decided to take a look. The philosophy really clicked with me and that's what we ended up going with. I don't regret that choice - it's worked out really well for us so far - but it's interesting that it hasn't for Atom. 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.

jordwalke 12y ago
(I'm on the ReactJS team at Facebook) >> 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.
- seanmcdirmid 12y ago
  > Immutable data structures are often the most helpful tool in accomplishing that. 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?

bostonvaulter2 12y ago

Is there a chance that they'll get bogged down tracking exactly what HTML needs to change for each update?

bostonvaulter2 12y ago
Is this really worth being downvoted? It is an honest question.

plorkyeran 12y ago

It looks like they weren't actually using React for much. The diff is +230 lines, and there's close to that much of just new tests. Most of the actual changes are trivial (e.g. @isMounted() to @mounted) and there's not all that much DOM manipulation logic in the end result. 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.

jsprogrammer 12y ago
I haven't looked at the code, but since you have, why were they experiencing so much overhead if it wasn't being used for much? 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?
- xahrepap 12y ago
  I haven't read the code, but I can make an guess as to why (at least one reason): Atom is using one web-renderer. React supports many version of many renderers/browser. Drop all that cruft and just go directly to the 'native' code.
  - mrbtie 12y ago
    This change doesn't seem to be about removing boilerplate to support multiple browsers, though. They're not implementing their own virtual dom diff their "one web-renderer", but moving away from this technology.

mrmondo 12y ago

I really don't like the idea of running an editor written in JS - I just tried out the latest stable build and it's still very much slower than Sublime Text 3.

unknownian 12y ago
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.
- rurounijones 12y ago
  Just in case you don't know about it. If you are looking for an editor written, and extensible, in (j)ruby then there is always http://redcareditor.com/ http://redcareditor.com/ Project is dead but the program is a pretty fully-fledged text editor from what I have heard.
- peteretep 12y ago
  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.
  - kbenson 12y ago
    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).
noarchy 12y ago
Much slower, indeed. You don't have to introduce a very large file before Atom starts to crawl. And good luck executing a search on such a file. 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.

deleted 12y ago

[deleted]

kin 12y ago
When React Native gets released you'll definitely see the hype train start up again.
girishso 12y ago
It's really easy to dismiss React. My suggestion would be to give it a try... it's very easy to pick up (unlike Angular) and would suit most of the use cases where you would use Angular. Writing a state heavy code editor in React is definitely not a best use case for React.

zak_mc_kracken 12y ago

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

Goopplesoft 12y ago
> 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 ;)
- adrusi 12y ago
  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 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.

zghst 12y ago

One editor barely using React doesn't mean it's going to swing back the other way now. React actually has good ideas and breathes fresh air into the JS community. Let's not forget how kick ass React is y'all.

shurcooL 12y ago

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 progress. Interesting times. [1] http://limetext.org/ http://limetext.org/

methyl 12y ago
Can you add something more about what is the minihtml module? Google says nothing.
- unfamiliar 12y ago
  I came here wondering the same thing. Based on the comments above, and what I know of the two editors, and the fact that there were some improvements to minihtml and suddenly today the sublime text changelog popped in HTML format, I would guess that minihtml is a light html renderer that can be used by plugins inside of sublime text. Atom already has this ability by design, so it can do things like draw a usage graph in a side panel, while previously sublime text could only have text-based panels produced by plugins. If I am correct, minihtml should allow plugins to display more complex user interfaces and data through the a minihtml pane.
- shurcooL 12y ago
  Grep the ST3 dev channel changelog [1] for "minihtml". [1] http://www.sublimetext.com/3dev http://www.sublimetext.com/3dev
  - budrick 12y ago
    All well and good, but that doesn't explain what it is, only that it's been worked on.
zyxley 12y ago
>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.

grandalf 12y ago

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.

fumonko 12y ago
likewise. Out of curiosity, which features are you referring to?
- taeric 12y ago
  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.
- grandalf 12y ago
  I like indent-region and the simplicity of C-x b to switch buffers. 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.

AdrianRossouw 12y ago

well, that was quick. =)

ProAm 12y ago
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.
- atonse 12y ago
  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.

somanim 12y ago

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

xtrumanx 12y ago

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

vjeux 12y ago
Nop, sticking with Atom :) it's awesome because it lets us write plugins with web technologies. Even though they pull React off of the core, it's still possible to use React to write plugins :)

vjeux 12y ago

Modifying the DOM is usually the bottleneck in web apps. To get a fast app (extreme simplification), you need to only apply the minimum set of mutations. It turns out that in a large codebase this is extremely hard to do. React asks the developer for a virtual representation and computes the diff between the previous one. In most situations, the time it takes to compute the set of mutations is negligible compared to the cost of the unneeded dom mutations it removed. 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

couchand 12y ago
It turns out that in a large codebase this is extremely hard to do. 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.
mlangenberg 12y ago
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. Is this still an issue when you override `ID_ATTRIBUTE_NAME`? require('react/lib/DOMProperty').ID_ATTRIBUTE_NAME = 'data-myproductid'; I am wondering if React is usable for writing a JS Widget, for example Disqus.

blt 12y ago

"Text editor has moved away from 10,000x performance overhead to 1000x"

elcct 12y ago
If you work at web scale you should have some spare cores in the cloud to throw at the tasks ;)

bolinfest 12y ago

For context, here's a discussion from the Atom forum that we had way back in August about the future of React in Atom: https://discuss.atom.io/t/whats-the-status-of-react-in-atom/11456 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 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 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 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.

spleeder 12y ago

Who changed the title of this post and why?

natch 12y ago
It's pretty common for post titles to be changed (by HN admins). The most frequent change I see is they change the title to match the title of the original linked article/story/whatever, which seems to be the case here. 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.

gorm 12y ago

From an user experience this optimization seems to have little effect I would guess. When you type, 2ms isn't noticeable. But it's a sign of good engineering and focus on details.

EGreg 12y ago

Angular touted its declarative syntax, but really what does that give you? It saves a few strokes over something like <div>Hey, <span class="myapp-name" /> how are you!</div> And then in your javascript: controller.onStateChanged("name").set(function () { $(".myapp-name", container).html(state.name); }); The latter is more explicit and also declarative. It also gives you a lot more flexibility and is much more efficient than dirty-checking. 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!

aikah 12y ago
<div>Hey, {{name}} how are you!</div> When one has 500+ states to manage, it's not just a matter of saving a few strokes anymore. 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.
- zkhalique 12y ago
  What would be the syntax of the declarative code in the template?

ntoshev 12y ago

They saw an improvement when they introduced React too... http://blog.atom.io/2014/07/02/moving-atom-to-react.html http://blog.atom.io/2014/07/02/moving-atom-to-react.html 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).

jokoon 12y ago

Sounds like premature optimization. /s More seriously: maybe sometimes, late optimization can be a bad thing. That's where one should talk about performance design concerns.

sudhirj 12y ago

In 20/20 hindsight, using React for a text editor isn't a very good choice. Text editors, especially ones geared towards fast typists / programmers, are a double whammy in terms of being latency sensitive and needing to open large files. 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.

PSeitz 12y ago

So is it fast now? I doubt that Atom will ever expect my performance needs, but will give it a try.

z3t4 12y ago

I hope they implement function parameter help and function list for JavaScript.

antihero 12y ago

I wonder if we'll ever see a React Curses module for React Native.

scotty79 12y ago

Too bad that they didn't just improve React to better handle their use case. Tossing it an hacking DOM updates manually seems like a cop out.

hondaz54 12y ago

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

spleeder 12y ago
I think this is a very good question, and the short answer in my opinion is yes, canvas rendering would make it much faster (as the guys at Flipboard have shown [1]). The downside is you would have to implement your own rendering engine from scratch which is quite challenging. [1] http://engineering.flipboard.com/2015/02/mobile-web/ http://engineering.flipboard.com/2015/02/mobile-web/
dingdingdang 12y ago
It certainly would be possible, take a look at what is done with canvas out there! But it would be a LOT of work to get the rendering right, most guys who implement "fast" text editors these days are not super intelligent hyper programmers but simply people who prefer to embed native OS text rendering views instead of inventing 10x odd gui junk on top of them.
antimatter15 12y ago
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.
- seanmcdirmid 12y ago
  Doesn't canvas have its own GPU accelerated batched draw operations? All tast needs to be accelerated, really, is font rendering, and I would be very surprised if it wasn't.
- spleeder 12y ago
  Canvas is hardware accelerated.

forthefuture 12y ago

The problem with anything that has to be compatible with everything is that the overhead will necessarily get to a point that you can't reasonably use it in production code. Not to say people won't still do it anyway, just that if you're looking for a bottleneck, you don't have to look very far. Until "frameworks" start being broken up into modules with individual functionality (kind of like how everyone tells you to learn how to program), there will always be churn like this. 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.

marijn 12y ago

Vaguely related: CodeMirror's story http://marijnhaverbeke.nl/blog/display-updates-in-codemirror.html http://marijnhaverbeke.nl/blog/display-updates-in-codemirror...

kakuri 12y ago

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.

dlisboa 12y ago
> 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.
VeejayRampay 12y ago
How is a Core i5 2.9GHz with 16GB RAM not considered a "powerhouse"?

zkhalique 12y ago

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!

d0m 12y ago

Just chiming in. Switched from Angular to React, and saw massive improvement on any fronts. Maintainability, Speed of development, performance, etc. 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.

d0m 12y ago

nickstefan12 12y ago

It seems like they never really gave react a real chance. although react is just a view render, to really get its red line performance requires going all in. I think it would have been worth it. a unidirectional data flow is worth the pain. It's so much easier to design something that only ever has to "rerender". 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.