Hacker News Reader

Comment by nightski | Hacker News Reader

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 underneath when you use React? It just doesn't make any sense.

View on HN

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.

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

<input> with <datalist> still doesen't work on Firefox Android.

That's an interesting one I wasn't familiar with.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...

It's a shame clicking on it doesn't show the options like a select box though.

Click again I guess?

> Recommended values in types text, search, url, tel, email and number, are displayed in a drop-down menu when user clicks or double-clicks on the control.

Clicking it shows the options for me (Chrome 119).

On paper, <datalist> is great but as implemented (or not) in all browsers, it has issues. This post walks through an example of using the element but also summarizes issues (as of June 2023): Under-Engineered Comboboxen?

https://adrianroselli.com/2023/06/under-engineered-comboboxe...

> Most people using react aren't building SPAs

> People still abuse React/Vue of course and the trend is 100% moving back to "mostly static" rather than slow SPAs

I'm not seeing this at all, in fact I can't remember the last React project I worked on that wasn't a full blown SPA. I don't see anyone starting or advocating for static sites with islands unless they're using a framework like Astro or something.

Do you have any example sites or codebases using this approach?

Not elegant but we use a websocket for search in htmx.

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.

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.

I think the criticisms of not solving state management and routing are well taken. I've tried to create a minimal sub-300 line, sub 3KB-compressed micro base class for using custom elements that reduces their cumbersomeness!

I wonder what minimal solutions to state management and routing might look like in Hyphen: https://github.com/00000o1/-

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.

I'd add longevity. If your company works for a product where you'll have to maintain the code you write now for the next decades, you don't want to deal with then-ancient abstractions. The JavaScript of a well-written web component should be as valid now as it will be in 10 years, as you're just using the platform.

This year I pulled class-based React component into a greenfield React project. Worked without a hitch, even though its a 10-year difference between approaches.

Meanwhile, "use the platform":

- all form components written before form participation landed in browsers are broken

- all web components written before cross-root ARIA (not even a spec yet) are potentially broken due to shadow DOM

- ... you may continue this list at your own leisure ...

Yeah I don't get the comments either. React has been there for a decade now, is pretty stable and very backwards compatible. You can't really go wrong with it and it's a super lightweight "framework" (I know, it's not a framework, maybe a library would be a better term) all things considered.

The issue is just some sort of "front end bad" feeling at this point, imo. It's like some people think web components are the answer to the popular perception of the frontend being a mess of yearly novelties. When again, you can just use react and could have done so for a decade now.

Reply on news.ycombinator.com