-
Notifications
You must be signed in to change notification settings - Fork 854
[discussion] investigate vanillajs approaches #754
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
3f3ac30
to
be30c49
Compare
@noelmace Awesome work on so many variants. Any observations so far? |
Whoops, I forgot about this PR 😅 Sorry for the flooding, here is a quick summary of some of my observations so far. the "good" VanillaJS approachSo, first, the generally advocated VanillaJS approach is kind of dumb, as it leads to ~30% worse rendering performance than an optimized one, and even ~10% compared to most rendering micro-libs (e.g. lit-html).
This is mostly because:
I'm still investigating different "minimal vanillajs component" approaches (no custom element, pre-parsed or programmatic template, no advanced function, etc...) w/ some helper functions. But I'll need to work on a solution to test shadow dom to compare those with "real life" Web Components. Some other general considerations
In general
Some comments on the pre-existing examples
|
requires: - to use an autonomous custom element named benchmark-row with a shadowRoot containing one HTMLTableRowElement - to add set `useRowShadowRoot` to `true` in "js-framework-benchmark" in the integration's package.json results for partial update, swap rows & remove row seems seems wrong as they are way too low
DX first: uses innerHTML with bad event listeners. The row component is badly optimised because it can't use a shadow dom. Delete in incredibly slow because it needs to do a findByIndex for everything (but maybe it's cheating to do otherwise, as vanilla-wc do the same). Optimisations: - the main component stores the rows elements in order to avoid to access the DOM too often - the main component uses a template to minimise parsing
remove disconnect has to makes clear run slower only listen on click at the root of the row component
use append instead of appendChild to optimise DOM access
new implementation based on vanillajs-wc-dx but using createElement instead of innerHTML
41710b6
to
ba7e11b
Compare
I made a lot of changes in my fork, and this branch has been removed in favor of Please check the dedicated issue I created to discuss differences between this fork and this project: https://github.com/fullwebdev/benchmark/issues/1 |
This PR is for feedbacks and discussions only
As I'm currently using this project in order to investigate different VanillaJS practices and their impacts on rendering performance, I'm creating some new poorly optimized implementations. Those aren't intended to be merged as is, as they are out of this project's scope.
Yet, sharing those implementations with contributors to this project may help some discussions about the current ones.
Especially:
vanillajs-wc-dx
, but in another PR) thevanillajs-wc
implementation follow good practices in order to be closer to "real-life" projects, even if it means worse results.FYI: in order to allow me to follow how rendering approaches compares without creating a bunch of implementations, I commit every results, so of course, those are conflicting with the master branch.