HTML Web Components • Hacker News Board

Re: HTML Web Components

#31

Post by gen220 » Mon, Nov 13, 2023, 5:04 PM UTC

hu3 wrote: post #15

I think I've finally seen the light when it comes to Web Components: https://github.com/kennyfrc/cami.js > No Build Steps, No Client-Side Router, No JSX, No Shadow DOM. We want you to build an MPA, with mainly HTML/CSS, and return HTML responses instead of JSON. Then add interactivity as needed. > Declarative templates with lit-html. Supports event handling, attribute binding, composability, caching, and expressions.

Have you tried HTMX before? Seems strongly aligned, with HTMX perhaps having a bigger community. Curious if you have, and found it lacking in some way.

Re: HTML Web Components

#32

Post by dmix » Mon, Nov 13, 2023, 5:04 PM UTC

ohwellhere wrote: post #25

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…

I think there's a lot of value for classic server-side web applications rather than SPAs. That handles routing, state, etc. I'm personally a fan and hope that the server-based application renaissance happens as some predict.

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, on my company website there's a timezone select box with 151 options. Asking a user to scroll through 100+ options is a big ask vs typing a few characters and hitting enter. There really is no static server-side way to solve this problem (I tried hard to think of one)... without creating a multi-page Wizard for what should be a single field on a larger form.

If you're building a SaaS product there are many UI requirements that demand high-interactivity and and there's really no better mainstream solution atm than static-first sites with small "islands" of React/Vue/etc components (ideally with hydration).

People still abuse React/Vue of course and the trend is 100% moving back to "mostly static" rather than slow SPAs but IMO JS-powered components are not never going away unless browsers start offering a broad selection of built-in complex web components like comboboxes, datepickers, tooltips, etc.

Re: HTML Web Components

#33

Post by singularity2001 » Mon, Nov 13, 2023, 5:05 PM UTC

It will be nice if/when these components can also be defined within HTML

Re: HTML Web Components

#34

Post by rsolva » Mon, Nov 13, 2023, 5:06 PM UTC

> My takeaway is: if you’re looking for longevity, opt for a technical approach of augmentation and enhancement over replacement.

This is my experience too, and this philosophy have made my web projects last a long time with minimal maintenance and dependencies.

Re: HTML Web Components

#35

Post by _joel » Mon, Nov 13, 2023, 5:07 PM UTC

Am I misreading this or is it what https://htmx.org/ provides?

Re: HTML Web Components

#36

Post by willsmith72 » Mon, Nov 13, 2023, 5:10 PM UTC

> But the unique power of web components (in the browser) is that they can render before JavaScript. React components cannot do this — full stop.

Unless you... server-side render them. Then your definition of "render" needs to change

Re: HTML Web Components

#37

Post by sesm » Mon, Nov 13, 2023, 5:12 PM UTC

>

> https://example.com/path/to/img.jpg" alt="..." />

>

I thought the standard way to do it is:

https://example.com/path/to/img.jpg" alt="..." />

Re: HTML Web Components

#38

Post by account-5 » Mon, Nov 13, 2023, 5:13 PM UTC

With the massive caveat that I'm not a web developer or react developer, doesn't this stuff just look XML? I know html is a subset of XML but this stuff looks more and more like the XML that everyone complains about.

Edit: I'm meaning the attributes being longer than what the tags are denoting.

Re: HTML Web Components

#39

Post by salzig » Mon, Nov 13, 2023, 5:16 PM UTC

account-5 wrote: post #38

With the massive caveat that I'm not a web developer or react developer, doesn't this stuff just look XML? I know html is a subset of XML but this stuff looks more and more like the XML that everyone complains about. Edit: I'm meaning the attributes being longer than what the tags are denoting.

Does HTML kinda look like XML? Yes.

Re: HTML Web Components

#40

Post by akshayka » Mon, Nov 13, 2023, 5:17 PM UTC

We use web components in our project (a reactive Python notebook that, among other things, lets users build simple web apps [1]) to make it easy for the user to instantiate and compose our UI elements. Users can easily interpolate these elements into markdown, for example, since their representation is just HTML.

[1] https://github.com/marimo-team/marimo