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
-
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
I specifically (and selfishly) enjoyed "A unix philosophy for web components" which takes some of the ideas from my work on Stellar and "Bring your own base class" blog post and pushes it further to create an abstract utility for binding data to the DOM
Really great stuff. Give it a read!
A unix philosophy for web development
Maybe all web components need to be a light-weight framework is the right set of helper functions.
(plainvanillaweb.com)
-
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):