I mean, Web Components already gives you a pretty similar experience: you can stick arbitrary properties on your custom elements and use shadow DOM to build internal documents that outside code can't inadvertently access. That and WASM is basically feature-equivalent to what ActiveX was trying to do, but actually engineered to be a standard rather than just proxying everything to COM/OLE.
I don’t believe that Web Components had anything to do with it at all.
When you control the scripting environment, and would be instantiating in scripting rather than in serialised markup, Custom Elements are one of the more superfluous features of the web platform: everything you can do with them, you can do every bit as effectively without them, at no meaningful cost or cost saving.
The point where things get a little more interesting is when you introduce Shadow DOM, because then you do have genuine capabilities that can’t be expressed in other ways (though whether you want to may be another matter).
But the real kicker, in my assessment and conclusion, is that both of these features landed after the migration from XUL to HTML began. (Not all that long after, and they have since been used variously, but the moving initiatives began before they were available.)
Web Components are Custom Elements + Shadow DOM, and this makes half of that equation server-side. The other half works as a client-side hydration strategy until they churn out whatever Declarative Custom Elements would look like.
Absolutely agree. My only gripe is that consuming a blackbox (ie third party) Web Component inside a Web Component can get problematic. Your options become create a global override system or (shudder) Shadow DOM piercing.
Really neat. I must be living under a rock, but I never had heard of this before. It seems to bring a lot of the advantages of component-oriented development with it - just declare and go and the implementers will have taken care of the necessary wiring behind the scenes to make the components work. What I don't have a feel for though is what disadvantages it might bring from component oriented development - how easy for example would it be to change the style and/or behavior of the expanded component dom objects, in a way that the original developers never thought of, if need be? In any case, very cool and thanks for posting.
To me Web Components is in early stages but seems like the closest we are going to get to that perspective/approach. Makes it easy to define your own HTML tags.
I like the idea of web components, but feels like a mistake to have welded shadow dom to the implementation (or at least the default way they are implemented/described/advertised).
The vast majority of devs I've worked with who try and use them are basically using them like JS frameworks or HTML templates in normal apps.
Shadow DOM is just really a poor fit for this type of use IMHO and results in practical issues like the OP.
I'm always really surprised when I read posts like these and they don't mention Web Components/Shadow DOM.
The ability to encapsulate markup, style, and behavior into a single unit with a clean API is an enormous improvement. Of all the new HTML5 features, I think Web Components have the highest potential to relieve a huge pain point for developers.
Image an online repository with all kinds of widgets -- range sliders, date-pickers, sortable lists, etc. But instead of a collections of inconsistent jQuery plugins with CSS dependencies, you get a single, self-contained module that can be interacted with as if it were a native DOM node.
Came here to drop a link to web components ;) imho, empowering devs to define elements & their behavior is better than defining a standard set of elements & their behavior.
Well, yes, because web components are native to the browser, not some third-party library. In other words, I'd feel no more locked into Web Components than I feel locked into the current DOM API.
"Web components" is really a collection of several independent specifications. Custom elements and shadow Dom are two of those, and I tend to agree that sticking with just custom elements will save a lot of headaches with the way things are now.
Having worked with web components over the past few months, yes this. I can mix and match polymer, x-* elements, brick components etc with ease. I don't have to care how a given component is written or what its dependencies are. It's definitely the future.
"Web Components" are the name for a dream, not an actual technology. The actual technologies involved -- customElement and shadow DOM -- are pretty crappy to use directly, and even when hidden behind a framework/library don't buy you that much. But people want it to be true that there is such a thing as a "Web Component" so the dream lives on.
I'd like to like web components, but their reliance on JS to instantiate along with all the chaos of the shadow DOM keep them off the table for me. I think they are a great concept defeated by the implementation.
The web component idea originally had something like 4 basic components.
- custom elements
- shadow DOM
- html imports ( now dead or at the very least 'resting' )
- html templates
I think it's important to note that you can build/use custom elements ( defining your own tags with encapsulated behaviour ) without having to use shadow DOM nor html templates.
So a simple way to start, in my view, is plain custom elements, mixed in with ES modules and import maps.
Shadow DOM and html templates are not compulsory to get your <custom-tag></custom-tag>
I'm saying that DOM through its relationship to HTML has weaknesses that make it unsuitable for building application components out of. "jQuery-enabled div-soup" is an example of how mixing presentation with model and logic yields unmaintainable results.
I have been interested in React.js recently, since it provides an interface to create reusable components and to use them inside a rich programming language with full types. I think that's a better example of a competing idea.
My experience is with building single page apps from scratch, so maybe there's a common use-case (embedding a twitter widget, or a 3rd party comment system in a blog) that Shadow DOM and Custom Components will address that I'm not familiar with.
reply