23 ms·

The Failed Promise of Web Components

367 points by lemonberry 6y ago

the_only_law 6y ago
Man I remember reading about web components some years ago after reading up on Poylmer Dart. It seemed like they were destined to become a common standard for building web apps soon(tm) but I guess frameworks like React blew up a lot quicker.
- spankalee 6y ago
  They are a common standard for building web apps. Dart itself hasn't kept up with web standards in general, but that's another story.
  - deleted 6y ago
    [deleted]
macawfish 6y ago
I recently stumbled across "shoelace", which at a glance seems like an example of what the article is hoping for. It's a thoughtfully designed library of UI web components. https://shoelace.style/ https://shoelace.style/
- dheera 6y ago
  ... and it suffers from the same oversight every other web component library (polymer, mdl) suffers from: - I can't swipe left/right between the tabs - I can't pull the menu out from the left by swiping the entire page right Two of the most basic touch navigation metaphors aren't supported. To be fair, Polymer and MDL don't support the above either. But this is why HTML5 apps are still not up to par with native apps. I really want to see a web component library with full touch functionality -- tab swiping, pinch zoom on images, pull to refresh on lists and card lists. https://shoelace.style/components/tab-panel https://shoelace.style/components/tab-panel
  - coder543 6y ago
    > it suffers from the same oversight every other web component library (polymer, mdl) suffers from: > - I can't swipe left/right between the tabs > - I can't pull the menu out from the left by swiping the entire page right Most native apps don't do either of those two things either... at least on iOS. I can't speak to how Android apps behave these days. Maybe these are your favorite interaction modes, but it really has nothing to do with whether X is "up to par with native apps." I'm certain these things could be implemented. Clearly they weren't considered desirable by the authors of Shoelace. What really holds HTML5 apps back is the fact that Apple consistently drags their heels on adopting push notifications for web. It only has to be available for apps that have been added to the home screen, so all the users who complain about getting nagged for notifications as they browse the web would still be perfectly happy not to be getting nagged. Without notification support, the number of companies who seriously invest in HTML5 apps (instead of native apps) is nearly zero, which really hinders investment in HTML5 frameworks targeting mobile app development (not frameworks just targeting mobile website development). Clearly, Apple benefits from pushing app developers into the App Store where they can require those developers to give them a cut of the profits.
    - robocat 6y ago
      > I'm certain these things could be implemented. Pulling a menu out from the left certainly cannot be implemented on iOS Safari Mobile, because it doesn’t support https://caniuse.com/css-overscroll-behavior https://caniuse.com/css-overscroll-behavior Supporting swipe left/right fails hard on iOS Mobile Safari because the browser wants to history navigate back/forward if you misplace your finger, and it is easy to inadvertently refresh the page unless you are very careful not to. I don’t think there is any effective workaround.
      - dheera 6y ago
        > Pulling a menu out from the left certainly cannot be implemented on iOS Safari Mobile Well HTML5 apps will never be a good experience on iOS then. On Android you can do almost anything UI-wise with Chrome, which paves the way to HTML5 installable apps.
- ssorallen 6y ago
  Thanks for the link. This library unfortunately highlights further challenges with Web Components like mixing custom WCs with native form elements. To use Shoelace form elements at all, you'll end up writing a bunch of JavaScript. > Shoelace forms don't make use of action and method attributes and they don't submit the same was as native forms. To handle submission, you need to listen for the slSubmit event as shown in the example below and make an XHR request with the resulting form data. > https://shoelace.style/components/form https://shoelace.style/components/form
  - domenicd 6y ago
    This is fixable, using the form-associated custom elements feature that's specified in HTML. (Introduction: https://html.spec.whatwg.org/multipage/custom-elements.html#custom-elements-face-example https://html.spec.whatwg.org/multipage/custom-elements.html#...) However, that's only currently shipping in Chrome, despite the other browsers being positive on it. Similar capability gaps that we're working to close are accessibility (https://html.spec.whatwg.org/multipage/custom-elements.html#custom-elements-accessibility-example https://html.spec.whatwg.org/multipage/custom-elements.html#..., same situation, everyone likes it, only Chrome ships so far) and focusability (https://github.com/w3c/webcomponents/issues/762 https://github.com/w3c/webcomponents/issues/762, still figuring out what the solution should be).
    - ssorallen 6y ago
      That’s great, thanks for the links.
  - claviska 6y ago
    > To use Shoelace form elements at all, you'll end up writing a bunch of JavaScript. Shoelace author here. This is somewhat true (I wouldn’t call it “a bunch” though), and it will be until form-associated custom elements are standard. However, I’d argue that most form validation and submission is done with JavaScript these days. I can’t think of the last time I saw a post request submitted from a form in the wild. (Not that it doesn’t happen, but it seems to be quite rare now.)
- yesimahuman 6y ago
  Shoelace is awesome! Also it is built with Stencil, which is a tool that generates web components from a development experience React and Angular devs would find familiar. One of the benefits of Stencil is that it can generate Angular, React, and Vue-specific bindings. This smooths over any issues React has in working with WC's and provides a first-class React experience. Stencil was built to power Ionic Framework which is arguably one of the most popular web component UI libraries. Fun fact: there are many thousands of app store apps built with web components! (data: https://appfigures.com/top-sdks/development/apps https://appfigures.com/top-sdks/development/apps). This underscores a fact about WCs: their proliferation is largely happening behind the scenes and unnoticed by many in the web world.
