Wow! Just now realizing @joeri_s (who made the Plain Vanilla website) has been dropping some amazing blog posts on vanilla web dev and #WebComponents since he shared the site in July
-
Hawk Ticehurstreplied to Hawk Ticehurst last edited by
@joeri_s also worth checking out are:
- Sweet suspense (https://plainvanillaweb.com/blog/articles/2024-09-09-sweet-suspense/)
- Poor man's signals (https://plainvanillaweb.com/blog/articles/2024-08-30-poor-mans-signals/)
- How fast are web components (https://plainvanillaweb.com/blog/articles/2024-09-06-how-fast-are-web-components/)p.s. @slightlyoff @justinfagnani would actually love your takes on that last post, was kind of surprised by the results
-
Hawk Ticehurstreplied to Hawk Ticehurst last edited by
p.s. @joeri_s not sure how much (if at all) of Stellar you checked out, but using #HTML #WebComponents and a technique that I've come to call "HTML-based state" you can get even closer to the conciseness of the Svelte `<Adder>` example
stellar/docs/reactivity.md at main · hawkticehurst/stellar
A stellar way to build reactive custom elements. Contribute to hawkticehurst/stellar development by creating an account on GitHub.
GitHub (github.com)
-
Joeri Sebrechtsreplied to Hawk Ticehurst last edited by
@hawkticehurst I hadn’t seen that yet but I will definitely be taking a look. The more I learn about vanilla web dev the more I write about it, and the more I write the more people send me stuff I get to learn from. It feels like being a web developer in the mid 2000’s again, like being on the frontier of something really interesting happening.
-
Hawk Ticehurstreplied to Joeri Sebrechts last edited by
@joeri_s agreed! writing to learn to write to learn ... (ad infinitum) has been one of my favorite surprising results of starting to blog more in the last few years
-
@hawkticehurst @joeri_s I need to open the tin on the benchmark code, by I strongly suspect that this isn't apples-to-apples, as there's likely Shadow DOM creation in the WC tests which is like creating another element.
-
@hawkticehurst @joeri_s Ok, looking at this code it's pretty clear that this isn't apples-to-apples; there's a doubling-up of the element count for the WC versions, but not for the reasons I expected.
I don't understand why there are extra `<span>` elements in the WC case; if you just want to set text content...set text content?
-
@slightlyoff ahhh nice those screenshots are helpful. @joeri_s would love to see what an updated apple-to-apples comparison looks like in that case
-
@hawkticehurst @joeri_s I can hack that up quickly if you'll take PRs.
-
Joeri Sebrechtsreplied to Alex Russell last edited by
@slightlyoff @hawkticehurst Actually, I was trying to give each component to same amount of work to do, by having both React and WC sides render a span. From a developer's perspective I feel that is the fairest comparison, although I can see why from a browser maker's perspective it wouldn't be. I'll update the benchmark to test the case where the WC is just setting textContent, but I have doubts it will change things (1/2)
-
Joeri Sebrechtsreplied to Joeri Sebrechts last edited by
@slightlyoff @hawkticehurst From working on the benchmark I noticed that document.createElement on the WC side is the costly operation, because of the element upgrade. On the React side React.createElement building the virtual DOM is a much cheaper operation, the costly part is diffing the virtual DOM to the real DOM. That's why I suspect React will still be faster even when the WC is just setting textContent. But I'll make the change, test it, and do a follow-up post to report back. (2/2)
-
Alex Russellreplied to Joeri Sebrechts last edited by
@joeri_s @hawkticehurst I think this is not right. There's no true bench harness here, and tracing the runs I see a huge amount of variability that's mostly about element count (again, these were not apples-to-apples) and GC stalls. Did you looks at a real benchmark harness that does warmups and geomean and all the rest?
-
Joeri Sebrechtsreplied to Alex Russell last edited by
@slightlyoff @hawkticehurst I've been reworking the benchmark this morning to be more apples to apples and get rid of variability, but I am indeed noticing that to do that I need a better harness and script the browser from the outside. Do you have suggestions for something I can base it on? I'm willing to do the leg work to set things up properly.
-
Alex Russellreplied to Joeri Sebrechts last edited by
@joeri_s @hawkticehurst Looking at this more, the measurement side is also not right. What I see is use of a single rAF to capture elapsed time, but that's not the real end-to-end time; to get that you need double-rAF. Single rAF only calls you back before the end of the current work posts to layout/paint, but React in particular is deferring some work to it's own rAF handler. You need to capture all of it.
-
@joeri_s @hawkticehurst Ok, so single-rAF is getting you most of the test time in the React version, but not the experienced end-to-end because the log text is *also* running through the same React instance, which means the real end-to-end time for updating the UI to report the element creation time is nearly double (because React is slow and this is unkeyed):