search

localvoid / uibench

UI Benchmark
183 stars 20 forks source link

Implementations of web-components based libraries #16

Open eavichay opened 6 years ago

eavichay commented 6 years ago

If needed, I would like to add benchmarks for Polymer vs. Slim.js If you open a scaffold repos I am willing to contribute implementation for those.

localvoid commented 6 years ago

When I've created this benchmark I've made a mistake by forcing everyone to use basic HTML elements (div/ul/li) without any additional nodes in the DOM tree (I just assumed that UI libraries aren't polluting DOM tree). And I don't want make global changes and force everyone to modify their uibench implementations (there also closed implementations for internal purposes).

There are several basic tests that checks for correctness and they assume that DOM tree has a basic structure, but with web-components it will be impossible to preserve this basic structure because I am trying to force everyone to wrap each node into a stateful component to make sure that this benchmark covers more code paths.

Another problem is that if I remove all this basic tests and allow everyone to use their own elements(web-components) there will be a problem with (full render time) measurements because of the differences in the stylesheets. div/ul/li are using default browser styles in this benchmark.

When I've experimented with web components I've found that they has a significantly higher overhead than a basic javascript objects that are used in modern UI libraries, especially when nowadays many developers prefers to use composition and wraps components into multiple layers of other components that adds different behavior.

eavichay commented 6 years ago

This doesn't mean necessary breaking the DOM tree. As this is a test for libraries, I could add polymer's <dom-repeat> or slim.js' s:repeat and keep the table structure. The only change would be in the wrapper of the display tree. Shadow DOM can be turned off so I see no reason why the tests shouldn't work.

localvoid commented 6 years ago

I am not sure, but I think that there is no good way for Polymer's <dom-repeat> to work like fn(state) => view. This benchmark just passes different state to this callback and implementation should update DOM tree according to this state (it simulates one of the most common use cases when server sents data snapshots and doesn't need to track client-side state on the server to generate changesets). From the Polymer documentation it seems that it only works by observing changes, but there is no information how data has been changed, and it probably won't be able to handle such use cases efficiently.