rektide 6y ago
It would have helped a lot if JS had a working modules systems on the web. > What hope do those who can’t write JS have? Using a custom element from the directory often needs to be preceded by a ritual of npm flugelhorn, import clownshoes, build quux, all completely unapologetically because “here is my truckload of dependencies, yeah, what”. JS has been in a dark & ugly spot, & WebComponents feeling janky & weird is probably 50% the fact that JS is this dark twisting maze where each project has it's own very unique assumptions about how to turn authored JS into usable, deployable JS. We're still hoping, praying that import-maps eventually give us modular javascript code that we can deploy, without having to push it through a handful of compile/build tools: https://github.com/Fyrd/caniuse/issues/4810 https://github.com/Fyrd/caniuse/issues/4810 By compare, Big Framework land often adopts some suggested normative best paths people can work with (ex, create-react-app bundling build/test/&c tools). Alas, the language itself is still, a decade latter, trying to proceed to useable modules on the web. The other major point of this article tends towards a JS vs HTML problem, another area I am very sympathetic to & have hopes for. > Far more people can write HTML than JS. Even for those who do eventually write JS, it often comes after spending years writing HTML & CSS. [...] If components are designed in a way that requires JS, this excludes thousands of people from using them. There are ongoing efforts with HTML Modules ( https://www.chromestatus.com/feature/4854408103854080 https://www.chromestatus.com/feature/4854408103854080 ) to try to make, among other things, bringing in WebComponents much easier, and Declarative Custom Elements ( https://blog.usejournal.com/w3c-declarative-custom-elements-proposal-b9640e54a5fd https://blog.usejournal.com/w3c-declarative-custom-elements-... ) to make building modules much more HTML-centric & declarative versus today where most of the authoring of a custom element has to be done in JS. There are very real problems, there is too much js, the js module system is still in a 1/2 complete state on the web, & these very much dog Web Components. But the future is exciting, & I continue to have hope that a much better, much more web native way of building emerges on the web platform. Lea talks a lot to how scattershot the last decade of work has been, how inconsistent, but given the other ecosystem constraints I'm not fully surprised, & I'm delighted that we are spending so long building & experimenting & learning, that for many of us, the hunger is very real. Also missing, the big adopters of WebComponents have been pretty silent, their thought-leadership seems missing: Youtube, Github. There are visible people from these worlds talking about WebComponents, but to my knowledge the real experience of WebComponents at scale from the very successful adopters remains a story not told.
devwastaken 6y ago
Something about this website makes mobile chrome scroll at low fps.
pfraze 6y ago
I completely agree with the author that WCs fail to push more behaviors into HTML. As she describes, you really want to be able to import the WC's script and then have new useful HTML tags. I use LitElement pretty extensively, which is a wrapper around WCs, and I like it quite a bit - but it's only a minor improvement in my mind compared to React, and that improvement is just reducing the abstractions from the DOM API. It's still a mega codebase. I've also tried multiple times to just work with vanilla WCs, and it's sensible only up to a very limited point. If you got a JSX/lit-html module involved it would go further, but at that point it's pretty past "vanilla." And even then, you're not in the realm of "just using HTML." Author lays a lot of that on the developers having a proclivity for JS, and that may be true, but I've been trying to figure out if this is just complexity in the stack that hasn't yet be solved. UIs are complex, you have lots of stateful interactions between them, and I'm really not sure what the right solution would be for a "do lots via HTML" goal.
- WorldMaker 6y ago
  My impression is that JS has led WCs for the simple fact that JS is easier to polyfill/prollyfill/ponyfill and there's a lot more infrastructure today for JS modules and JS bundling. Web Components have been a lot of trying to assemble the cart behind you while riding the (JS) horse, simply because web standards are so slow. (I'm not sure if that analogy entirely works, though in my head it adds the unsightly picture that at least some of the material you have to build the cart with is manure, and WCs being built more than partly from JS manure does sound accurate.) ES2015 modules are about at the point that caniuse statistics show them as nearly viable for production work, with HTTP/2 (or 3) deployment being possibly the last puzzle piece for a global lessened reliance on bundling for performance reasons. (Though not for simplicity of usage reasons: it's still useful to be able to drop an entire third party bundle all at once on a file host and use the thing as a single import.) Meanwhile, CSS Modules are still something prollyfilled by JS bundlers and there still isn't an official spec yet?! And "HTML Modules" is so barely on the drawing board that it would be optimistic to call what JS bundlers are doing there as anything resembling a "prollyfill" (we're to "wishfill", I guess?). (And most JS WCs are using virtual DOMs or JS-native template tools instead of HTML templates anyway.)
- 6y ago
verisimilidude 6y ago
Fully agree with the author. My biggest complaint about web components is that I don’t see a lot of advantages over using React, Svelte, or some other JS library. The author hints at this: if I’m already committing to a big JS build process, why wouldn’t I reach for one of these more ergonomic JS tools? Warm fuzzies for trying to use open standards isn’t enough to convince most people to switch away from more popular JS solutions.
- spankalee 6y ago
  The benefit isn't warm fuzzies - it's interoperability: with other components, tools, the browser and devtools, other developers. If you build an app with web components, even if you're using one specific helper library to do it, it makes it possible, easy even, to incrementally migrate to other libraries. You can migrate top-down, bottom-up, or even middle-out to other helper libraries and have a continuously working app. You can import and use another web component built with another library without being constrained to just the framework you chose. You can even build an app with all web components, later decide you really don't like them and want to use only a framework and still easily incrementally migrate top down and not break the app. This makes web components the much safer choice for large and long lived projects, and more flexible for projects of all sizes.
- onion2k 6y ago
  One huge advantage is that you can isolate a web component in its own shadow DOM, which means it has CSS that's independent from the rest of the page. If you're making something for other people to embed in their code, even if you're on the same project, you can save them from breaking it by styling it by mistake. You can also close the shadow DOM to stop people easily inspecting it, but I must admit I haven't actually figured out a reason to do that yet.
  - franciscop 6y ago
    That is the same if you use e.g. styled components with React, where every component is self-contained and doesn't leak the styles. The mechanism is different, but the end result is the same, and oh it's a game changer IMHO.
ChrisMarshallNY 6y ago
I love her description of using a dependency-laden component: > Using a custom element from the directory often needs to be preceded by a ritual of npm flugelhorn, import clownshoes, build quux, all completely unapologetically because “here is my truckload of dependencies, yeah, what”. Many steps are even omitted, likely because they are “obvious”. Often, you wade through the maze only to find the component doesn’t work anymore, or is not fit for your purpose. That is so true. The "unapologetically" thing is important. I see this all the time. There's often a fair bit of 'tude, where I am looked at with condescension, for not knowing something "obvious." The fig tree pic is perfect. EDIT: Removed phrase that was possibly corrosive to the narrative.
- lazyjeff 6y ago
  > BTW: This lady has a Masters from MIT. She def knows her way around things. Moreso than that, Lea is near the end of a Ph.D. in David Karger's group, an expert on CSS, and overall amazing researcher and developer for the web.
  - dejavuagain 6y ago
    It's sad to see the sexism in the need to preemptively back her up.
    - taytus 6y ago
      I don't think people are "backing her up" because of sexism. I saw it more as: "She knows her shit. Dear devs, pay attention" And yes, Lea is pretty awesome.
      - xmprt 6y ago
        Yup. All too often I see posts just like this from someone who self taught themselves javascript two years ago and after building a few personal projects, thinks they're an expert on it.
    - ChrisMarshallNY 6y ago
brundolf 6y ago
This post is needlessly snarky, but I don't disagree with the basic premise. Here's what killed web components: lack of native databinding on the web. That's the reason the standard is useless without JS. Any modular, dynamic, modern UI requires databinding, which means it's going to bring in a framework anyway, which means that self-contained widgets are all going to bring in their own frameworks, which means that instead of one large framework on the page you have five or six, all of them stitched together through rickety HTML-attribute APIs and custom value-parsing strategies because HTML attributes are just strings. I fail to grasp why databinding hasn't made it into a web standard yet. The web has a long tradition of feeling out features in the JS world before adopting the successful ones into the platform. jQuery turned into querySelector() and fetch(), CommonJS modules blazed the trail that led to ES modules, etc. And this next paradigm is more than ready to get standardized. Not only would it make the dream of web components possible, it would eliminate the need for a whole lot of the JavaScript out there and even make UIs faster, since reactivity logic would be implemented natively. It's such an obvious, ubiquitous improvement to the web that I can only assume there's some fundamental implementation roadblock I'm missing.
- gavinray 6y ago
  To be frank, I think in large part this is due to React. I'm not an authority in this area, but I seem to recall that because React uses a synthetic event system, it won't interoperate with Web Component bindings and emitted events. (I know React doesn't work well with Webcomponents, the part I'm unsure of is whether it's specifically due to this). React also doesn't have an easy means of turning React components into Web Components for publishing and consuming. (Preact does though, they put a lot of work into it). Svelte, Vue, and (I believe) Angular can all emit web components. In Vue, you can use the framework's standard data-binding and event capture syntax to interact with custom web components. You wouldn't be able to tell the difference between a Vue component and a Web Component you imported from a package. (I can't speak for Angular, maybe someone could chime in here.) To me, it represents a huge failure on the part of the developer community not to make publishing web components the standard. It seems silly to write a wildly popular component/component-library, and vendor-lock it to a single framework. Why not just publish a web component version as well? https://cli.vuejs.org/guide/build-targets.html#web-component https://cli.vuejs.org/guide/build-targets.html#web-component https://preactjs.com/guide/v10/web-components/ https://preactjs.com/guide/v10/web-components/ https://dev.to/silvio/how-to-create-a-web-components-in-svelte-2g4j https://dev.to/silvio/how-to-create-a-web-components-in-svel... https://angular.io/guide/elements https://angular.io/guide/elements
systemvoltage 6y ago
What is a well designed component given current limitations of HTML spec? There is no way around it. The author makes really good points but offers no solution. Just complains. Would love to know more how we can do this better if there is a way.
atum47 6y ago
Hi, please take a look at my FOS library. I tried to do exactly what the article describes a web component should do - extends HTML providing new elements that can be used without any further "programming". https://github.com/victorqribeiro/fos https://github.com/victorqribeiro/fos
c-smile 6y ago
> Can we fix this? Sure, by returning to basics. Let's assume that Web Component is a DOM element with a code associated with it + lifecycle events. Here is how Components are done in Sciter ( https://sciter.com https://sciter.com ) 1. CSS has got `prototype` property: div.my-component { prototype: MyComponent url(script/components.js); } where MyComponent is the name of class in JS, url (optional) is an URL where this MyComponent can be found. 2. In script that custom component is usually represented by ES6 class (+ decorators) class MyComponent extends Element { // lifecycle event/method componentDidMount() { } // lifecycle event/method componentWillUnmount() { } // component specific methods foo() { } bar() { } // event handlers - decorated functions @event("mousedown") onMouseDown(evt) { } @event("click", "button#submit") onSubmit(evt, button) { } @event("change", "input.name") onNameChange(evt, input) { } } and that's it. Sciter lives with this schema more than 10 years - proven to be very convenient and flexible. Yet simple: one property `prototype` + simple wiring of lifecycle events.
- agumonkey 6y ago
  after doing a bit of vue I wanted this :)
  - c-smile 6y ago
    The good thing about this mechanism is that you just need CSS in order to declare your components. The script will run only if you have elements with matching selectors. So you may have component libraries. Browser will instantiate only used components.
- cdata 6y ago
  This is literally what a custom element is. Assuming your @event decorator is built upon the EventTarget interface: class MyComponent extends HTMLElement { // lifecycle event/method connectedCallback() {} // lifecycle event/method disconnectedCallback() {} @event("mousedown") onMouseDown(evt) { } @event("click", "button#submit") onSubmit(evt, button) { } @event("change", "input.name") onNameChange(evt, input) { } } That said, custom elements don't cost $310 for an indie license. Instead, they are free and available in every web browser.
sam_goody 6y ago
If there was a way to write JS within the component, I think that they could have taken off - just see how well components are in React, Vue et al. And to get that to happen, all you would need is the ability to refer to `this` within the component. Aside for that, treat the JS within the component as a module, ability to access global vars, but within scope. But instead, you are expected to put the relevant JS in the code that creates the component (in the parent document), which means that reusability and is a pipe dream, and components are really not componentized.
- megous 6y ago
  You don't need to add anything to the global JS object to create a web component. It can be completely isolated and untouchable from the document's scope, except for registering a html name for the component, so that you can reference it from DOM/HTML.
- claytongulick 6y ago
  I'm not sure what you mean? All my components are totally encapsulated, and each module is self registering. All I have to do is import "path/some-component.js" and I can then use <some-component> in any markup I want.
aitchnyu 6y ago
TIL of <dialog> which can get by with very little JS. But why is Safari refusing to implement it and why did Firefox put it behind a feature flag for years?
- werdnapk 6y ago
  I think the reason Firefox hasn't exposed it completely yet is to deal with accessibility issues.
richardanaya 6y ago
I’m personally super excited for lit-html’s future in web components. It feels much simpler.
Animats 6y ago
What's so embarrassing is that the HTML/CSS/Javascript mess does roughly the job Visual Basic did. But worse.
- runawaybottle 6y ago
  Is that true? If I download Visual Basic right now, could I make a sensible visual app vs React? I’m tempted to see if the truth is really out there.
  - devit 6y ago
    No, Visual Basic 6 can only place controls by X/Y position, has no databinding and no VDOM or way to create controls other than placing them in the designer or manually creating and destroying them in code. It's pretty terrible unless you want to make UIs with a fixed size and set of controls.
    - runawaybottle 6y ago
      So then I’ll keep the question open. What is the dopest UI framework across any language with great paradigms, design language, developer experience, and of course, dope results? Right now I’ll say the best iOS/android apps put web to shame. Is Flutter and SwiftUI where we should be looking? The question is specific to semi complex apps (typical crud), not websites.
      - mlvljr 6y ago
        QML might be.
- icedchai 6y ago
  Yep. Web development is mostly about putting square pegs into round holes, over and over again.
dmix 6y ago
I wasn’t aware that web components were promising advanced interactivity on the web without JS still doing the heavy lifting. I watched those early google talks too and he’s right that doesn’t seem like what they were promising earlier. I think OP confused including components using native HTML style tags would somehow also help solve the giant disparity in what you can accomplish with pure html/css and with JS added on top. The stuff about JS being dependency and framework heavy seem thrown in but is a bit of a different problem and often comes with the territory with any complex JS. If Web components weren't ever really going to promise a new JS free future (other than being a clean way to maintain complex layouts and import isolated/reusable chunks of UI) then those ancillary arguments about the JS ecosystem are a different and somewhat unrelated problem. This is mostly about the others misguided idealism that doesnt sync with the IRL demands on frontend development for interactivity and complex state management vs the very limited offerings of pure HTML.
sergeykish 6y ago
Web Components were crafted for jQuery world. $("#datepicker").datepicker() Custom elements resolves problem we had with XHR HTML response, it instantiates automatically. Problem solved. Widgets were popular and easily broken by CSS, solved by Shadow DOM.
- c-smile 6y ago
  Shadow DOM does not solve any real life problem. sDOM is spherical horse in a vacuum, my pardon.
  - deleted 6y ago
    [deleted]
  - c-smile 6y ago
    I'd appreciate any details from anonymous downvoters. Any sample that can be done by sDOM and is not feasible without it and associated machinery?
aazaa 6y ago
> The other day I was looking for a simple, dependency free, tabs component. You know, the canonical example of something that is easy to do with Web Components, the example 50% of tutorials mention. I didn’t even care what it looked like, it was for a testing interface. I just wanted something that is small and works like a normal HTML element. Yet, it proved so hard I ended up writing my own! I was looking for some examples of the better approach the author seems to want, but didn't find them. Found some in the article linked near the bottom: https://www.smashingmagazine.com/2017/02/designing-html-apis/ https://www.smashingmagazine.com/2017/02/designing-html-apis... The author gives an example of a list-type component. It can be initialized in one of two ways: - JS-first: an empty list element is added and a JS initializer populates the children from data - HTML-first: the full markup for the list is added, including children, and the JS works in the background to build the right internal data representation The rest of the article gives specific, actionable advice on building HTML-first components. For this reason, I think it's a better article to start with.
- deleted 6y ago
  [deleted]
cdata 6y ago
This article is tailored to attract the web components haters. IMO it does not foster a constructive thread of discussion, and some of the critique just as easily applies to the JavaScript ecosystem overall. Web components have some distance to go before they are ideal for all of their envisioned use cases. In particular, I am awaiting declarative shadow roots, declarative custom elements and template instantiation ("data binding"). That said, the work that has been done so far on them is impressive. Web components by and large have survived the needless antagonism they have received from some corners and proved themselves in production scenarios from companies big and small. If you have interacted with a Salesforce application, you have used web components. If you have visited Github, you have used web components. If you watch videos on YouTube, you have used web components. The ground truth is that web components are solving problems and making headway. They only stand to get better as new capabilities begin to land. I'm excited for what the future holds.
- ralphc 6y ago
  I do work in Salesforce, and I find Lightning Web Components easier to use and understand than the popular frameworks. Yes they require JavaScript, but the alternatives don't?
- divbzero 6y ago
  > This article is tailored to attract the web components haters. IMO it does not foster a constructive thread of discussion, and some of the critique just as easily applies to the JavaScript ecosystem overall. I think you missed reading to the very end! She concludes on a hopeful note that we can do a better job with Web Components, with a few specific proposals on what a better future could hold.
stevebmark 6y ago
If you work in the Salesforce ecosystem, you know they are doubling down on their use of web components in their "modern" development process. This has lead to a very poorly designed ecosystem. It's infuriating they continue to double down on a system that the rest of us are rightfully abandoning.
ChrisArchitect 6y ago
what the, this was already on here a bunch of times a week ago when it was news https://news.ycombinator.com/item?id=24581439 https://news.ycombinator.com/item?id=24581439 https://news.ycombinator.com/item?id=24587413 https://news.ycombinator.com/item?id=24587413 https://news.ycombinator.com/item?id=24587413 https://news.ycombinator.com/item?id=24587413 and a response post: https://news.ycombinator.com/item?id=24606342 https://news.ycombinator.com/item?id=24606342
- earthboundkid 6y ago
  I wrote the response. Maybe someone will submit it another three times and then it will finally catch on…
- suyash 6y ago
  Looks like many people were desperately trying for the post to trend which it din't until this one, not sure if this is breaking any HN guidelines, maybe moderator can chime in.
tarkin2 6y ago
The death of HTML imports killed web components for me. With HTML imports, you would import a HTML file. In that file would be css, html and the js to make the component. Then you’d use HTML as usual in your main file. Finally you could create custom components easily while keeping yourself dealing primarily with HTML. Instead, you were forced to use bizarre js import systems. And at that point you were in JS land. Firefox’s decision not to support HTMLImports in favour of waiting to see what happens with JS killed it.
- flowerlad 6y ago
  > In that file would be css, html and the js to make the component. You can do that. Here's an example Web Component that contains the css, html and javascript: https://github.com/wisercoder/uibuilder/blob/master/WebComponentsDemo/elements/ZxListEditor.tsx https://github.com/wisercoder/uibuilder/blob/master/WebCompo...
  - tarkin2 6y ago
    I'm talking about how you import that into your main HTML file.
- tannhaeuser 6y ago
  What's the point though to bake that into HTML if you need tons of JavaScript to make it happen anyway? You can just as well use the flexibility of JavaScript to build up component graphs. HTML, or rather SGML, has an established method of syntactically composing fragments using SGML entities that is well integrated into the process of editing HTML using plain text editors, not to speak of extending the vocabulary with new elements and their content models in powerful ways. Introducing elements into markup using script rather than declarative means only serves to complicate parsing, with questionable benefits.
  - tarkin2 6y ago
    Because with HTML you would use HTML to structure your elements. Javascript was never designed to structure element s we get things like JSX, to compensate, adding further complexity. HTML Imports was an attempt to keep with the existing platform.
k__ 6y ago
I always saw WCs as the leaves to the root that CSS frameworks already offer. You can drop in Bootstrap and the whole page looks nice, but the moment you want to use the GUI elements that consist of multiple HTML tags, things get ugly. WC would offer a way to merge these into one element. Then you could drop your JS framework of choice in the middle and be done with it. React isn't cool anymore? Well, at least you can take Bootstrap and its WCs with you. I had the impression CSS frameworks had a longer half-life than their JS counterparts anyway. I don't really care about all that HTML module stuff or JS requirements. Sure would be cool if things were different, but from a practical POV it doesn't seem THAT important to me.
wnevets 6y ago
>who revel in complex APIs, overengineered build processes and dependency graphs that look like the roots of a banyan tree. I keep thinking I'm just being old and cranky whenever I go through "modern" projects and my eyes cross at the overengineering and complexly. Does this mean other people are starting to see this aswell?
cletusw 6y ago
> "I just wanted something that is small and works like a normal HTML element" My first stop when looking for a web component is always https://component.kitchen/elix https://component.kitchen/elix because of their commitment to the Gold Standard (https://github.com/webcomponents/gold-standard/wiki https://github.com/webcomponents/gold-standard/wiki), which is basically to imitate native elements wherever possible.
shams93 6y ago
I'm using lit-element for a project it's much more usable than writing components from scratch. The growth of complexity on the client side is really quite staggering and thanks to browser stagnation I doubt it will get better any time soon. A platform that should be low code is really maximum over code!
divbzero 6y ago
It’s hard to tell from the comments here, but the author actually ends her article on a hopeful note and offers concrete proposals on how we could fix the shortcomings of Web Components and fulfill its promise: – No dependencies beyond one <script> tag – Syntax and API in line with conventions of built-in HTML elements – Accessible by default via ARIA – Themeable via ::part(), selective inheritance, and custom properties – Only one component of each type in the directory Which proposals would be beneficial is up for debate (esp. the last one IMO) but they’re worth highlighting and discussing.
dannymoerkerke 6y ago
I wrote a response to this article, Lea was kind enough to respond to it by the way: https://medium.com/swlh/the-failed-criticism-of-web-components-ee94380f3552?source=friends_link&sk=406daa6d2bb0a0e563f501bc8a99c4f5 https://medium.com/swlh/the-failed-criticism-of-web-componen...
gorpomon 6y ago
> I’m not sure if this is a design issue, or a documentation issue. Perhaps for many of these web components, there are easier ways to use them. Perhaps there are vanilla web components out there that I just can’t find. Perhaps I’m looking in the wrong place and there is another directory somewhere with different goals and a different target audience. I did a deep dive into web components for a client recently. I tried to see if we could translate an entire Angular component library into Web Components we could share with the entire org and they could use them regardless of wrapping framework. I ran into the same discoverability issues the author did. After finding a new package, I'd spend some time with it, hit its limitations and then by magically finding the right article I'd find an entirely different project. In total I ended up sampling: plain JS web components, Svelte, Stencil, lit-element, Angular -> WC, and probably a few more. None ever really seemed to work, and the jank I encountered in them all via slotting seemed to preclude using them-- I could never get rid of a very noticeable Flash of Un-styled Content. The end goal the author talks about sounds really nice, a simple script tag to get more HTML. I think in practice though, that end goal isn't so rosy. If your web page is just web components + html/css then perhaps it's performant enough . But if you're working on a truly massive application (think design collaboration tools, etc), then probably you'll just want to keep it all in the framework, you're already paying a size penalty, might as well not pay a complexity penalty as well. If we can get a simple, useful, and popular web component library as an accepted standard, I think it will be useful to a certain sliver of developer who needs more power than HTML/CSS but doesn't want to learn lots of JS, but I think that will be a sliver of developers, not many. For the rest, I can imagine single-file-per-component compilation based frameworks like Svelte will obviate the need for web components. Remember, html is for the authors, not the consumers of web pages, and if your app is suitably large enough you'll probably need complexity managed in several ways (global state, UI components, data fetching, etc) and in that sense a framework will likely serve you better.
int_19h 6y ago
For the past 10 years or so, every time I read one of those articles on the state of modern web development, I'm thankful that I've dodged that bullet. Coming from the desktop world, it feels like the amount of complexity exposed to the end users of all those frameworks is quite insane compared to what they're getting from them.

367 points by lemonberry 6y ago

Man I remember reading about web components some years ago after reading up on Poylmer Dart. It seemed like they were destined to become a common standard for building web apps soon(tm) but I guess frameworks like React blew up a lot quicker.

spankalee 6y ago
They are a common standard for building web apps. Dart itself hasn't kept up with web standards in general, but that's another story.
- deleted 6y ago
  [deleted]

macawfish 6y ago

I recently stumbled across "shoelace", which at a glance seems like an example of what the article is hoping for. It's a thoughtfully designed library of UI web components. https://shoelace.style/ https://shoelace.style/

dheera 6y ago
... and it suffers from the same oversight every other web component library (polymer, mdl) suffers from: - I can't swipe left/right between the tabs - I can't pull the menu out from the left by swiping the entire page right Two of the most basic touch navigation metaphors aren't supported. To be fair, Polymer and MDL don't support the above either. But this is why HTML5 apps are still not up to par with native apps. I really want to see a web component library with full touch functionality -- tab swiping, pinch zoom on images, pull to refresh on lists and card lists. https://shoelace.style/components/tab-panel https://shoelace.style/components/tab-panel
- coder543 6y ago
  > it suffers from the same oversight every other web component library (polymer, mdl) suffers from: > - I can't swipe left/right between the tabs > - I can't pull the menu out from the left by swiping the entire page right Most native apps don't do either of those two things either... at least on iOS. I can't speak to how Android apps behave these days. Maybe these are your favorite interaction modes, but it really has nothing to do with whether X is "up to par with native apps." I'm certain these things could be implemented. Clearly they weren't considered desirable by the authors of Shoelace. What really holds HTML5 apps back is the fact that Apple consistently drags their heels on adopting push notifications for web. It only has to be available for apps that have been added to the home screen, so all the users who complain about getting nagged for notifications as they browse the web would still be perfectly happy not to be getting nagged. Without notification support, the number of companies who seriously invest in HTML5 apps (instead of native apps) is nearly zero, which really hinders investment in HTML5 frameworks targeting mobile app development (not frameworks just targeting mobile website development). Clearly, Apple benefits from pushing app developers into the App Store where they can require those developers to give them a cut of the profits.
  - robocat 6y ago
    > I'm certain these things could be implemented. Pulling a menu out from the left certainly cannot be implemented on iOS Safari Mobile, because it doesn’t support https://caniuse.com/css-overscroll-behavior https://caniuse.com/css-overscroll-behavior Supporting swipe left/right fails hard on iOS Mobile Safari because the browser wants to history navigate back/forward if you misplace your finger, and it is easy to inadvertently refresh the page unless you are very careful not to. I don’t think there is any effective workaround.
    - dheera 6y ago
      > Pulling a menu out from the left certainly cannot be implemented on iOS Safari Mobile Well HTML5 apps will never be a good experience on iOS then. On Android you can do almost anything UI-wise with Chrome, which paves the way to HTML5 installable apps.
ssorallen 6y ago
Thanks for the link. This library unfortunately highlights further challenges with Web Components like mixing custom WCs with native form elements. To use Shoelace form elements at all, you'll end up writing a bunch of JavaScript. > Shoelace forms don't make use of action and method attributes and they don't submit the same was as native forms. To handle submission, you need to listen for the slSubmit event as shown in the example below and make an XHR request with the resulting form data. > https://shoelace.style/components/form https://shoelace.style/components/form
- domenicd 6y ago
  This is fixable, using the form-associated custom elements feature that's specified in HTML. (Introduction: https://html.spec.whatwg.org/multipage/custom-elements.html#custom-elements-face-example https://html.spec.whatwg.org/multipage/custom-elements.html#...) However, that's only currently shipping in Chrome, despite the other browsers being positive on it. Similar capability gaps that we're working to close are accessibility (https://html.spec.whatwg.org/multipage/custom-elements.html#custom-elements-accessibility-example https://html.spec.whatwg.org/multipage/custom-elements.html#..., same situation, everyone likes it, only Chrome ships so far) and focusability (https://github.com/w3c/webcomponents/issues/762 https://github.com/w3c/webcomponents/issues/762, still figuring out what the solution should be).
  - ssorallen 6y ago
    That’s great, thanks for the links.
- claviska 6y ago
  > To use Shoelace form elements at all, you'll end up writing a bunch of JavaScript. Shoelace author here. This is somewhat true (I wouldn’t call it “a bunch” though), and it will be until form-associated custom elements are standard. However, I’d argue that most form validation and submission is done with JavaScript these days. I can’t think of the last time I saw a post request submitted from a form in the wild. (Not that it doesn’t happen, but it seems to be quite rare now.)
yesimahuman 6y ago
Shoelace is awesome! Also it is built with Stencil, which is a tool that generates web components from a development experience React and Angular devs would find familiar. One of the benefits of Stencil is that it can generate Angular, React, and Vue-specific bindings. This smooths over any issues React has in working with WC's and provides a first-class React experience. Stencil was built to power Ionic Framework which is arguably one of the most popular web component UI libraries. Fun fact: there are many thousands of app store apps built with web components! (data: https://appfigures.com/top-sdks/development/apps https://appfigures.com/top-sdks/development/apps). This underscores a fact about WCs: their proliferation is largely happening behind the scenes and unnoticed by many in the web world.

rektide 6y ago

It would have helped a lot if JS had a working modules systems on the web. > What hope do those who can’t write JS have? Using a custom element from the directory often needs to be preceded by a ritual of npm flugelhorn, import clownshoes, build quux, all completely unapologetically because “here is my truckload of dependencies, yeah, what”. JS has been in a dark & ugly spot, & WebComponents feeling janky & weird is probably 50% the fact that JS is this dark twisting maze where each project has it's own very unique assumptions about how to turn authored JS into usable, deployable JS. We're still hoping, praying that import-maps eventually give us modular javascript code that we can deploy, without having to push it through a handful of compile/build tools: https://github.com/Fyrd/caniuse/issues/4810 https://github.com/Fyrd/caniuse/issues/4810 By compare, Big Framework land often adopts some suggested normative best paths people can work with (ex, create-react-app bundling build/test/&c tools). Alas, the language itself is still, a decade latter, trying to proceed to useable modules on the web. The other major point of this article tends towards a JS vs HTML problem, another area I am very sympathetic to & have hopes for. > Far more people can write HTML than JS. Even for those who do eventually write JS, it often comes after spending years writing HTML & CSS. [...] If components are designed in a way that requires JS, this excludes thousands of people from using them. There are ongoing efforts with HTML Modules ( https://www.chromestatus.com/feature/4854408103854080 https://www.chromestatus.com/feature/4854408103854080 ) to try to make, among other things, bringing in WebComponents much easier, and Declarative Custom Elements ( https://blog.usejournal.com/w3c-declarative-custom-elements-proposal-b9640e54a5fd https://blog.usejournal.com/w3c-declarative-custom-elements-... ) to make building modules much more HTML-centric & declarative versus today where most of the authoring of a custom element has to be done in JS. There are very real problems, there is too much js, the js module system is still in a 1/2 complete state on the web, & these very much dog Web Components. But the future is exciting, & I continue to have hope that a much better, much more web native way of building emerges on the web platform. Lea talks a lot to how scattershot the last decade of work has been, how inconsistent, but given the other ecosystem constraints I'm not fully surprised, & I'm delighted that we are spending so long building & experimenting & learning, that for many of us, the hunger is very real. Also missing, the big adopters of WebComponents have been pretty silent, their thought-leadership seems missing: Youtube, Github. There are visible people from these worlds talking about WebComponents, but to my knowledge the real experience of WebComponents at scale from the very successful adopters remains a story not told.

devwastaken 6y ago

Something about this website makes mobile chrome scroll at low fps.

pfraze 6y ago

I completely agree with the author that WCs fail to push more behaviors into HTML. As she describes, you really want to be able to import the WC's script and then have new useful HTML tags. I use LitElement pretty extensively, which is a wrapper around WCs, and I like it quite a bit - but it's only a minor improvement in my mind compared to React, and that improvement is just reducing the abstractions from the DOM API. It's still a mega codebase. I've also tried multiple times to just work with vanilla WCs, and it's sensible only up to a very limited point. If you got a JSX/lit-html module involved it would go further, but at that point it's pretty past "vanilla." And even then, you're not in the realm of "just using HTML." Author lays a lot of that on the developers having a proclivity for JS, and that may be true, but I've been trying to figure out if this is just complexity in the stack that hasn't yet be solved. UIs are complex, you have lots of stateful interactions between them, and I'm really not sure what the right solution would be for a "do lots via HTML" goal.

WorldMaker 6y ago
My impression is that JS has led WCs for the simple fact that JS is easier to polyfill/prollyfill/ponyfill and there's a lot more infrastructure today for JS modules and JS bundling. Web Components have been a lot of trying to assemble the cart behind you while riding the (JS) horse, simply because web standards are so slow. (I'm not sure if that analogy entirely works, though in my head it adds the unsightly picture that at least some of the material you have to build the cart with is manure, and WCs being built more than partly from JS manure does sound accurate.) ES2015 modules are about at the point that caniuse statistics show them as nearly viable for production work, with HTTP/2 (or 3) deployment being possibly the last puzzle piece for a global lessened reliance on bundling for performance reasons. (Though not for simplicity of usage reasons: it's still useful to be able to drop an entire third party bundle all at once on a file host and use the thing as a single import.) Meanwhile, CSS Modules are still something prollyfilled by JS bundlers and there still isn't an official spec yet?! And "HTML Modules" is so barely on the drawing board that it would be optimistic to call what JS bundlers are doing there as anything resembling a "prollyfill" (we're to "wishfill", I guess?). (And most JS WCs are using virtual DOMs or JS-native template tools instead of HTML templates anyway.)
6y ago

verisimilidude 6y ago

Fully agree with the author. My biggest complaint about web components is that I don’t see a lot of advantages over using React, Svelte, or some other JS library. The author hints at this: if I’m already committing to a big JS build process, why wouldn’t I reach for one of these more ergonomic JS tools? Warm fuzzies for trying to use open standards isn’t enough to convince most people to switch away from more popular JS solutions.

spankalee 6y ago
The benefit isn't warm fuzzies - it's interoperability: with other components, tools, the browser and devtools, other developers. If you build an app with web components, even if you're using one specific helper library to do it, it makes it possible, easy even, to incrementally migrate to other libraries. You can migrate top-down, bottom-up, or even middle-out to other helper libraries and have a continuously working app. You can import and use another web component built with another library without being constrained to just the framework you chose. You can even build an app with all web components, later decide you really don't like them and want to use only a framework and still easily incrementally migrate top down and not break the app. This makes web components the much safer choice for large and long lived projects, and more flexible for projects of all sizes.
onion2k 6y ago
One huge advantage is that you can isolate a web component in its own shadow DOM, which means it has CSS that's independent from the rest of the page. If you're making something for other people to embed in their code, even if you're on the same project, you can save them from breaking it by styling it by mistake. You can also close the shadow DOM to stop people easily inspecting it, but I must admit I haven't actually figured out a reason to do that yet.
- franciscop 6y ago
  That is the same if you use e.g. styled components with React, where every component is self-contained and doesn't leak the styles. The mechanism is different, but the end result is the same, and oh it's a game changer IMHO.

ChrisMarshallNY 6y ago

I love her description of using a dependency-laden component: > Using a custom element from the directory often needs to be preceded by a ritual of npm flugelhorn, import clownshoes, build quux, all completely unapologetically because “here is my truckload of dependencies, yeah, what”. Many steps are even omitted, likely because they are “obvious”. Often, you wade through the maze only to find the component doesn’t work anymore, or is not fit for your purpose. That is so true. The "unapologetically" thing is important. I see this all the time. There's often a fair bit of 'tude, where I am looked at with condescension, for not knowing something "obvious." The fig tree pic is perfect. EDIT: Removed phrase that was possibly corrosive to the narrative.

lazyjeff 6y ago
> BTW: This lady has a Masters from MIT. She def knows her way around things. Moreso than that, Lea is near the end of a Ph.D. in David Karger's group, an expert on CSS, and overall amazing researcher and developer for the web.
- dejavuagain 6y ago
  It's sad to see the sexism in the need to preemptively back her up.
  - taytus 6y ago
    I don't think people are "backing her up" because of sexism. I saw it more as: "She knows her shit. Dear devs, pay attention" And yes, Lea is pretty awesome.
    - xmprt 6y ago
      Yup. All too often I see posts just like this from someone who self taught themselves javascript two years ago and after building a few personal projects, thinks they're an expert on it.
  - ChrisMarshallNY 6y ago

brundolf 6y ago

This post is needlessly snarky, but I don't disagree with the basic premise. Here's what killed web components: lack of native databinding on the web. That's the reason the standard is useless without JS. Any modular, dynamic, modern UI requires databinding, which means it's going to bring in a framework anyway, which means that self-contained widgets are all going to bring in their own frameworks, which means that instead of one large framework on the page you have five or six, all of them stitched together through rickety HTML-attribute APIs and custom value-parsing strategies because HTML attributes are just strings. I fail to grasp why databinding hasn't made it into a web standard yet. The web has a long tradition of feeling out features in the JS world before adopting the successful ones into the platform. jQuery turned into querySelector() and fetch(), CommonJS modules blazed the trail that led to ES modules, etc. And this next paradigm is more than ready to get standardized. Not only would it make the dream of web components possible, it would eliminate the need for a whole lot of the JavaScript out there and even make UIs faster, since reactivity logic would be implemented natively. It's such an obvious, ubiquitous improvement to the web that I can only assume there's some fundamental implementation roadblock I'm missing.

gavinray 6y ago
To be frank, I think in large part this is due to React. I'm not an authority in this area, but I seem to recall that because React uses a synthetic event system, it won't interoperate with Web Component bindings and emitted events. (I know React doesn't work well with Webcomponents, the part I'm unsure of is whether it's specifically due to this). React also doesn't have an easy means of turning React components into Web Components for publishing and consuming. (Preact does though, they put a lot of work into it). Svelte, Vue, and (I believe) Angular can all emit web components. In Vue, you can use the framework's standard data-binding and event capture syntax to interact with custom web components. You wouldn't be able to tell the difference between a Vue component and a Web Component you imported from a package. (I can't speak for Angular, maybe someone could chime in here.) To me, it represents a huge failure on the part of the developer community not to make publishing web components the standard. It seems silly to write a wildly popular component/component-library, and vendor-lock it to a single framework. Why not just publish a web component version as well? https://cli.vuejs.org/guide/build-targets.html#web-component https://cli.vuejs.org/guide/build-targets.html#web-component https://preactjs.com/guide/v10/web-components/ https://preactjs.com/guide/v10/web-components/ https://dev.to/silvio/how-to-create-a-web-components-in-svelte-2g4j https://dev.to/silvio/how-to-create-a-web-components-in-svel... https://angular.io/guide/elements https://angular.io/guide/elements

systemvoltage 6y ago

What is a well designed component given current limitations of HTML spec? There is no way around it. The author makes really good points but offers no solution. Just complains. Would love to know more how we can do this better if there is a way.

atum47 6y ago

Hi, please take a look at my FOS library. I tried to do exactly what the article describes a web component should do - extends HTML providing new elements that can be used without any further "programming". https://github.com/victorqribeiro/fos https://github.com/victorqribeiro/fos

c-smile 6y ago

> Can we fix this? Sure, by returning to basics. Let's assume that Web Component is a DOM element with a code associated with it + lifecycle events. Here is how Components are done in Sciter ( https://sciter.com https://sciter.com ) 1. CSS has got `prototype` property: div.my-component { prototype: MyComponent url(script/components.js); } where MyComponent is the name of class in JS, url (optional) is an URL where this MyComponent can be found. 2. In script that custom component is usually represented by ES6 class (+ decorators) class MyComponent extends Element { // lifecycle event/method componentDidMount() { } // lifecycle event/method componentWillUnmount() { } // component specific methods foo() { } bar() { } // event handlers - decorated functions @event("mousedown") onMouseDown(evt) { } @event("click", "button#submit") onSubmit(evt, button) { } @event("change", "input.name") onNameChange(evt, input) { } } and that's it. Sciter lives with this schema more than 10 years - proven to be very convenient and flexible. Yet simple: one property `prototype` + simple wiring of lifecycle events.

agumonkey 6y ago
after doing a bit of vue I wanted this :)
- c-smile 6y ago
  The good thing about this mechanism is that you just need CSS in order to declare your components. The script will run only if you have elements with matching selectors. So you may have component libraries. Browser will instantiate only used components.
cdata 6y ago
This is literally what a custom element is. Assuming your @event decorator is built upon the EventTarget interface: class MyComponent extends HTMLElement { // lifecycle event/method connectedCallback() {} // lifecycle event/method disconnectedCallback() {} @event("mousedown") onMouseDown(evt) { } @event("click", "button#submit") onSubmit(evt, button) { } @event("change", "input.name") onNameChange(evt, input) { } } That said, custom elements don't cost $310 for an indie license. Instead, they are free and available in every web browser.

sam_goody 6y ago

If there was a way to write JS within the component, I think that they could have taken off - just see how well components are in React, Vue et al. And to get that to happen, all you would need is the ability to refer to `this` within the component. Aside for that, treat the JS within the component as a module, ability to access global vars, but within scope. But instead, you are expected to put the relevant JS in the code that creates the component (in the parent document), which means that reusability and is a pipe dream, and components are really not componentized.

megous 6y ago
You don't need to add anything to the global JS object to create a web component. It can be completely isolated and untouchable from the document's scope, except for registering a html name for the component, so that you can reference it from DOM/HTML.
claytongulick 6y ago
I'm not sure what you mean? All my components are totally encapsulated, and each module is self registering. All I have to do is import "path/some-component.js" and I can then use <some-component> in any markup I want.

aitchnyu 6y ago

TIL of <dialog> which can get by with very little JS. But why is Safari refusing to implement it and why did Firefox put it behind a feature flag for years?

werdnapk 6y ago
I think the reason Firefox hasn't exposed it completely yet is to deal with accessibility issues.

richardanaya 6y ago

I’m personally super excited for lit-html’s future in web components. It feels much simpler.

Animats 6y ago

What's so embarrassing is that the HTML/CSS/Javascript mess does roughly the job Visual Basic did. But worse.

runawaybottle 6y ago
Is that true? If I download Visual Basic right now, could I make a sensible visual app vs React? I’m tempted to see if the truth is really out there.
- devit 6y ago
  No, Visual Basic 6 can only place controls by X/Y position, has no databinding and no VDOM or way to create controls other than placing them in the designer or manually creating and destroying them in code. It's pretty terrible unless you want to make UIs with a fixed size and set of controls.
  - runawaybottle 6y ago
    So then I’ll keep the question open. What is the dopest UI framework across any language with great paradigms, design language, developer experience, and of course, dope results? Right now I’ll say the best iOS/android apps put web to shame. Is Flutter and SwiftUI where we should be looking? The question is specific to semi complex apps (typical crud), not websites.
    - mlvljr 6y ago
      QML might be.
icedchai 6y ago
Yep. Web development is mostly about putting square pegs into round holes, over and over again.

dmix 6y ago

I wasn’t aware that web components were promising advanced interactivity on the web without JS still doing the heavy lifting. I watched those early google talks too and he’s right that doesn’t seem like what they were promising earlier. I think OP confused including components using native HTML style tags would somehow also help solve the giant disparity in what you can accomplish with pure html/css and with JS added on top. The stuff about JS being dependency and framework heavy seem thrown in but is a bit of a different problem and often comes with the territory with any complex JS. If Web components weren't ever really going to promise a new JS free future (other than being a clean way to maintain complex layouts and import isolated/reusable chunks of UI) then those ancillary arguments about the JS ecosystem are a different and somewhat unrelated problem. This is mostly about the others misguided idealism that doesnt sync with the IRL demands on frontend development for interactivity and complex state management vs the very limited offerings of pure HTML.

sergeykish 6y ago

Web Components were crafted for jQuery world. $("#datepicker").datepicker() Custom elements resolves problem we had with XHR HTML response, it instantiates automatically. Problem solved. Widgets were popular and easily broken by CSS, solved by Shadow DOM.

c-smile 6y ago
Shadow DOM does not solve any real life problem. sDOM is spherical horse in a vacuum, my pardon.
- deleted 6y ago
  [deleted]
- c-smile 6y ago
  I'd appreciate any details from anonymous downvoters. Any sample that can be done by sDOM and is not feasible without it and associated machinery?

aazaa 6y ago

> The other day I was looking for a simple, dependency free, tabs component. You know, the canonical example of something that is easy to do with Web Components, the example 50% of tutorials mention. I didn’t even care what it looked like, it was for a testing interface. I just wanted something that is small and works like a normal HTML element. Yet, it proved so hard I ended up writing my own! I was looking for some examples of the better approach the author seems to want, but didn't find them. Found some in the article linked near the bottom: https://www.smashingmagazine.com/2017/02/designing-html-apis/ https://www.smashingmagazine.com/2017/02/designing-html-apis... The author gives an example of a list-type component. It can be initialized in one of two ways: - JS-first: an empty list element is added and a JS initializer populates the children from data - HTML-first: the full markup for the list is added, including children, and the JS works in the background to build the right internal data representation The rest of the article gives specific, actionable advice on building HTML-first components. For this reason, I think it's a better article to start with.

deleted 6y ago
[deleted]

cdata 6y ago

This article is tailored to attract the web components haters. IMO it does not foster a constructive thread of discussion, and some of the critique just as easily applies to the JavaScript ecosystem overall. Web components have some distance to go before they are ideal for all of their envisioned use cases. In particular, I am awaiting declarative shadow roots, declarative custom elements and template instantiation ("data binding"). That said, the work that has been done so far on them is impressive. Web components by and large have survived the needless antagonism they have received from some corners and proved themselves in production scenarios from companies big and small. If you have interacted with a Salesforce application, you have used web components. If you have visited Github, you have used web components. If you watch videos on YouTube, you have used web components. The ground truth is that web components are solving problems and making headway. They only stand to get better as new capabilities begin to land. I'm excited for what the future holds.

ralphc 6y ago
I do work in Salesforce, and I find Lightning Web Components easier to use and understand than the popular frameworks. Yes they require JavaScript, but the alternatives don't?
divbzero 6y ago
> This article is tailored to attract the web components haters. IMO it does not foster a constructive thread of discussion, and some of the critique just as easily applies to the JavaScript ecosystem overall. I think you missed reading to the very end! She concludes on a hopeful note that we can do a better job with Web Components, with a few specific proposals on what a better future could hold.

stevebmark 6y ago

If you work in the Salesforce ecosystem, you know they are doubling down on their use of web components in their "modern" development process. This has lead to a very poorly designed ecosystem. It's infuriating they continue to double down on a system that the rest of us are rightfully abandoning.

ChrisArchitect 6y ago

what the, this was already on here a bunch of times a week ago when it was news https://news.ycombinator.com/item?id=24581439 https://news.ycombinator.com/item?id=24581439 https://news.ycombinator.com/item?id=24587413 https://news.ycombinator.com/item?id=24587413 https://news.ycombinator.com/item?id=24587413 https://news.ycombinator.com/item?id=24587413 and a response post: https://news.ycombinator.com/item?id=24606342 https://news.ycombinator.com/item?id=24606342

earthboundkid 6y ago
I wrote the response. Maybe someone will submit it another three times and then it will finally catch on…
suyash 6y ago
Looks like many people were desperately trying for the post to trend which it din't until this one, not sure if this is breaking any HN guidelines, maybe moderator can chime in.

tarkin2 6y ago

The death of HTML imports killed web components for me. With HTML imports, you would import a HTML file. In that file would be css, html and the js to make the component. Then you’d use HTML as usual in your main file. Finally you could create custom components easily while keeping yourself dealing primarily with HTML. Instead, you were forced to use bizarre js import systems. And at that point you were in JS land. Firefox’s decision not to support HTMLImports in favour of waiting to see what happens with JS killed it.

flowerlad 6y ago
> In that file would be css, html and the js to make the component. You can do that. Here's an example Web Component that contains the css, html and javascript: https://github.com/wisercoder/uibuilder/blob/master/WebComponentsDemo/elements/ZxListEditor.tsx https://github.com/wisercoder/uibuilder/blob/master/WebCompo...
- tarkin2 6y ago
  I'm talking about how you import that into your main HTML file.
tannhaeuser 6y ago
What's the point though to bake that into HTML if you need tons of JavaScript to make it happen anyway? You can just as well use the flexibility of JavaScript to build up component graphs. HTML, or rather SGML, has an established method of syntactically composing fragments using SGML entities that is well integrated into the process of editing HTML using plain text editors, not to speak of extending the vocabulary with new elements and their content models in powerful ways. Introducing elements into markup using script rather than declarative means only serves to complicate parsing, with questionable benefits.
- tarkin2 6y ago
  Because with HTML you would use HTML to structure your elements. Javascript was never designed to structure element s we get things like JSX, to compensate, adding further complexity. HTML Imports was an attempt to keep with the existing platform.

k__ 6y ago

I always saw WCs as the leaves to the root that CSS frameworks already offer. You can drop in Bootstrap and the whole page looks nice, but the moment you want to use the GUI elements that consist of multiple HTML tags, things get ugly. WC would offer a way to merge these into one element. Then you could drop your JS framework of choice in the middle and be done with it. React isn't cool anymore? Well, at least you can take Bootstrap and its WCs with you. I had the impression CSS frameworks had a longer half-life than their JS counterparts anyway. I don't really care about all that HTML module stuff or JS requirements. Sure would be cool if things were different, but from a practical POV it doesn't seem THAT important to me.

wnevets 6y ago

>who revel in complex APIs, overengineered build processes and dependency graphs that look like the roots of a banyan tree. I keep thinking I'm just being old and cranky whenever I go through "modern" projects and my eyes cross at the overengineering and complexly. Does this mean other people are starting to see this aswell?

cletusw 6y ago

> "I just wanted something that is small and works like a normal HTML element" My first stop when looking for a web component is always https://component.kitchen/elix https://component.kitchen/elix because of their commitment to the Gold Standard (https://github.com/webcomponents/gold-standard/wiki https://github.com/webcomponents/gold-standard/wiki), which is basically to imitate native elements wherever possible.

shams93 6y ago

I'm using lit-element for a project it's much more usable than writing components from scratch. The growth of complexity on the client side is really quite staggering and thanks to browser stagnation I doubt it will get better any time soon. A platform that should be low code is really maximum over code!

divbzero 6y ago

It’s hard to tell from the comments here, but the author actually ends her article on a hopeful note and offers concrete proposals on how we could fix the shortcomings of Web Components and fulfill its promise: – No dependencies beyond one <script> tag – Syntax and API in line with conventions of built-in HTML elements – Accessible by default via ARIA – Themeable via ::part(), selective inheritance, and custom properties – Only one component of each type in the directory Which proposals would be beneficial is up for debate (esp. the last one IMO) but they’re worth highlighting and discussing.

dannymoerkerke 6y ago

I wrote a response to this article, Lea was kind enough to respond to it by the way: https://medium.com/swlh/the-failed-criticism-of-web-components-ee94380f3552?source=friends_link&sk=406daa6d2bb0a0e563f501bc8a99c4f5 https://medium.com/swlh/the-failed-criticism-of-web-componen...

gorpomon 6y ago

> I’m not sure if this is a design issue, or a documentation issue. Perhaps for many of these web components, there are easier ways to use them. Perhaps there are vanilla web components out there that I just can’t find. Perhaps I’m looking in the wrong place and there is another directory somewhere with different goals and a different target audience. I did a deep dive into web components for a client recently. I tried to see if we could translate an entire Angular component library into Web Components we could share with the entire org and they could use them regardless of wrapping framework. I ran into the same discoverability issues the author did. After finding a new package, I'd spend some time with it, hit its limitations and then by magically finding the right article I'd find an entirely different project. In total I ended up sampling: plain JS web components, Svelte, Stencil, lit-element, Angular -> WC, and probably a few more. None ever really seemed to work, and the jank I encountered in them all via slotting seemed to preclude using them-- I could never get rid of a very noticeable Flash of Un-styled Content. The end goal the author talks about sounds really nice, a simple script tag to get more HTML. I think in practice though, that end goal isn't so rosy. If your web page is just web components + html/css then perhaps it's performant enough . But if you're working on a truly massive application (think design collaboration tools, etc), then probably you'll just want to keep it all in the framework, you're already paying a size penalty, might as well not pay a complexity penalty as well. If we can get a simple, useful, and popular web component library as an accepted standard, I think it will be useful to a certain sliver of developer who needs more power than HTML/CSS but doesn't want to learn lots of JS, but I think that will be a sliver of developers, not many. For the rest, I can imagine single-file-per-component compilation based frameworks like Svelte will obviate the need for web components. Remember, html is for the authors, not the consumers of web pages, and if your app is suitably large enough you'll probably need complexity managed in several ways (global state, UI components, data fetching, etc) and in that sense a framework will likely serve you better.

int_19h 6y ago

For the past 10 years or so, every time I read one of those articles on the state of modern web development, I'm thankful that I've dodged that bullet. Coming from the desktop world, it feels like the amount of complexity exposed to the end users of all those frameworks is quite insane compared to what they're getting from them.