Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Failed Promise of Web Components

lea.verou.me

Post reply on HN
Print view View original

91–100 of 235 posts

Re: The Failed Promise of Web Components

#91

Post by brundolf »

jeroenhd wrote: post #61
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…

> anything interactive in JS

Except this barrier has never existed. Every HTML input is interactive: text fields, checkboxes, radio buttons. They not only remember their value, but your cursor position within them and the segment of text you've highlighted. The browser knows how far each scrollable element is scrolled, which element is in focus as you tab through the page. Forms have validation state, and can be interacted with to send an HTTP request. These days you can even do autocomplete with nothing but HTML: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...

The magic of HTML has never been about static layout, but about having a declarative language for building out an interface (not just a static view, but an interface). This idea that it should be nothing but a dumb view-layer is a new one, popularized by the very frameworks you're railing against. Data binding is a way to stay in that declarative space, while dramatically expanding what use-cases can be covered within it. JavaScript (in the browser) was, and always should have remained, a trapdoor for working around HTML's shortcomings. It's a Turing-complete language for doing things that can't be done any other way. Anything that can be neatly siphoned off from that more complex imperative world, should be. For the sake of complexity, for the sake of accessibility, for the sake of performance, and for the sake of compatibility.

Re: The Failed Promise of Web Components

#93

Post by pier25 »

SahAssar wrote: post #79
pier25 wrote: post #70

Earlier quoted context omitted.

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

Isn't observable superseded by Proxy? Most (all?) of what is enabled by observable should be possible with Proxy, right?

Good point although Proxy is pretty low level (for the JS world) and you still need to implement a lot of stuff yourself.

I would have expected something more akin to RXJS, MobX, or even the Svelte reactivity system.

Re: The Failed Promise of Web Components

#94

Post by moron4hire »

jeroenhd wrote: post #61
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…

The major desktop UI toolkits don't agree. They all have data-binding for controls.

And we still separate concerns on the desktop. The model/view/viewmodel paradigm is pretty good.

Re: The Failed Promise of Web Components

#95

Post by renke1 »

SahAssar wrote: post #79
pier25 wrote: post #70

Earlier quoted context omitted.

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

Isn't observable superseded by Proxy? Most (all?) of what is enabled by observable should be possible with Proxy, right?

I guess Observable as in RxJS Observable (or the likes). Similar to Promise which is now part of the standard.

Re: The Failed Promise of Web Components

#96

Post by dmix »

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.

Re: The Failed Promise of Web Components

#97

Post by agumonkey »

c-smile wrote: post #67

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

after doing a bit of vue I wanted this :)

Re: The Failed Promise of Web Components

#98

Post by stickfigure »

brundolf wrote: post #91
jeroenhd wrote: post #61

Earlier quoted context omitted.

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…

> anything interactive in JS Except this barrier has never existed. Every HTML input is interactive: text fields, checkboxes, radio buttons. They not only remember their value, but your cursor position within them and the segment of text you've highlighted. The browser knows how far each scrollable element is scrolled, which element is in focus as you tab through the page. Forms have validation state, and can be inte…

I built lots of HTML form UIs in the early 2000s. They were garbage. Many modern web UIs are on par with native apps, so much so that folks are now using web technologies to build actual native apps.

With 150 years of evolution (at current W3C standards pace) you might get an HTML spec that is capable of expressing the behavior that users expect from present-day applications. Until then we have React et al.

Re: The Failed Promise of Web Components

#99

Post by systemvoltage »

ChrisMarshallNY wrote: post #44
systemvoltage wrote: post #43

Earlier quoted context omitted.

> BTW: This lady has a Masters from MIT. She def knows her way around things. I agree with all of what you said until you bought up this unnecessary credential wrapper. It leaves a bad taste - statements like this. I don't know why. Going to MIT is doesn't make you an automatic genius nor does it mean that they know their way around things. It bothers me.

Cool. I'll remove it. Not necessary for the narrative.

Thanks for being receptive.

Re: The Failed Promise of Web Components

#100

Post by spankalee »

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…

> custom value-parsing strategies because HTML attributes are just strings

HTMLElement have properties too, and custom elements can accept any non-string data via properties instead of attributes.

Post reply on HN