@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.
Posts
-
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@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)
-
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@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)
-
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@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.
-
Writing a post on how frontend technology choice-making is extremely broken in 2024, even by on the Lemon Vendors [1] own terms, and I ran across the perfect word to describe how the React ecosystem is trapped in a legacy cage of its own continual re-m...@slightlyoff Another part of the problem is the lack of learning resources. There’s a gazillion books and videos on building a complex frontend with react, but for vanilla web dev there’s very little guidance past the building of simple pages. That’s part of the reason why I made my plain vanilla site.
-
Writing a post on how frontend technology choice-making is extremely broken in 2024, even by on the Lemon Vendors [1] own terms, and I ran across the perfect word to describe how the React ecosystem is trapped in a legacy cage of its own continual re-m...@slightlyoff I think React and to a lesser degree Angular are basically the IBM of frontend. They’re not the best choice for most projects, but nobody will blame that choice when projects go south. It is a brave team that goes for a vanilla web setup.