1. 2
  1.  

  2. 5

    I still don’t get why I should care about Web Components. What problem do they actually solve?

    If I’m going to depend on JavaScript anyway, then why wouldn’t I just use any of the decent libraries/frameworks/languages available? Reusable widgets? Yeah we can do that in every other available alternative.

    In fact, if I don’t want to rely on JavaScript, then I can create reusable and extensible HTML components in any static site generator or web framework. It’ll have better browser support than Web Components too.

    IIRC, the spec for WC was proposed in 2012 or so, and it still doesn’t seem to have a purpose or solve any real problems. This tech is dead in the water.

    1. 4

      Each JS framework has its own API for reusable components. A react-video-player won’t work in Ember, and a ember-preload won’t work in Vue. For example, Matrix.org’s JavaScript SDK is tied to React. Other JS SDK’s use an iframe (Facebook Like Button and other ad-tech SDK’s usually go this route) or abstain from providing any UI functionality at all (like WebTorrent).

      Web Components, since they act exactly like built-in HTML elements, should work within any framework. If your framework can render arbitrary HTML elements, then it can render a custom HTML element. If you’re just building an app, it doesn’t matter; just render the HTML that you want in your template language. As a library author, the ability to provide a JavaScript widget with some level of encapsulation using only browser built-in APIs seems really nice.

      1. 0

        Ok, so WC allows you to build widgets that aren’t specific to React, but are instead specific to the JavaScript you need to include to make WC work. What is the practical difference between that and jQuery widgets?

        Don’t take me for a jQuery fanboy now, but typical jQuery widgets (or even just plain JavaScript libraries) neither depend on React, nor require an iframe.

        Plug-n-Play JavaScript widgets which aren’t tied to a particular framework have been available since forever, and there is exactly zero practical difference in being able to use a custom tag name for it. Exactly zero users care if under the hood an element is constructed with

        <foo></foo>

        instead of

        <div class="foo"></div>

        1. 4

          They’re composable: you can do <foo><bar></bar></foo> without either widget needing to know how the other works. Otherwise there’s not that much difference with regular ol’ hacked-together widgets, apart from (IMHO) they’re cleaner to install and easier to write.

      2. 1

        WebComponents give you custom tags that can do custom things. Custom tags are a good thing because they allow you to do your custom things in a composable and contained way that can be reused (hence the “Components” in “WebComponents).

        All of this without having to worrry about a web packer, a transpiler and at least a fuckton of JS code (fuckton is the SI-unit for external JS). It all comes built-in in the major browsers for your pleasure and it is far easier to use than any existing framework:

        class MyComponent extends HTMLCanvasElement {
        // Your custom made `<canvas>` element logic goes here
        }
        

        Just extend the elements you want with your custom logic or build a brand new element from scratch yourself (like the author did in the article).

        Now open your browser console and start coding away! Its free :)

        1. 3

          Custom tags are a good thing

          This is literally the opposite of what everyone in the web standards world said for years. Not the only whiplash this space has given me recently.

          1. 1

            Can you give an example ? XML had support for namespaces since version 1.0. Custom elements/tags were somewhat of a target even before web components came along. If you take a look at any react codebase you will also find lots of custom elements as JSX works with those at the base.

            1. 1

              Support for namespaces would be super cool, but we’ve never really gotten close enough to that being a reality in the web-browser-HTML world.

              I know custom elements have been around for a long time. Wouldn’t have had to crusade against them if no one were trying to constantly add nonstandard crap to their pages.

              JSX is… less bad? Because it’s not actually in the markup. Though it’s still very odd and of course the whole rendering webpages from JavaScript thing is bad but that’s a different discussion.

              1. 1

                It’s a pity that server rendering of react apps is so CPU intensive; I’ve been on several projects which implemented it and then switched it off again.

          2. 1

            without having to worrry about a web packer, a transpiler

            Oh yeah. Once import maps become a thing, it will be possible to use libraries like LitElement from npm packages in a completely toolless way :)

            1. 1

              Didn’t knew about those. Cool stuff :D

            2. 0

              Custom tags are a good thing because they allow you to do your custom things in a composable and contained way that can be reused (hence the “Components” in “WebComponents).

              The ability to create custom tags is completely orthogonal to the goal of self-contained components. A custom tag just moves an identifier that some styles/scripts need from an attribute to the tag name itself.

              All of this without having to worrry about a web packer, a transpiler

              You don’t need these things to use JavaScript libraries.

              and at least a fuckton of JS code (fuckton is the SI-unit for external JS)

              That code has to exist somewhere. Does Web Components somehow magically make all that code disappear? I think your argument here is a bit silly and totally incorrect.

              It all comes built-in in the major browsers

              No it doesn’t. I’m not sure if you’ve ever tried to run an online business, but a significant proportion of business web-app users still run IE11, which doesn’t run Web Components. Looks like you can get it working with some polyfill.

              it is far easier to use than any existing framework

              That’s pretty subjective. I don’t find your hello-world-esque snippet compelling. If I want to create a custom canvas, I can do that just as easily without Web Components.

              1. 1

                The ability to create custom tags is completely orthogonal to the goal of self-contained components. A custom tag just moves an identifier that some styles/scripts need from an attribute to the tag name itself.

                It gives you the ability to describe your component name an arguments in a declarative way and use it in a ideomatic style long-side other elements of your web app. I find your absolutist approach disturbing, almost troll-like. They are certainly not “completely” orthogonal and the design decision of using a custom tag as since been replicated in many other places (such as JSX components).

                You don’t need these things to use JavaScript libraries.

                You certainly don’t need. But when the average pkg dependency has several levels of nested multi-dependencies that may be reused in other packages you will be glad that you are using tools to help you minimize your build and keep those dependencies in place. Sure you can simply use <script src="components-pkg.js"> and write it all in that single file without the use of any tool. Claiming that “You don’t need these things to use X” without providing any other kind of counter-example seems like claiming that you don’t need a file editor to write code and point to some random xkcd comic in a serious way. Again, this certainly feels troll-like from your part.

                That code has to exist somewhere. Does Web Components somehow magically make all that code disappear? I think your argument here is a bit silly and totally incorrect.

                Sorry I was trying to make it lighter. That code does have to exist somewhere, it comes bundled in your browser (if it supports) and most likely not implemented entirely in JS.

                No it doesn’t. I’m not sure if you’ve ever tried to run an online business, but a significant proportion of business web-app users still run IE11, which doesn’t run Web Components. Looks like you can get it working with some polyfill.

                Sorry for not including IE11 as a major browser. Most web devs typically don’t. In which case I’ll rephrase: WebComponents are supported by all major browsers except IE11 where you can use a polyfill to make them work.

                That’s pretty subjective. I don’t find your hello-world-esque snippet compelling. If I want to create a custom canvas, I can do that just as easily without Web Components.

                Can you show an example ? Why don’t you find extending a class compelling ? Would you prefer a prototype approach or a more functional approach ?

                1. 0

                  It gives you the ability to describe your component name an arguments in a declarative way and use it in a ideomatic style long-side other elements of your web app.

                  There is nothing more “declarative” about moving an identifier into a tag name vs using that same identifier in an element attribute. Whether or not custom tag names is ideomatic [sic] is also 1) not true, since by far most of the Internet does not use custom tag names, and 2) in my opinion not a tradeoff I see as a good deal. A cursory cost/benefit analysis to me says that adding extra machinery just so you can write <foo> instead of <div id="foo"> is not worth it.

                  They are certainly not “completely” orthogonal

                  Yes they are. I understand English is not your first language and perhaps you are misunderstanding that word, but the fact is you do not need custom tag names to create self-contained components.

                  and the design decision of using a custom tag as since been replicated in many other places (such as JSX components).

                  This is an appeal to authority kind of reasoning. The fact that JSX exists and they adopted the same idea doesn’t mean much of anything. You do realise in React’s case, it’s just syntax sugar around a bunch of function calls, right?

                  You certainly don’t need. But when the average pkg dependency has several levels of nested multi-dependencies that may be reused in other packages you will be glad that you are using tools to help you minimize your build and keep those dependencies in place. Sure you can simply use and write it all in that single file without the use of any tool. Claiming that “You don’t need these things to use X” without providing any other kind of counter-example seems like claiming that you don’t need a file editor to write code and point to some random xkcd comic in a serious way. Again, this certainly feels troll-like from your part.

                  I’m sorry, how is this relevant? Are you telling me that Web Components also handles package management and dependency resolution? Because I don’t think it does.

                  That code does have to exist somewhere, it comes bundled in your browser

                  I don’t believe the promise of web components is that they will bundle all of the JavaScript libraries you would ever want to use in your browser. Your argument was that Web Components somehow obviates the need for external JS, since you said “a fuckton of JS code (fuckton is the SI-unit for external JS)”. This is obviously completely false.

                  Sorry for not including IE11 as a major browser. Most web devs typically don’t.

                  Yeah, it’s a shame most web developers apparently have little regard for anything other than the happy path when it comes to building software products for businesses. Windows 10 (and by extension IE11) still isn’t EOL, and it still has a not insignificant market share. I’m a “web dev” myself, and I can’t afford to present paying customers of my business with a broken experience, hence my relatively conservative approach.

                  Why don’t you find extending a class compelling ? Would you prefer a prototype approach or a more functional approach ?

                  The syntax is completely irrelevant here. This may be the point we’re talking past each other the most on. Syntax just isn’t that important.

                  You’ve suggested a couple of times that I’m a troll since I haven’t provided counter-examples. This really is not the case. I don’t feel I need to provide counter-examples, because they are already in such great abundance and have been for a very long time. Here’s one self-contained component though, since you insist.

                  1. 1

                    Windows 10 (and by extension IE11)

                    The default browser on Windows 10 is Edge, not IE11.

                    just so you can write <foo> instead of <div id="foo">

                    It’s not just about that! It’s about the lifecycle!

                    With Custom Elements, your code is called when the element is created, removed, attributes are set, and so on. You are literally subclassing DOM elements and adding your behavior. The result is, your elements can act like native ones. The consumer of your element doesn’t have to call new SomeThing(someDomNode) or anything like that, they just drop <some-thing> into anywhere — a static file without a line of JS, a framework template, anything.

                    The DOM is a component model. The browser’s native component model. Custom Elements makes it extensible.

                    If you really think ad-hoc “components” where you just start a component’s behavior with a call like new SomeThing(someDomNode) are acceptable.. I don’t know how to convince you.

                    1. 1

                      The default browser on Windows 10 is Edge, not IE11.

                      I see. In that case, I don’t know who these people are who insist on continuing to use IE11 (probably not their choice actually), but those people do exist.

                      The consumer of your element doesn’t have to call new SomeThing(someDomNode) or anything like that, they just drop into anywhere — a static file without a line of JS, a framework template, anything.

                      If I write a static HTML page now — in a browser where Web Components are supported — and I “just drop <some-thing> into anywhere” on the page, what will happen? Where are the scripts associated with this custom element? Does the browser download them? Are all custom elements in the universe bundled into every browser? Is there some global registry which contains all the unique names of possible custom elements?

                      If you really think ad-hoc “components” where you just start a component’s behavior with a call like new SomeThing(someDomNode) are acceptable.. I don’t know how to convince you.

                      This is how 99.99999% of the scripted Internet currently works. I’m quite happy with the Internet. Any criticisms I would level at Internet technology do not involve this aspect. I am sorry you find almost all of the Internet unacceptable.

                    2. 0

                      ok