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.
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.
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.
> 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.
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.
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.
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?
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.
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.
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...
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.
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.
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
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.
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.
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.
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.
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.
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/
Project is dead but the program is a pretty fully-fledged text editor from what I have heard.
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.