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

71–80 of 235 posts

Re: The Failed Promise of Web Components

#71

Post by goatlover »

franciscop wrote: post #32
onion2k wrote: post #26

Earlier quoted context omitted.

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

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.

But why should developers have to use a framework like React to do something the browser could provide for them? Not everyone is writing a JS application. Some just need to add some custom HTML, CSS and little bit of JS.

Re: The Failed Promise of Web Components

#72

Post by auggierose »

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…

Care to explain for what reasons you are a strong proponent of this? Is it religious?

Re: The Failed Promise of Web Components

#73

Post by goatlover »

elcritch wrote: post #47
spankalee wrote: post #17

Earlier quoted context omitted.

The JS module system is actually better suited for this. And ultimately HTML imports don't solve any of the cross-package import issues that JS modules are still trying to solve.

Perhaps, but as a web developer html imports let me pull in and use web-components without writing any Javascript. Give an HTML editor to a 15 year old, some links to a decent web-component library and they're off to the races without mastering JS.

Exactly this. Why should JS be required for something the browser could handle when we're talking about HTML?

Re: The Failed Promise of Web Components

#74

Post by pier25 »

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…

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

If browsers provided data binding and reactivity out of the box, frameworks and applications would be much faster and lighter.

Re: The Failed Promise of Web Components

#75

Post by nwienert »

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…

Web Components are a total mess and impossible to build anything of significance with. I can't even imagine how anyone would get anything done with them. It's like an Angular developer, an artist, and a mid-2010s neural net walked into a bar and sketched out a spec by taking shots and passing it clockwise.

Separation of languages is a silly way to separate things. You're building components: logic, structure and style are coupled. SwiftUI adopts the React model, and it succeeds because of it. One can build an app in React/SwiftUI in about 1/2 the time spent "separating concerns", and build systems still extract things out to be clean and performant, there's no sacrifice being made there. CSS is a shitshow and a total mess especially on large teams.

React has nothing to do with how performant an app is and if anything speeds them up compared to anything previously, you may be confusing the power and ease with which it enables development as getting some drunk on building larger apps, but that's only because of how effective it is. Twitter is a good example, great performance. It's way more about the team than the tool, though certainly it will get easier over time to have the defaults be better at optimization for smaller teams who are ambitious.

Most of the super bloated websites I see are basically news sites and other less-techy sites that are stuffed with ad tracking and have no tree shaking. The majority of React apps build with Webpack which supports tree shaking and lazy loading out of the box, plus React makes it possible to pre-render your entire app and deliver it as HTML that hydrates.

Re: The Failed Promise of Web Components

#77

Post by jeroenhd »

pier25 wrote: post #74
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…

> 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. If browsers provided data binding and reactivity out of the box, frameworks and applications would be much faster and lighter.

Web browsers provide many features out of the box but frameworks rarely use them. Web components are one thing; HTML templates are another. Streaming video is being decoded by Javascript even though every browser supports H.264, input elements such as calendar controls are rewritten, animations are done in JS instead of smooth CSS transitions, drag and drop support is manually rewritten in JS...

Whenever a feature gets added to standard HTML, web frameworks and "polyfills" keep implementing their own versions because the standards don't fit them and they don't want to rewrite (or keep their own implementation as a mere fallback).

Even if a data binding framework would be standardized today, it would take years for browsers to catch up and gain critical mass. There'd only be more polyfills and Javascript to help support people running IE11 or whatever.

I'm glad many JS features have been implemented natively in HTML5, but this specific case feels overkill to me. HTML templates have been introduced and then ignored by frameworks already and I doubt any framework would switch over to a new data binding API if it became a standard today.

Re: The Failed Promise of Web Components

#78

Post by nawitus »

nwienert wrote: post #75
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…

Web Components are a total mess and impossible to build anything of significance with. I can't even imagine how anyone would get anything done with them. It's like an Angular developer, an artist, and a mid-2010s neural net walked into a bar and sketched out a spec by taking shots and passing it clockwise. Separation of languages is a silly way to separate things. You're building components : logic, structure and sty…

I've built several complex apps (which I suppose are "of significance") with web components. I just used a framework (Polymer in my case) to abstract away the web components API.

Re: The Failed Promise of Web Components

#79

Post by SahAssar »

pier25 wrote: post #70
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 obv…

Isn't observable superseded by Proxy?

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

Re: The Failed Promise of Web Components

#80

Post by coder543 »

robocat wrote: post #59
coder543 wrote: post #40

Earlier quoted context omitted.

My hot take: hamburger menus are a really bad UX paradigm in almost all cases, and bottom tab bars are much better. So, I disagree entirely: iOS can easily support fantastic HTML5 mobile apps... if push notifications ever become available. From what I remember, Google started switching to bottom tab bars a couple of years ago, even on Android. But, when you have a bunch of features, it's much easier on the developer…

> bottom tab bars are much better The last time I looked they were incredibly fragile to implement on mobile device browsers. Mobile Safari had borkage: rotation or tab addition/deletion changing the page height such that you occasionally lose the bottom bar; input focus loses the bottom bar or leaves the bottom bar occluding elements (position sticky doesn’t recalc when page scrolls). Problems with strange interacti…

To be clear, I'm talking about HTML5 mobile apps. Apps that you add to your home screen from the web, where none of the Safari chrome is visible to interfere with things. You rarely encounter this kind of thing precisely because notifications aren't supported, as I've been saying. Chat apps? Most users want notifications. Forum apps (like Reddit)? Most users want notifications. Calendar apps? Shopping apps? Podcast apps? Weather apps? Almost every user wants to have the option of notifications for these apps. Video games? Most companies want notifications to drive user re-engagement... even if a lot of users don't allow games to spam them with notifications. Virtually every kind of app benefits from or completely requires being able to alert you that things have happened.

There's very little reason for good tools to exist right now, when notifications don't, and this seems intentional on Apple's part. Great tooling could definitely exist for HTML5 mobile apps to make it a good experience to build great apps that way... except for the lack of notification support on iOS. Historically, the Google Play Store is so lax about things that there's no reason not to just submit apps there. You don't even have to give Google a 30% cut on a lot of things, if you provide your own payment mechanisms. So, making HTML5 mobile apps for an Android audience has never been that appealing. But, that might be changing soon. On iOS, there have always been a lot of motivating reasons for companies to release apps as HTML5 Mobile Apps, but the lack of notifications just completely stops the idea flat.

For HTML5 mobile websites, a hamburger menu is often an unfortunate reality, but I think having the most frequently used links always clickable at the top of the page is better than stuffing absolutely everything into the hamburger menu. HN does a great job with this.

Post reply on HN