Tiled rendering is a bog-standard approach for GPU-accelerated Web browser compositing since Mobile Safari came out in 2007. I'm surprised their version of Chromium wasn't doing it already (and I know at least some Chromium configurations can, for example on mobile). Seems odd that they'd have to do it themselves.
In fact, it's odd that they'd have to use translate3d at all. Just changing the scroll offset on a native scrolling root should cause the compositor's tiled rendering infrastructure to automatically do the right thing.
i think that part of the issue is that these problems are so far down the optimization stack at this point, that they are seen as late optimizations.
development should start simple, and problems should be solved as they become apparent. to do otherwise would be counter-productive.
imagine how complex development of a text editor would be if we assumed that we had such major constraints? at this point, it is good to revisit some of those optimization, as we strive for small improvements, but to entertain going all the way to bare metal is just ludicrous.
while i am grateful for the knowledge from such resource-driven development (i did that too, writing video games for 286/386 and 68040 we were quite restraint-driven), i am happy that we can think of these sorts of optimizations as further down the pipeline optimizations, and don't need to consider them day to day.
They did raise or remove the limit I believe, though long lines, particularly minified files, do still pose a problem and force me to kill Atom.
Edit: Confirmed that the 2mb limit was removed. While viewable and editable, depending on the operation you attempt you may see issues.
I tried copy/pasting the contents of a 3mb json file several times and eventually it caused exceptions to be thrown (but no crash). Same test worked in Sublime Text, albeit with freezing. They do still have some work to do on the edge cases but it's been nice to see progress.
Atom uses react. It has a virtual dom that changes (instead of the actual dom) which itself can set off its own events and start more changes).
When the changes to the virtual dom are complete it will compare the dom as it is to the virtual dom, find the differences and
apply only the differences to the actual dom.
It's super fast since the virtual dom only has to support what it needs, as opposed to the actual dom with around 2 decades of outdated functions and properties.
In fact, it's odd that they'd have to use translate3d at all. Just changing the scroll offset on a native scrolling root should cause the compositor's tiled rendering infrastructure to automatically do the right thing.