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

91–100 of 247 posts

Re: HTML Web Components

#91

Post by [deleted] »

jtcasper wrote: post #42
dmix wrote: post #32

Earlier quoted context omitted.

Most people using react aren't building SPAs. Vue/React can be used the same way as jquery, which is to add enhanced UI functionality that server-side HTML views simply can't offer. The best example is a multi-select box, or a searchable select box with autocomplete (what W3 calls the combobox pattern https://www.w3.org/WAI/ARIA/apg/patterns/combobox/ ) which in jquery was usually via https://select2.org/ For example…

The element with a text input field is an HTML native typeahead, which works great with SSR or you could wire up the datalist client side with an XHR creating the datalist. You maybe don't get full control over the rendering style of it, but it's a still significantly more usable than the Angular Material autocompletes.

[deleted]

Re: HTML Web Components

#92

Post by willio58 »

ivanjermakov wrote: post #88

> But the unique power of web components (in the browser) is that they can render before JavaScript. React components cannot do this — full stop. Umm, that's why SSR was created?

Web components are standardized by the web consortium. They are the way web browsers have agreed components should work. They have value inherently and don’t necessarily mean you can’t use react, in fact they can be used together very well especially for things like framework agnostic design systems. Basically, web components have more holding power inherently because they are browser native. React and SSR is just a great way to augment that.

While I write react daily and love it, I think it’s important to realize no methodology today will have any real importance or meaning 100 years from now. It’s all a means to an end and frameworks and web components are just different means.

In 2123, people will glance at a paragraph about react and move on to the next topic in programming history.

Re: HTML Web Components

#93

Post by jdmg94 »

web components are the quantum realm of CSS. What you know as normal might not work when you're trying to write style customization. My org has multiple teams working with different stacks, so at one point someone decided to write our component library using web components. Everyone hated it and we're now moving away from it.

Re: HTML Web Components

#94

Post by divbzero »

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…

Could we shorten the catchy name further? Call them “HTML components”.

Re: HTML Web Components

#95

Post by webstrand »

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.

What's the advantage of this over just using divs for everything, though? If this used shadow dom, I could understand. But custom elements don't even behave like blocks by default. Namespace collisions with custom components are just as bad as class collisions, if not worse since you can't `.myns.button`. Is it just the `connectedCallback` versus some manual method of wiring up elements to their javascript behaviors?

Re: HTML Web Components

#96

Post by Ambolia »

sylware wrote: post #89
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 "…

The core of the web only need basic HTML with closing tags (and properly shaped singleton element/tags) with the basic grammar (from the specs), utf8 encoded, no script. It is enough for a bazillion of online services, that without requiring a beyond insanely complex and massive web engine from Big Tech. basic HTML forms can do wonders. Of course, you can have a full blown Big Tech web app, but don't forget to have a…

If you are only doing web as documents with links. As soon as you use any Forms and error back-and-forth you have to either patch over the web stardards, or annoy your users with sub-par functionality.

Re: HTML Web Components

#97

Post by CharlesW »

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.

I understand that argument, but Lit isn't a web standard, and it's an esoteric choice compared to Vue, which works great with custom elements.

Re: HTML Web Components

#98

Post by Joeri »

hu3 wrote: post #59
nightski wrote: post #17

Earlier quoted context omitted.

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…

Preact requires a build step otherwise you don't get JSX and you have to build applications a la mithril.js mode: > const app = h('h1', null, 'Hello World!'); With Web Components no build step is required and you're still able to intermix HTML with JS just like JSX. See the code below this section: https://github.com/kennyfrc/cami.js#key-concepts--api

You can use the htm library as a pure client-side jsx: https://github.com/developit/htm

It is not completely the same, but far better than that h function madness.

Re: HTML Web Components

#99

Post by Osmose »

I think this article is emphasizing custom tags / code reuse as the primary feature of React, which isn't really the case? The whole reason React was a game changer was because it eliminated (as much as possible, anyway) the invisible extra state stored in the DOM from your app and made its rendering declarative, which greatly reduces how much state you have to keep in your head when reading and reasoning about your app UI logic.

Web components don't address this on their own, which is why a lot of libraries still exist that build on top of them.

Re: HTML Web Components

#100

Post by [deleted] »

hu3 wrote: post #59
nightski wrote: post #17

Earlier quoted context omitted.

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…

Preact requires a build step otherwise you don't get JSX and you have to build applications a la mithril.js mode: > const app = h('h1', null, 'Hello World!'); With Web Components no build step is required and you're still able to intermix HTML with JS just like JSX. See the code below this section: https://github.com/kennyfrc/cami.js#key-concepts--api

[deleted]
Post reply on HN