4 ms·
> No one in their right mind would even think about writing and using WebComponents in vanilla JS. Why not? I have written a complete widget toolkit [1] this w
by jarek-foksa 9y ago
> No one in their right mind would even think about writing and using WebComponents in vanilla JS.
Why not? I have written a complete widget toolkit [1] this way. With vanilla APIs the code is a bit more verbose and repetitive, but in turn you get more options for speed optimization and fine-tuning.
[1] https://github.com/jarek-foksa/xel https://github.com/jarek-foksa/xel
- mlsarecmg 9y agoYou get a small set of APIs that allow you to encapsulate, so what, encapsulation never was the problem. Now how do you bind, how does the UI react to store changes, how do you bring state managers into this, etc. We'd be in 2010 fighting the naked dom all over again. As for optimization, vanilla won't be faster than a framework unless you write one from scratch. That means having a scheduler in place that orders dom read/writes, pooled events listening from a single source (the main document), a prioritizer that can cull, something that diffs state in order to render the minimal set of components, etc. Many don't realize the effort that goes into these libs to render as efficient as possible. Even if some stuff is baked into the browser, the field is moving so fast that we get higher benefits from community driven optimizations. And that is an understatement if you look at things like React Fiber.
- dmitriid 9y ago> With vanilla APIs the code is a bit more verbose and repetitive Exactly. Just the code for syncing attributes and properties is enough to never ever use vanilla JS for WCs