41–50 of 225 posts
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...
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…
>> 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.
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 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
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…
(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 stu…
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?
Earlier quoted context omitted.
"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.
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 ca…
Earlier quoted context omitted.
(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 stu…
> 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…
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 anno…
"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.
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.
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 anno…
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.
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.