Rendering Improvements
blog.atom.io
blog.atom.io
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.
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.
I remember something about a 2MB (or was it 2GB?) limit at some point.
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.
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.