Rearchitect for optimization at browser-level

[inokawa]

Is your feature request related to a problem? Please describe.
We achieved optimization in this lib at sufficient level, with improving js, css and React technique.
However it seems to be difficult to be the fastest without rethinking its architecture to become suitable for optimization at browser level.
Of course it would make it difficult to maintain, so we have to choose the one which has clear benefits and acceptable cons.

Describe the solution you'd like

• DOM recycling
  • implemented in iron list, cdk-virtual-scroll-viewport, recyclerlistview (but not DOM), etc.
  • cons: maybe having problem on accessibility and state.
• Synchronous scrolling
  • implemented in Monaco Editor and (probably) older CodeMirror
  • cons: probably hard to implement smoother than native asynchronous scrolling
• or something better (need to investigate)

Describe alternatives you've considered
N/A

Additional context
N/A

[inokawa]

Closing because tricky optimization can decrease maintainability and flexibility.

[inokawa]

Consider recycling mode in #280