“Implement text editor DOM updates manually instead of via React”

Re:“Implement text editor DOM updates manually instead of vi... by plorkyeran on Thursday February 26, 2015 @11:41PM (#9117204)

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.

[ Parent | on HN ]

Re:“Implement text editor DOM updates manually instead of vi... by jsprogrammer on Thursday February 26, 2015 @11:52PM (#9117237)

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?

[ Parent | on HN ]

Re:“Implement text editor DOM updates manually instead of vi... by xahrepap on Friday February 27, 2015 @12:20AM (#9117302)

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.

[ Parent | on HN ]

Re:“Implement text editor DOM updates manually instead of vi... by mrbtie on Friday February 27, 2015 @12:31AM (#9117334)

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.

[ Parent | on HN ]