[deleted]
“Implement text editor DOM updates manually instead of via React”
11–20 of 225 posts
Re: “Implement text editor DOM updates manually instead of via React”
#12That 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...
He's missing the point of Declarative vs Imperative and Virtual DOM vs Data Binding if he thinks it will circle back to jQuery.
Re: “Implement text editor DOM updates manually instead of via React”
#13That 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...
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…
This is why I designed Glitch:
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.
Re: “Implement text editor DOM updates manually instead of via React”
#14I 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.
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.
Re: “Implement text editor DOM updates manually instead of via React”
#15It 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 fu…
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?
Re: “Implement text editor DOM updates manually instead of via React”
#16I 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.
Re: “Implement text editor DOM updates manually instead of via React”
#17[deleted]
When React Native gets released you'll definitely see the hype train start up again.
Re: “Implement text editor DOM updates manually instead of via React”
#18I 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 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 ;)
Re: “Implement text editor DOM updates manually instead of via React”
#19I 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.
Re: “Implement text editor DOM updates manually instead of via React”
#20[deleted]
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.