
“Implement text editor DOM updates manually instead of via React” - spleeder
https://github.com/atom/atom/pull/5624
======
zak_mc_kracken
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.

~~~
zghst
React is so much different from other frameworks, I feel.

Someone that doesn't know React can basically come in and start working on a
large app from Day 1. It is so much less frustrating than Angular, Backbone +
Ember + handlebars, etc. You can continue to add features to a React
application and not slow down.

Also React isn't unproven. Over 1 Billion people use a React application
everyday (Facebook + Instagram web). 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.

~~~
e1g
>Over 1 Billion people use a React application everyday (Facebook + Instagram
web) It's fun to actually see which parts of public websites are written with
react by running this in the browser console:

    
    
      setInterval(function() { Array.prototype.slice.call(document.querySelectorAll('[data-reactid]')).forEach(function(element) { element.style.background = 'rgba(255,0,0,0.1)'; }) }, 500)
    

Some pages to try it on:
[https://instagram.com/natgeo](https://instagram.com/natgeo)
[https://www.facebook.com](https://www.facebook.com)
[https://www.airbnb.com.au/go/US](https://www.airbnb.com.au/go/US)

edit: the snippet is from Pete Hunt who is on the core React team
([https://twitter.com/floydophone/status/557348616080076800](https://twitter.com/floydophone/status/557348616080076800))

~~~
PSeitz
That killed my facebook tab

~~~
runeks

        function() { Array.prototype.slice.call(document.querySelectorAll('[data-reactid]')).forEach(function(element) { element.style.background = 'rgba(255,0,0,0.1)'; }) }
    

is executed every 500 ms using command in question. So if the above function
takes 500 ms or more to execute, the tab will get stuck (I would think).

Try just executing this command once:

    
    
        Array.prototype.slice.call(document.querySelectorAll('[data-reactid]')).forEach(function(element) { element.style.background = 'rgba(255,0,0,0.1)'; })

~~~
dcherman
Instead of using a timer or a one time selector, just add a new CSS rule via a
style tag

(function() { var style = document.createElement( "style" );

    
    
       style.innerHTML = "[data-reactid] { background: rgba(255,0,0,0.1); }";
       document.head.appendChild( style );

}());

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

~~~
mlangenberg
_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.

~~~
methyl
> I am wondering if React is usable for writing a JS Widget, for example
> Disqus.

It is, I've written some quite impressive widgets and it performs really well.

~~~
mlangenberg
Do you load it into an iframe?

If not, how do you make sure you are not conflicting with an existing version
of window.React?

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

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

------
kylec
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
(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
> 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?

~~~
jordwalke
Most of the people that don't believe that immutable, persistent data
structures are effective tools to increase performance of reconciliation, only
put one foot in (that's my personal experience). That kind of reservation
often compels people to "just try immutability on a part of their tree". It
doesn't work like that and you often should go all in before you begin seeing
the benefits. It's a leap of faith, admittedly.

Almost every application (ever) is a list of lists of lists (and so on). Even
text can be broken up into paragraphs/code-blocks etc which form the lists. If
these structures form a tree, and that tree is somewhat well balanced, then
small changes can be found in log(n) time by comparing reference identity
without developer intervention (by either a mixin or Om-like system). log(n)
ends up being extremely fast for n in the range of graphical nodes in most UI
applications. For everything else, a windowing infrastructure can be used
(usually baked into a very sophisticated <ListView> component - our
ReactNative mobile applications use this approach (special <ListView>
component that exploits immutability without developer intervention)).

~~~
seanmcdirmid
Thanks for your reply!

I work in this field and have written lots of code, both mutable and
immutable, declarative, OO and functional, to solve a variety UI problems.
I've also written my own language-enabled editors using multiple techniques
(see comment
[https://news.ycombinator.com/item?id=9117234](https://news.ycombinator.com/item?id=9117234)
for the one I'm working on right now, but you can see
[https://www.youtube.com/watch?v=SAoRWmjl1i4](https://www.youtube.com/watch?v=SAoRWmjl1i4)
for an Eclipse-based one I did in 2007), so I've definitely got multiple feet
in the game.

I don't work in Web, most of my UI code was written for Swing, SWT (Eclipse),
and these days WPF in immediate mode. It seems like React is solving a bunch
of JS/DOM problems, so maybe my experience doesn't transfer, but I've found
that for my work, it is much easier to just go with mutable data structures
that support change propagation, so you make a change that affects a line in a
block (my current editor architecture, block - lines - more blocks - more
lines - etc...), the change is just...O(1) because the line can be
damaged/repaired directly! So why would I give that up for O(log(n))?

~~~
jordwalke
It's a great question. All of this (immutability) only makes sense to even
attempt if you believe that immutability is easier to reason about than
mutability. If we don't agree there, then I have nothing more to add really.
But assuming we agree, then there is the question of performance.

In most applications, we have three tiers of time durations.

Tier One: During an interaction/animation you must update the screen every
16ms. Code may not run longer than 16ms (less in practice).

Tier Two: You are not interacting, but may begin interacting with something at
some unknown time. Code may not block the UI thread for longer than about 50ms
so that there is a guarantee of not introducing _perceivable_ delays into the
interface.

Tier Three: Long running tasks which should be executed in parallel with the
UI thread/process.

If going from O(1) to O(log(n)) still allows you to meet your deadlines for
whichever latency tier you are targeting in whichever supported device classes
you want to support, then it's worth it in order to program with better
abstractions. Blocking for 1ms is as good as blocking for 13ms in Tier 1.
Blocking for 25.5 is as good as blocking for 40ms in Tier 2. (This is helped
by a decent event loop/task scheduler etc).

Again, all of this assumes you genuinely value immutability as a programming
paradigm over mutability. If you'd really rather mutate, then you should just
be using mutations/observables. I would not rather. Sometimes, I still perform
mutations for the _most_ critical parts of a UI abstraction (such as a
scroller animation etc) - but I am up front about it being a compromise of
what I'd _rather_ do.

~~~
seanmcdirmid
> All of this (immutability) only makes sense to even attempt if you believe
> that immutability is easier to reason about than mutability. If we don't
> agree there, then I have nothing more to add really.

Ok, that makes a lot of sense. I spend a lot of time trying to make mutability
easy to reason about (my research), so I agree on the problems but disagree on
solution strategies (fixing mutability with managed time vs. avoiding it).
There are plenty of differing and evolving opinions in this field (e.g. back
in the early 90s, constraints were going to save us).

I see as the main benefit of React is that there is no need for change
propagation, just do a fast diff at the end. That's interesting and could be
an overall win given the constant overhead of change propagation (O(1) with
lots of bookkeeping), but I'm not sure how that would scale in practice. One
of the reasons I moved on from declarative UIs (I did my dissertation on one
called SuperGlue) was because the paradigm is difficult to scale in
expressiveness (let alone performance) beyond simple examples; e.g. I couldn't
build interactive compilers bolted onto seamlessly onto editors for richer
programming experiences.

~~~
jordwalke
Ah, it's good to know we have an ally against a common foe and I respect that
you're taking a different approach (I suspect you'd be interested in Mezzo).
I'd really encourage you to try out React though. It's different than other
FRP type systems because the granularity of "reactivity" is much larger (at
the component level) which means the majority of your code executes on _plain_
data structures such as arrays and objects. There's no need to continuously be
lifting your data into some "reactive" data container. For example, if you
have two numbers that are changing over time, if you want to add them, you use
the + operator instead of creating some kind of "ReactivePlus" operator.

Also, in some types of apps, when you have many of these point to point
bindings wired up, the bookkeeping of them can start to add up too, especially
when everything ends up changing any time anything small changes. This hurts
two cases predominantly: 1\. Your initial rendering of the UI. You usually
have to set up these point to point bindings. It would be faster to not have
to when blocking the initial user experience (which is critical). 2\. When
small changes end up rerendering the entire page anyways. This is the worst
time to be slow because you already have so much to do! If some small
imperceivable delay becomes a medium imperceivable delay, it's not so bad. But
when the entire scene changes all the time, a framework like React that
anticipates this can cut right to the chase and do the rerendering without
also having to do the bookkeeping along the way. Different apps will have
different sweet spots in different paradigms. I will say that it's worked out
well for us at Facebook/Instagram and many other serious production apps (not
just simple examples). I'd encourage you to try it out and give us more
feedback since you've done so much research in this area.

~~~
seanmcdirmid
When I was working in a design studio, I wrote a framework called Bling that
auto lifts WPF dependency property animation/data binding for C#:

[http://bling.codeplex.com/](http://bling.codeplex.com/)

So you could write something like:

    
    
        w.Right.Bind = v.Left + k.Width 
    

and it would compile that into a continuous data binding expression (auto
lifting was also useful for defining shaders in C#, they use similar
techniques in JS/WebGL). But you are absolutely right: the book keeping was
too much, and if you had say a chart with 100x100 cells each individually
bound, your startup time would really suck. Glitch (my current work) has a
much lower cost per state read (where you install listeners), and, like React,
does not require lifted operations: so you read some state into values,
operate on some values, and store the values in some state somewhere else.
Each read is traced as it happens, each write is logged as it occurs,
everything in between is just normal code; no lifting is necessary (I think
React is like that for reads and doesn't allow for state writes outside of DOM
updates that appear immutable).

The only question now is about granularity, and that is completely tweakable.
There are some issues with state cycles, which have to be rejected (otherwise,
non-monotonic changes might not work correctly in an incremental context), and
keeping state separate helps prevent "false" cycles from occurring, but I'm
looking at ways to separate cycle detection with state update granularity, and
anyways, none of that applies to React since writes aren't handled in the
framework.

What I'm interested in is expressiveness; as a PL person I have a cliche
benchmark: can you implement a compiler in React? A compiler, after all, is
just a "view" of flat text into some other form (e.g. a typed AST that can be
used as a model in a language-aware editor). For React, I think the symbol
table would stop you (everything else in a compiler is pretty much
functional), but I might be wrong.

I'm definitely interested in React and will keep looking at it. Unfortunately,
I don't do any web work so finding a proper context is hard.

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

~~~
rtpg
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
This is why I designed Glitch:

[http://research.microsoft.com/apps/mobile/showpage.aspx?page...](http://research.microsoft.com/apps/mobile/showpage.aspx?page=/en-
us/people/smcdirm/managedtime.aspx)

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
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
Ugh...mobile link, this should work:

[http://research.microsoft.com/en-
us/people/smcdirm/managedti...](http://research.microsoft.com/en-
us/people/smcdirm/managedtime.aspx)

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

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

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

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

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

------
grandalf
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
likewise. Out of curiosity, which features are you referring to?

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

------
shurcooL
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
Can you add something more about what is the minihtml module? Google says
nothing.

~~~
shurcooL
Grep the ST3 dev channel changelog [1] for "minihtml".

[1] [http://www.sublimetext.com/3dev](http://www.sublimetext.com/3dev)

~~~
budrick
All well and good, but that doesn't explain what it is, only that it's been
worked on.

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

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

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

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

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

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

------
marijn
Vaguely related: CodeMirror's story [http://marijnhaverbeke.nl/blog/display-
updates-in-codemirror...](http://marijnhaverbeke.nl/blog/display-updates-in-
codemirror.html)

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

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

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

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

~~~
peteretep
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
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).

------
xtrumanx
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
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 :)

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

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

------
bolinfest
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/...](https://discuss.atom.io/t/whats-the-status-of-react-in-atom/11456)

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
Who changed the title of this post and why?

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

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

~~~
bostonvaulter2
Is this really worth being downvoted? It is an honest question.

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

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

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

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

------
AdrianRossouw
well, that was quick. =)

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

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

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

        <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
What would be the syntax of the declarative code in the template?

