5 ms·

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 larg

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.

ohwellhere 3y ago
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.
- dmix 3y ago
  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/ https://www.w3.org/WAI/ARIA/apg/patterns/combobox/) which in jquery was usually via https://select2.org/ 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.
  - jtcasper 3y ago
    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.
    - xigoi 3y ago
      <input> with <datalist> still doesen't work on Firefox Android.
    - dmix 3y ago
      That's an interesting one I wasn't familiar with. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist 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.
      - couchand 3y ago
        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.
      - cdcarter 3y ago
        Clicking it shows the options for me (Chrome 119).
    - deleted 3y ago
      [deleted]
    - extra88 3y ago
      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-comboboxen.html https://adrianroselli.com/2023/06/under-engineered-comboboxe...
hu3 3y ago
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 https://github.com/kennyfrc/cami.js#key-concepts--api
- Joeri 3y ago
  You can use the htm library as a pure client-side jsx: https://github.com/developit/htm https://github.com/developit/htm It is not completely the same, but far better than that h function madness.
- deleted 3y ago
  [deleted]
naasking 3y ago
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.
- deleted 3y ago
  [deleted]
kansface 3y ago
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.
- Fahata 3y ago
  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.
  - troupo 3y ago
    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 ...
    - mardifoufs 3y ago
      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.
keepamovin 3y ago
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/- https://github.com/00000o1/-

ohwellhere 3y ago

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.

dmix 3y ago
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/ https://www.w3.org/WAI/ARIA/apg/patterns/combobox/) which in jquery was usually via https://select2.org/ 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.
- jtcasper 3y ago
  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.
  - xigoi 3y ago
    <input> with <datalist> still doesen't work on Firefox Android.
  - dmix 3y ago
    That's an interesting one I wasn't familiar with. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist 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.
    - couchand 3y ago
      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.
    - cdcarter 3y ago
      Clicking it shows the options for me (Chrome 119).
  - deleted 3y ago
    [deleted]
  - extra88 3y ago
    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-comboboxen.html https://adrianroselli.com/2023/06/under-engineered-comboboxe...

hu3 3y ago

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 https://github.com/kennyfrc/cami.js#key-concepts--api

Joeri 3y ago
You can use the htm library as a pure client-side jsx: https://github.com/developit/htm https://github.com/developit/htm It is not completely the same, but far better than that h function madness.
deleted 3y ago
[deleted]

naasking 3y ago

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.

deleted 3y ago
[deleted]

kansface 3y ago

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.

Fahata 3y ago
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.
- troupo 3y ago
  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 ...
  - mardifoufs 3y ago
    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.

keepamovin 3y ago

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/- https://github.com/00000o1/-