“Implement text editor DOM updates manually instead of via React”
1–10 of 225 posts
Re: “Implement text editor DOM updates manually instead of via React”
#2That 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...
Re: “Implement text editor DOM updates manually instead of via React”
#3That 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...
Haha, it was only a matter of time (measured in weeks) until React was over. The new hotness is evidently manually setting innerHTML.
Re: “Implement text editor DOM updates manually instead of via React”
#4This 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.
Re: “Implement text editor DOM updates manually instead of via React”
#5Is there a chance that they'll get bogged down tracking exactly what HTML needs to change for each update?
Re: “Implement text editor DOM updates manually instead of via React”
#6It 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.
Re: “Implement text editor DOM updates manually instead of via React”
#7That 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 lot better how to edit the DOM after an event (like hitting a character) than React's general algorithm
Re: “Implement text editor DOM updates manually instead of via React”
#8I 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.
Re: “Implement text editor DOM updates manually instead of via React”
#9That 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...
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.
Re: “Implement text editor DOM updates manually instead of via React”
#10I 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.