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

HTML Web Components

blog.jim-nielsen.com

Post reply on HN
Print view View original

111–120 of 247 posts

Re: HTML Web Components

#111

Post by troupo »

mock-possum wrote: post #44
superkuh wrote: post #8

It's a nice idea and I'm glad we can expand the language to differentiate between html web components and javascript web components. That's important because the vast majority of use of web components are in the form of javascript web components. The only time I've ever seen HTML web components are on blog posts talking about how you can use web components. Never on an actual website about something besides web compo…

I’ve made a couple of big SPAs that use Lit to manage views. I can’t link you to them here without blowing my cover, but honestly I love working with web components, and being able to do it natively rather than propped up by a mound of JavaScript feels good.

You're not doing it natively. You're using a framework replete with its own custom DSL, multiple workarounds for issues like SVGs, its own data binding system etc.

It's just as native as any other framework under the sun.

Re: HTML Web Components

#112

Post by recursive »

no_wizard wrote: post #74
recursive wrote: post #69

Earlier quoted context omitted.

In some cases, react seems to go out of its way to make the built-in functionality harder to access. For instance, if you assign "onchange" to an , react will give you the "input" event, not the "change" event. (Actually, it gives a neither. It gives you a "synthetic" event that's closer to input than change) What if you know what you're doing, and you actually wanted "change"? You have to use an element ref an attac…

You can access the `nativeEvent` property on the event object[0] if you prefer [0]: https://react.dev/reference/react-dom/components/common#reac...

Doesn't solve this problem. "change" fires at different times from "input". `nativeEvent` is useful if you want the real event data object for the event that actually fired. In this case, it's a whole other event.

Re: HTML Web Components

#113

Post by troupo »

superkuh wrote: post #8

It's a nice idea and I'm glad we can expand the language to differentiate between html web components and javascript web components. That's important because the vast majority of use of web components are in the form of javascript web components. The only time I've ever seen HTML web components are on blog posts talking about how you can use web components. Never on an actual website about something besides web compo…

> but reality is stacked against HTML web components.

Because they don't exist. "HTML web components" are just HTML, and you don't need components for them.

Web Components are useless without Javascript.

Re: HTML Web Components

#114

Post by recursive »

11235813213455 wrote: post #79
recursive wrote: post #69

Earlier quoted context omitted.

In some cases, react seems to go out of its way to make the built-in functionality harder to access. For instance, if you assign "onchange" to an , react will give you the "input" event, not the "change" event. (Actually, it gives a neither. It gives you a "synthetic" event that's closer to input than change) What if you know what you're doing, and you actually wanted "change"? You have to use an element ref an attac…

it's a well known thing in react (preact does it well https://preactjs.com/guide/v10/differences-to-react/#use-oni... ), and probaly a design mistake on their side (now too late to change), I can't think of other cases like that

They could still expose a `nativeChange` event without breaking backward compatibility.

Re: HTML Web Components

#115

Post by Xeamek »

joshstrange wrote: post #49

I was interested to see this article explain what `user-avatar` actually did/provided but it never did. Does it just have styles in it? If so why wouldn't I just use css classes? I also think having a `user-avatar` take a `src` prop makes way more sense than having to add an `img` tag inside it everywhere I use it. In that case what am I saving? What is reusable? Vue/React/Angular don't seem like they are trying to "…

>Every alternative to the big frameworks (looking at you htmlx) feel like minor syntaxic sugar for jQuery and friends

True

>which feels like a massive step backwards and completely the wrong choice for building a web app.

Why?

I mean, I'd agree if by 'web-app' you mean something like google-sheets.

But I believe this whole "anti-react" movement isn't talking about such usecases, but rather against defaulting frameworks and building using them 'from the ground up', where trully all the website actually need is the "sparkling of interactivity on top"

Re: HTML Web Components

#116

Post by joshstrange »

boredtofears wrote: post #84
joshstrange wrote: post #49

I was interested to see this article explain what `user-avatar` actually did/provided but it never did. Does it just have styles in it? If so why wouldn't I just use css classes? I also think having a `user-avatar` take a `src` prop makes way more sense than having to add an `img` tag inside it everywhere I use it. In that case what am I saving? What is reusable? Vue/React/Angular don't seem like they are trying to "…

I think the Eric Meyer post demonstrates the intention of that much better: https://meyerweb.com/eric/thoughts/2023/11/01/blinded-by-the... The benefit boils down to progressive enhancement: because an img tag has built in behavior you simply rely on default rendering behavior and provide "augmentation" as needed via your web component.

That still doesn't click for me. Why wouldn't you make the label/slider part of the component itself. It feels like you have the worst of both worlds. You more or less need/expect it to always wrap those elements but nothing enforces that so this seems very brittle to me, not to mention verbose.

They mention not wanting to pass though all those props:
We will ignore the last 2 since those are required anyway. How is `type="range"` not the default that you would just set, no attribute/prop needed? Then min/max/step/value all feel like things you could have defaults for and then, yes, pass them through. In forms I'm always pushing towards consistency, I don't want to make it easy to just set random attributes on the underlying element, it needs to be deliberate.

I can believe I'm just missing something but Web Components just seem like extra work with very little gain.

Re: HTML Web Components

#117

Post by troupo »

drawkbox wrote: post #68
CharlesW wrote: post #65

Earlier quoted context omitted.

But if you introduce an open-source dependency to make web components usable, why not use a popular, complementary ecosystem like Vue? https://vuejs.org/guide/extras/web-components.html

Staying closer to web standards is always best for maintainability and portability. I personally like custom direct standards but that doesn't always work in a team for some reason today. There will always be less dependencies in a straight standards solution, that makes for better maintainability and opsec. I also think it is better for web developers to know standards over just abstractions, it makes for better dev…

> Staying closer to web standards is always best for maintainability and portability.

That's what you get if you chose literally anything but web components. Because web components are really bad at using and playing nice with web standards: https://threadreaderapp.com/thread/1717580502280867847

They need dozens of new web standards to fix their self-inflicted wounds and to work with the browser in a way that everyone else is already working

> Additionally, web standards like Web Components/templates/custom elements will always be faster at browser level.

[citation needed]

The 2010-era design choices that web components enshrined hinder a lot of optimizations that modern frameworks are doing.

There are reasons why almost none of the modern frameworks use web components as the foundation. Including those who originally used their design or whose authors were bullish on them (Vue, Svelte, Solid).

IIRC even Angular beats Lit in benchmarks now.

Re: HTML Web Components

#118

Post by naasking »

nightski wrote: post #17
simonw wrote: post #2

Also read these articles for more on the idea of "HTML Web Components": https://meyerweb.com/eric/thoughts/2023/11/01/blinded-by-the... - "So there you have it: a few thousand words on my journey through coming to understand and work with these fully-Light-DOM web components, otherwise known as custom elements. Now all they need is a catchy name, so we can draw more people to the Light Side of the Web." https://adact…

I just don't get the point. They are cumbersome to use, so now you need a lightweight framework on top of the built in framework such as Lit (which btw is larger than Preact). Then they solve none of the real problems like state management, routing, etc... so you'll likely need to pull in more. Sure you can get re-usable components. But are you going to pull in a re-usable web component that might use say Vue underne…

State management is only a problem if you have client-side state that isn't HTML state. Lots of web apps don't fit that mould.

Re: HTML Web Components

#119

Post by tolmasky »

I can't tell if people who champion web components don't understand why the React model took off, or purposefully pretend to not know why since web components don't really solve most of the things people using React care about, and thus look bad in comparison.

This article is a good example of this. For starters, the "one shell component" thing is kind of a red herring. There's plenty of React components that interact with children, and you can clearly make web components that also "hide all the details". So this seems to be more of a "general" good practice they want to encourage, than anything specifically tied to React or Web Components in particular.

Critically however, the whole idea of "hey, web components still look good before JavaScript!" is either intentionally obtuse or really misses the point of React -- React can have a better non-JavaScript initial render, thanks to SSR, which is significantly harder to do with Web Components. I don't really care if "falls back" to some lame Web 1.0 rendering if my SSR-ed UserAvatar looks identical to the fully "active" component on first paint before any JavaScript runs. That is one of the main selling points of React and React-like systems today. You can't just ignore that completely and expect to convince anyone who's currently using that sort of system. But I understand why they don't address it, since the only real answers involve using some sort of build system with Web Components, which they've also decided to say are the worst thing ever. So their only choice is to compare non-SSR Web Components to non-SSR React Components. And, I dunno, maybe they're better than the way we did things 8 years ago when that was the case? I'd have to think hard about that purely academic question.

The funny thing is that these are often the same people that would push for as little JavaScript as possible, and yet Web Components are fundamentally tied to JavaScript. Whereas React-style components can actually generate fully static JavaScript-free pages if you want to. This sort of situation springs up a lot: Web Components go on and on about not being "shells single components", and yet React-style components make it so much easier to deal with children. You aren't forced into the ugly slot system which immediately removes the "illusion" of it being a "real" HTML component, and is easier to deal with in the catch-all case too. Not to get into another huge differentiation, but I also personally prefer a more "functional" approach of writing a single render function vs. dealing with a bunch of lifetime callbacks to track the changing states of attributes and children.

Re: HTML Web Components

#120

Post by kansface »

nightski wrote: post #17
simonw wrote: post #2

Also read these articles for more on the idea of "HTML Web Components": https://meyerweb.com/eric/thoughts/2023/11/01/blinded-by-the... - "So there you have it: a few thousand words on my journey through coming to understand and work with these fully-Light-DOM web components, otherwise known as custom elements. Now all they need is a catchy name, so we can draw more people to the Light Side of the Web." https://adact…

I just don't get the point. They are cumbersome to use, so now you need a lightweight framework on top of the built in framework such as Lit (which btw is larger than Preact). Then they solve none of the real problems like state management, routing, etc... so you'll likely need to pull in more. Sure you can get re-usable components. But are you going to pull in a re-usable web component that might use say Vue underne…

Web components are only useful IMO in the case of a large enterprise which wants to systematically and consistently style a large number of applications written by different divisions in different frameworks in different languages targeting different clients.
Post reply on HN