The Failed Promise of Web Components • Hacker News Board

Re: The Failed Promise of Web Components

#61

Post by jeroenhd » Wed, Sep 30, 2020, 7:17 PM UTC

brundolf wrote: post #20

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 i…

I'm a strong proponent of separation of duties on the web (style and visuals in CSS, layout in HTML, anything interactive in JS). Enabling data binding in HTML would only serve to blur those lines.

With some minimal JS, you can update each web component already. Is writing nameField.innerText = response.name really that difficult? What problem does it solve to make a standard for it? As for (de)serialization, JS has built-in support for JSON and XML. HTML attributes are everything but rickety in my opinion, as any decent parser will allow you to access them as if they are a normal dictionary. Put JSON in them if you really want to encode complex data in attributes, although you probably shouldn't.

I strongly believe the abhorrent overuse of React and other such libraries on the web is the sole reason our computers have gotten hundreds of times faster but the web is only slightly as quick. I don't see a place in web standards for a React-style functional design because of the specific rules each of these libraries have.

Re: The Failed Promise of Web Components

#62

Post by brundolf » Wed, Sep 30, 2020, 7:19 PM UTC

MaxBarraclough wrote: post #56

brundolf wrote: post #20

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 i…

Related to this, it annoys me that Polymer is sometimes described as not a framework , as if it's just a set of polyfills/shims. Of course it's a framework, it provides a data-binding system that is incompatible with other frameworks, and which isn't simply a polyfill.

Exactly. The best piece of supporting evidence for my original point is that even Google themselves, in all of their Web Components marketing, used Polymer for everything. To the point where some people didn't really even understand the distinction between the two! That was a giant admission that this stuff is useless without databinding.

Re: The Failed Promise of Web Components

#63

Post by brundolf » Wed, Sep 30, 2020, 7:22 PM UTC

rusk wrote: post #55

brundolf wrote: post #20

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 i…

We had XUL at one stage which is I think what you’re talking about. It just never took off. I think you’re pointing out that the premise itself is flawed given the clunky nature of html, which could be why ...

I'm pointing out that HTML as it exists right now doesn't solve the big problems around this. I still think it could be extended to do so, but what's important here is that it hasn't been.

Re: The Failed Promise of Web Components

#64

Post by tashoecraft » Wed, Sep 30, 2020, 7:24 PM UTC

ChrisMarshallNY wrote: post #14

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 w…

This is everywhere in programming. Just trying to setup vim involved learning an insane amount of information that is scatter documented with every person recommending different ways to accomplish the same task. You feel stupid for not knowing one tiny part.

Re: The Failed Promise of Web Components

#65

Post by lowkeyokay » Wed, Sep 30, 2020, 7:26 PM UTC

gavinray wrote: post #57

brundolf wrote: post #36

Earlier quoted context omitted.

> To me, it represents a huge failure on the part of the developer community not to make publishing web components the standard The problem is that if you're writing a Vue app, and you import a web component that was written in Preact, you're now loading both Vue and Preact onto your page. That means your app will take twice as long to load. That is a huge downside to weigh against the inconvenience of having to find…

The point about the shipping the framework as a dependency is a good one. In the grand scheme of things it's not the end of the world but shipping multiple framework runtimes is definitely not ideal. Svelte is the outlier here, where the end-product is fully compiled to standard API's without a runtime. Maybe we'll see more frameworks adopt this approach in the future.

StencilJS does this too. It also has a wrapper to create React components. I really recommend it

Re: The Failed Promise of Web Components

#66

Post by pfraze » Wed, Sep 30, 2020, 7:31 PM UTC

hinkley wrote: post #13

pfraze wrote: post #6

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 AP…

Would it help if we made a standard for communication between web components, so whatever tools they use internally, you can wire them into your code or to each other? Web components are abstraction boundaries, and you have to define boundaries carefully or you still end up with a big ball of mud, now with extra layers of indirection to make your life even worse.

Yes, but I'm unsure what a well-designed execution of that would look like.

Re: The Failed Promise of Web Components

#67

Post by c-smile » Wed, Sep 30, 2020, 7:32 PM UTC

> 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 )

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.

Re: The Failed Promise of Web Components

#68

Post by sam_goody » Wed, Sep 30, 2020, 7:33 PM UTC

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.

Re: The Failed Promise of Web Components

#69

Post by gavinray » Wed, Sep 30, 2020, 7:34 PM UTC

lowkeyokay wrote: post #65

gavinray wrote: post #57

Earlier quoted context omitted.

The point about the shipping the framework as a dependency is a good one. In the grand scheme of things it's not the end of the world but shipping multiple framework runtimes is definitely not ideal. Svelte is the outlier here, where the end-product is fully compiled to standard API's without a runtime. Maybe we'll see more frameworks adopt this approach in the future.

StencilJS does this too. It also has a wrapper to create React components. I really recommend it

I completely forgot about Stencil from the Ionic team.

Definitely agreed. If you want an example of Web Components working cross-framework, look at Ionic and Stencil tbh.

Re: The Failed Promise of Web Components

#70

Post by pier25 » Wed, Sep 30, 2020, 7:37 PM UTC

brundolf wrote: post #20

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 i…

Totally agree with you. I'll add to that a lack of native reactivity.

The observable proposal has existed for years. It's still in stage 1 and was last presented in to the TC39 in 2017 [1].

There seems to be an almost total disconnect between the needs of web developers and what the TC39 is working on. Data binding and reactivity are two important points, but also the need of optional static types which should be obvious by looking at the meteoric success of TypeScript. This is nothing new, it has been discussed since ES4 times 10+ years ago.

[1] https://github.com/tc39/proposals/blob/master/stage-1-propos...