51–60 of 248 posts
Earlier quoted context omitted.
what about slots?
Slots require shadow DOM which means there can be performance and CSS issues on widgets designed for local use with shared CSS. But I agree they’re also an option. :)
Is Web Components flawless, hardly. While the APIs are accepted standards and implemented in most browsers there are still a few holdouts, and to be sure there are still edges to iron out. No technology is without it warts, its awkward teen years. But Web Components is maturing and the tooling around it is maturing as well and Web Components most definitely has a place and is most definitely here to stay.
Also it is worth keeping in mind that the Web Component APIs are specifically written as low level APIs and intend to be built upon by libraries and frameworks to simplify and aid the process. Libraries like the one I am currently pitching, ZephJS [1], which aims at making writing and distributing web components mind numbingly simple to do. ZephJS is a perfect example of the new generation of Web Component libraries to facilitate answering the need I espouse above: the middle ground between basic and beast that so many web developers live in.
[1] Introducing ZephJS: https://gist.github.com/arei/8083a6270e704b830c68a2020f3e5e3...
I'm all for something that's native to the browser.
Right now you write a `
` tag for a paragraph element. No question about it. Imagine if you needed to use a P-tag library just to render a paragraph tag? Of course not right, you would just use the native browser `
` tag. I think that React is a P-tag library in essence.
I would go all-in for a native version of "frontend framework".
Earlier quoted context omitted.
> Web Components don’t offer a declarative way of updating the DOM; What does that mean? The methods provided by the web components spec appear declarative as do the methods provided by the DOM spec. Declarative example with nothing like innerHTML: https://developer.mozilla.org/en-US/docs/Web/API/Element/att... Either way this discussion is stupid as updating the DOM is stupid simple even without a framework. The DOM…
> * stupid - https://github.com/prettydiff/wisdom/blob/master/Delusional_... It seems you wrote this article; have you read it back? You bury the lede under 1230 words explaining some social concepts rather than anything programming-related. Additionally, you use many complex words to describe simple subjects. And you do this knowingly: for example, you felt the need to link the definition of "acquiescence" to the wo…
Web Components don’t offer a declarative way of updating the DOM; it’s still `innerHTML` and using DOM APIs to edit the state of the live DOM. Backbone was a hassle to manage in any sizeable app because updating the view was left up to every dev to figure out themselves. React brought a declarative wrapper around the statefulness of the DOM, and that is the killer feature that Web Components does not offer at all. Vu…
Earlier quoted context omitted.
Slots require shadow DOM which means there can be performance and CSS issues on widgets designed for local use with shared CSS. But I agree they’re also an option. :)
:part and :theme CSS puesdo-selectors will help address these issues
Also, css variables can be global and still enter into the shadow-dom unobtrusively (This is without using the polyfills, though, I believe this is a limitation in the polyfills currently, which might be why that part of it has been confusing in the past.).
Ploymer was a crapshow and HTML import a nightmare for load times. Unless some sort of topology bundling is provided for web components I'm out. We tried to do generic components for multiple frameworks based in webcomponets and it was an utter failure in practice especially for low band networks.
To be fair, HTML imports is deprecated and won't be standardised. The recommended way to package web components now is with ES modules, and they can be bundled (with eg. Rollup or Webpack.)
It has great tooling, awesome community, and it's pushed the boundaries of how we thought frontend development.