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.
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.
>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:
Fake test. React Components don't always return a DOM element, also not every element shows up all the time, instead you should download the React dev tools.
There are at least 30-40 top level components on Facebook. Nice try though.
You are of course correct that some React components will not be caught by this single-line test. It is impossible to truly know unless you are the author of the app, and that's the case even with React tools (e.g. you would not be able to identify my server-rendered components that are not mounted on the front-end).
The intent was not to provide a debugging tool - it's just to provide people with limited exposure to React a simple one-liner to help them understand what is meant when someone says Facebook/Instagram use React, and see some components in the wild. To that goal, using a simple test for data-reactid attribute will catch the overwhelming majority of in-the-wild use cases.
I had the opposite impression when looking at the React docs. JSX was intimidating and getting the quick examples to work resulted in several errors. JSX is of course optional, but the way that Angular just worked, without any non sense of installing anything, is what really drew me into the framework.
Thing is with React though, is that whilst it's initially a bit weird, once you get the hang of component lifecycle, there's very little conceptually left to learn, whereas with angular it just keeps getting more complicated.
JSX is simple, it is just simplified HTML. I think you may want to give it another try, sharpen your skills with it. It is not difficult to work with if you try.
And on installing things, it is basically what any developer does these days. We install tools for almost anything. Just think of the JSX tools as another tool in your belt to help with the translation. The paradigm shift opens up your palette to new technologies. For instance, you can go from using just JSX to using ES6 with JSX (babeljs) as well, with no added cost, all because you already have your build process set up.
I will say though that when it comes to abstracting elements, this behavior seems to be implicit across the board (angular directive templates require the same, though they include a somewhat-informative error state).
As someone who has only begun to feel out React/JSX after developing some large, semi-complex enterprise UI's in Angular (with the respective back-end, usually an abstracted REST API) I'm finding the React model to be a lot more intuitive and scalable.
Angular is fantastic until you run up against problems with complex tasks that either must run outside of the digest loop or require manual control of painting/rendering to compensate for the abysmal binding performance.
I agree - I find React has a higher initial overhead than Angular. Frontend web development is complex, so in the long run, the complexities will still show if you make a misstep.
That said, I'm happy with my time so far with React. I haven't gone into nitty gritty engineering with it yet due to not having the time to start really coding on my project with it, but it has been fairly simple relatively speaking.
I'm excited for Angular 2 though - the amount of planning going into it is excellent, and I believe it will also turn heads with its simplicity & performance.
Frontend web development is seeing some exciting changes that should ultimately make our development ecosystem much better to work with.
Intimidating was probably a poor choice of words. I guess odd would be better? Idk. It was just a deterrent for me. I can get over the syntax but the installation errors coupled with it being weird was just enough to make me drop the tutorial I was working on.
I do hope to start working with React again. It took me a few times to really get into angular so I'm sure once a guide comes out that really gets the details right I'll be fine. Something like this[1] for React would be amazing.
"and text editors have an insanely high bar to clear in terms of performance and responsiveness"
For some reason that sentence really bothers me. Not because our standards are so high for text editors. But because they're so low for damn near everything else.
My first text editor was usable on a machine 300,000 times slower with a million times less RAM. It bothers me that text editor performance is ever considered challenging at all.
For this sort of thing, with a fixed amount of developer time:
- Performance
- Stability
- Actually working
you can pick 2. Also, if you pick performace, 50% of the time you can only pick 1.
Everything is a tradeoff but it's a lot easier to sell something slow than to sell something that doesn't work, and a lot of the performance costs are due to general techniques encoded in these frameworks that reduce bugs.
Another thing is that things do get faster. I think V8 has gotten 10x faster (at least) on real code since its inception. And that's despite JS not having changed.
Cloud9 manages to pull off all 3, and in javascript to boot. I honestly don't notice any difference in performance between it and ST3 (other than initial loading, which is a given seeing as it's web based).
Vim itself is fine, but the plethora of plugins that a lot of people install can drag it down. Firefox has the same problem with extensions. And it's really not the fault of the base package. It's the plugin developers not doing due diligence, and it's the shear number of plugins making it impossible to test all combinations.
I'm not sure why you would open a log file with vim, but that's besides the issue. The issue is with 500 line files. Open one up in Sublime and one in Vim. If you only use Vim you'll never discover what it to means to have a performant editor (I've used Vim for ~10yrs and still regularly do).
I have no idea what you are talking about. I opened a 26,000 line file (no I don't want to talk about it). In vim it opened instantly and my scrolling was only limited by my key repeat rate. The scrolling isn't as smooth looking because vim doesn't animate the scrolling between lines. Sublime took 2 seconds to open the same file, and scrolling was smooth.
Maybe you are using to many vim plugins? I'll admit vim plugins are a real problem, the gui rendering desperately needs to be moved to its own thread.
I think there may be a possibility of the terminal itself being slow. Years ago when I used semi transparent terminals in something like enlightenment it was seriously noticeable when you were trying to scroll through text and it'd take a while to appear. Then I switched to using a simple terminal like rxvt and no transparency effects under ion2 and wow was it fast.
So, perhaps the answer is that it's not the editor nor plugins that's slow in the scenario. I think the line numbering even causes some slight slowdown. Anything that actually parses text will obviously cause a performance hit too. I notice slowdowns when I use visual selection modes combined with tricky combos of commands. Even without any of that, it might be possible that the version of vim is doing something stupid like what happens when you open up a 1GB log file in less and hit G. Haven't run an strafe to understand the fseek calls being made but that's been painful without exception in my experience. Perhaps that's what the poster was recalling.
You're right. Editing a large file with syntax coloring and vim slows to a crawl. I just can't get away from Vim though as it works so well in terminals.
This is mostly to do with the syntax matching, the regexes used for that, and thus ultimately also the implementation of the regex engine (which was more or less swapped in Vim 7.4). It bother me a bit too (but not too much). Perhaps it can be mended, we'll see :).
I love ST; I happily bought a v2 license a while ago, and will buy v3 when it's an option. I just get nervous about the resources being allocated to its development, so I've run Atom almost exclusively for a few months as a hedge.
It's worth noting that if you haven't checked in recently, ST3 development appears to be back on track and proceeding at a pretty good clip. (Having said that, I'm keeping my eye on Atom myself. My big concern with ST3 is that the combination of closed source and single developer gives it a bus factor of 1. I'm hoping Jon follows through on his vague plan to get another developer in this year.)
That is definitely not one those "pick two" situations. The relationship between those 3 things is quite different, in fact having one normally implies a better than average chance of having the others.
You can not release a feature until it is performant, stable and working. You just won't release a lot of features. If you have the testing and release procedures that keep things stable and working - testing for performance regressions is easier, not harder.
The classic "pick 2" situations is time, cost, features. Picking any one of those makes the other two harder to do, not easier.
It might have something to do with the demographics. Text editor users are developers, power users, or at the very least, very tech savvy (there is also the other extreme of the spectrum, people who know nothing better, but you get my point). With that demographics, we (at least I know I do) tend to be more picky.
The majority of people are content with coffee-making-loading-time for their OS, and the slug that is called Microsoft Word or Adobe Reader.
I'm not a fan, but Microsoft Word 2013 is massively more performant than Atom, at any basic task that both programs do (launching, opening files, find/replace, etc).
> 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.
React is something which stands astride on a line that divides a framework and library. I believe, like all good libraries out there, which do one thing and one thing well, React might stay for a longer period of time. At the first look of it, it might look heavy and bloated but it professes a far simpler view of building UIs.
The best part is, just like jQuery, it didn't take me more than a few hours to get comfortable with React and incorporate it into building something, something that could have taken a few weeks with other frameworks. I am not saying there won't be anything better than this but I am sure it isn't just another hyped fad.
> I enjoy seeing the latest fad being burned at the stake as much as the next guy
You're talking about a project developed in Coffeescript.
> I think their technical choice of going for Javascript will be their ultimate downfall,
This is debatable. Editors like cloud9 have acceptable performances and webtechs allow one to distribute software right in the browser,which fits a huge number of use cases.
> Atom is a text editor, and text editors have an insanely high bar to clear in terms of performance and responsiveness.
This "insanely high bar" has been easily cleared by text editors running on humble home computers for 30+ years. I'm not sure it qualifies as being insanely high.
I think the point is not necessarily that "text editors intrinsically require gigabytes of RAM and gigahertz CPUs", but that they have "insane" latency requirements.
On the one hand, yes, our computers ought to be able to handle text editing. On the other hand, as long as you meet the latency requirements one way or another it doesn't much matter whether you barely met them or utterly blew them out of the water by four orders of magnitude... instant is instant, to a human.
A browser is a tough place to build a text editor. You're running a huge, complicated, sophisticated text rendering and typesetting environment, which you're using only a vanishing fraction of but the browser doesn't know that and can't much optimize for it. (Some, sure, I'm sure it's got special routines for monospaced text, but it still can't know you won't just stick a picture in the middle of it a moment from now.) You're running on top of a fairly slow language, even after all the optimization work on it [1]. You're running in an environment that is deeply structured to be synchronous so if you accidentally write a for loop over anything that turns out to be larger than you expected, you've frozen your environment until you're done, to say nothing of accidentally handing the browser a big rendering job ("did you just open a directory with 20,000 files? here, let me render that for you..."). Any of these things individually might be overcome, but the combination is quite challenging. It's nifty that the browser lets you run "anywhere" but it is also in a lot of ways a crazy place to try to build a programmer-quality text editor.
[1]: I have to justify this every time I say it since somehow the idea that "Javascript is fast!" has sunk into the community, but it's not true. The easiest proof is asm.js... if Javascript was already "C-fast" or even close, it would not even exist. It exists precisely because Javascript is not a fast language. Javascript is much faster than it started out as, but it started out as an extraordinarily slow afterthought meant to run a statement or 4 in response to a mouse click. It has still stabilized on "much slower than C" and appears to have essentially plateaued. The result of speeding up something miserably slow by quite a bit can still result in something slow in the end.
> I think the point is not necessarily that "text editors intrinsically require gigabytes of RAM and gigahertz CPUs", but that they have "insane" latency requirements.
What about the latency requirements is insane, then? I can't think of what "insane" could possibly mean in this context other than technically challenging or infeasible.
> A browser is a tough place to build a text editor.
I agree. To some extent I'd call that in itself an "insane requirement". The merge request proves, however, that you can attain reasonable performance by avoiding additional abstractions on top of the already very abstracted platform. Looking at the call graphs, Javascript itself or even the DOM obviously were far from being the bottlenecks.
"I can't think of what "insane" could possibly mean in this context other than technically challenging or infeasible."
Apparently, responding to keystrokes by putting a character on the screen in less than a couple hundred milliseconds is still technically challenging, or at least, doing everything we want to do within that time frame is still technically challenging for a high-powered editor. Which is less silly if you think about it. A single keystroke in "notepad" is one thing, a single keystroke in a programmer editor is quite another.
"Looking at the call graphs, Javascript itself or even the DOM obviously were far from being the bottlenecks."
If Javascript really was a fast language on par with C++ or something, that amount of abstraction would not have been a problem. The fact that Javascript is slow really is a problem. It is not necessarily the problem, because many other things are contributing, but it is a very significant part of the problem.
You can bring a Java or C++ program with its knees with too much abstraction too, but it takes a lot, lot more work than that. (Many have managed to leap this bar and more, though!)
It's one of the reasons I'm really trying to get the 1990s-style dynamic scripting languages out of my professional life. It really isn't that hard to reach a point where you simply can not have both of "a good design" and "sufficient response time" because you literally want to do more work than the language can get done on one core in 100ms unless you essentially manually inline everything, but that's not practical for its own reasons.
In fact, on that note, note that this is it for Atom. This is the fastest they can go with this layer. Should they end up pushing the editor a bit farther and should they end up needing a bit more performance to do something else properly, they won't be able too, because they just tapped out this well.
Does it really need to happen on one core? The platform supports webworkers and serializing certain events across channels wouldn't take much... if you look at, for example some of the cross channel rendering with react that has been experimented with, there's merit there.
For this use case, I suspect you wouldn't be able to win much with WebWorkers. You'd have to profile, but having done a lot of profiling with multithreading in several environments I've learned to expect disappointment relative to my initial lofty hopes. It feels like it ought to be easy to get linear speedups and that it ought to take something really unusual and special to slow it down; in practice you're lucky to even get "good" speedups.
Games in js have had similar requirements, or even tougher. expectation out of a game has been increasing for a long while, and there are games being built on js (even full fledge games using asm.js and webgl),
So i dint think the requirement for latency is as insane, you just need good dicipline, which game develers have had for decades
An asm.js game using WebGL drops the slow language problem and drops the vast bulk of the browser layout problems, leaving only the problem that you're still sorta stuck on synchronousness, but games have dealt with that for years. The fact that you reached for those details to justify your point is further evidence of my point, not denial of it.
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.
Why not? The browser is something like a mechanism for delivering text, images, layouts, and interactive scripts. It's highly cross-platform. Quite perfect for many uses, and the popularity of web apps is almost evidence in itself.
CSS is a bit annoying, but with evergreen browsers and flexbox it's getting very good—and even as annoying as it is, it's still mostly easier to work with than most GUI toolkits.
I often think of the browser as something like an X11 server. It doesn't matter how old you are; why don't you think it makes sense?
> Quite perfect for many uses, and the popularity of web apps is almost evidence in itself.
Mobile and micro-services will change that.
> why don't you think it makes sense?
Because I went through the evolution of using text based GUIs, Amiga, Atari and PC GUI toolkits, drawing UIs with the likes of Visual Basic, Turbo Pascal, Delphi and C++ Builder. To the modern ones of XAML, Cocoa, QML and so on.
The list is just a bit long to post here. Most of them provided a saner developer experience than HTML/CSS/JavaScript will ever do. Unless we throw DOM away and replace it by something more tailored to applications instead of rendering documents.
Even if the DOM gets replaced, the browser can hardly provide an integrated experience in terms of what any native desktop/mobile environment offers to its users in terms of immersion and interactivity between applications.
It is just no different than using Java with AWT 1.0 in the early years without native widgets and integration to the respective desktop APIs.
Hmm, interesting. I've used a few GUI toolkits, written bindings for GTK+, worked with Java and Swing, etc. Modern web development, especially using React, is in many ways the sanest thing I've come across.
It reminds me of stuff like Emacs, Lisp systems, Smalltalk, etc. Inspectable environments using dynamic languages... But React's model for components and DOM elements seems to me in many ways easier and better than Emacs buffers or Smalltalk widgets.
I use browser developer tools a lot for changing scripts and styles interactively, and while it's nowhere near perfect, it's often extremely useful and convenient, and I think the model has lots of potential.
> It reminds me of stuff like Emacs, Lisp systems, Smalltalk, etc. Inspectable environments using dynamic languages
In a way yes, but only if we can get rid of DOM and have 1:1 parity with desktop APIs.
One ends up piling div elements with CSS and JavaScript, to imitate something that looks like native widgets, but don't behave like them nor can interact with the desktop environment.
I find Qt5's QML to be a million times easier to use, read, debug, maintain. And that is because it is designed as a markup for applications. HTML was never designed for that. Neither was CSS. This is the reason for all this incredibly inefficient HTML webapp madness.
The DOM's main advantage is supposed to be accessibility and portability to different form factors; otherwise, just roll your own UI using Canvas (like I do using WPF canvas anyways for my editor work). It's not clear to me how accessibility could be preserved while allowing for more flexibility.
Mobile and micro-services will change what? Even then microservices are an architectural pattern, it's not inherently tied to a platform, whether it runs native or in the browser.
Many native application on the mobile space are using micro services with a native UI, as a means to provide an integrated user experience with the respective platform features and keeping the business logic portable.
Without having installers that include adware (Java) or that seem borderline-unsupported (X11/Quartz) or that require funny multi-stage compiling (Qt).
> or that seem borderline-unsupported (X11/Quartz)
Since when is Quartz unsupported?
> or that require funny multi-stage compiling (Qt).
Since when do users compile GUI frameworks?
Cross platform UI is nothing new, there are much more options to choose from than those you listed, and browsers can hardly offer more than a 90's GUI experience.
I don't like that it's this way, but the web is a (mostly) open standard for GUIs that is supported virtually everywhere that has a GUI at all.
Cocoa and .NET produce good interfaces but are proprietary and only work on one platform. GTK+ is Free and "works" on all desktop platforms, but anyone who's used a GTK app on mac can tell you how awful it is (and it's really the only place that it's great is on GNOME-based linux DEs).
Qt is Free, and it has fairly good support on all platforms (even mobile), but making the interfaces look and work great on all platforms requires the developers to put a lot of work into custom UI elements (see how Qt programs look on GNOME or OS X when they use the default UI elements). It also requires developers to use C++, offensive to programmers who prefer hosted languages (although arguably better for those planning to port to mobile). But the C++ it uses is so far removed from non-qt C++, even requiring compiler plugins, that many C++ developers have qualms with the language it uses.
The web is programmer-friendly, cross-platform and Free. Writing a desktop app using web tech means it's relatively easy to port it to ChromeOS (or FirefoxOS if that becomes popular ever) or an in-browser app. It has the lowest performance of any of the mentioned technologies, which is only relevant for especially performance-sensitive apps (text editors) and mobile.
Really Qt wins out on technological merit, but web is comes in a close second, and there's actually a large supply of developers who know what they're doing with web.
With Qt5, you write your interfaces (and optionally can even write all or most of your app) in QML. I tried it out, and it is such a breath of fresh air, compared to HTML/CSS. You can achieve the exact same thing with a small fraction of the resource consumption.
Most native applications use a language runtime and most GUI ones use a general-purpose declarative layout engine. Put those together and you basically have a browser.
Except their GUI (if well made) is much better at interop, handles tons of shortcuts that are forgotten in webapps, and native apps don't have to bother with crazy amount of limits browsers have "because security". Like Chrome not letting you bind to half of the Emacs shortcuts because some evil actor could use them on a webpage to phish you.
It's the closest thing we have to a general purpose, cross platform application engine that pretty much runs anywhere with a GUI interface (for anything updated in the past 3-5 years).
Browsers are more easily available on every major, and most minor platforms than any GUI toolkit out there... Things like atom, brackets and similar make sense. They translate well between standalone app in an OS, or a platform app for the likes of ChromeOS, or as a SaaS app in a browser.
No, they aren't the fastest, lightest or best performing. They don't even have the smallest codebases... what they are is broadly available, with minimal variance and a lot of developers with most of the knowledge needed to maintain them.
Using CSS magic tricks and JavaScript to make an unordered list appear like a menu or a toolbar just feels wrong, just as one example from many.
I liked the way XHTML was going to remove the semantic and pave way for proper components, sadly it never happened that way.
Anyone experienced with XAML and similar layout engines can see how much better the browsers could be, if people wouldn't insist into binding a document model into an application engine.
Even with HTML 5, which still is a problem to support properly across multiple devices without a "debug everywhere" attitude, has less widgets support than a 90's GUI.
Completely agree. The fundamental problem is that HTML and CSS are the wrong tools for webapps. They are designed for documents. This is why all these CSS rules are so hard to use for applications. It is built on the model of a document, not a user interface.
The situation is immensely worse on machines like the Raspberry Pi or the BeagleBoard. People have drunk the HTML5 kool-aid and now want to run HTML5 on such machines. When you see how these boards choke when running stuff like an asteroids clone in Firefox or Chrome, you weep. Write the same thing in C++, or in something like XAML/XUL/QML/Enlightenment Edje, and it is super smooth.
My favourite would be something like QML, but with Lua instead of Javascript (but a Lua variant where the array indices start with 0, not with 1). Lua is much easier to accelerate properly, as LuaJIT has shown.
So use a component adapter, like polymer... That said, I wouldn't mind something closer to XAML or Flash/Flex that was an open specification, with a cleaner language implementation (though, I like JS)...
The trouble is actually getting a cross-platform rendering engine working everywhere that HTML/HTTP already works... So, you go build it, get it working at LEAST on Windows, OSX, Linux, Android and iOS... then we'll see how adoption goes. More likely you'll see React* bindings take off with generators to whatever platform is targetted, with JS as the language in use.
I don't want to spend money on the side projects I'm just playing with, but it would be nice to have them cross-platform (including mobile). Do any of those options still apply? IIRC Xamarin is expensive and there's no free way to run Java on iOS? All the SDL-based GUIs I've seen have looked awful.
Qt would be lovely - what does using it from Android Java look like? I remember messing with the Qt Java bindings a while ago and finding them a bit ropey.
So much this. The DOM is absolutely going to be the bottleneck more than JavaScript. I can't really provide any concrete benchmarks to support this because its a very complex topic, and you can really only come to that conclusion after trying to optimize the DOM for something as critical as a text editor.
It can be strategic even if limited to quick edits and for some subsets of the repository now. Anyway I can think of a GitHub augmented with an IDE and integrated with a CI and CD system with deployment to a Heroku. It could let you write code from pretty everywhere, occasionally even on a tablet or a large phone. Somebody will use it.
GitHub has been slowly tricking me into doing more and more of those quick edits on their site. If they can work Atom in as seamlessly as their other updates I'm sold. Somehow I'm still circumspect.
I use web-mode to edit JSX. It's not bad at all actually - the indentation and highlighting are there. I've started using web-mode for its intended purpose, too (when editing templates that have CSS and JS snippets).
As someone who never really jumped into code until very recently, I find Atom far and away the most accessible text editor. Familiar interface (to a browser) and not overwhelming to set up. I've tried emacs, vim, and sublime. I'm sure that I could come to love emacs or vim, but it just seemed like too much messing with it before I would really enjoy it. Sublime is better, but I just prefer Atom. Guess that makes me some kind of radical minority here :)
Actually Sublime was the first one I tried. And I liked it quite a bit more than vim or emacs, perhaps due to being a noob. But I still preferred Atom to Sublime.
> 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.
I totally agree. A language or technology that doesn't change is dead. The JS world can get a crazy sometimes but we need to understand WHY certain frameworks/patterns may be better and when to apply them.
Kudos to the Atom team on making their product better.
The problem with React is that it doesn't improve the computational complexity of the problem. In fact, it makes the situation worse, since every little update is now O(n).
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.