6 ms·

The main reason is that they're too low-level to use directly. They do a lot, but stop just short of being useful without something of a framework on top. I t

The main reason is that they're too low-level to use directly. They do a lot, but stop just short of being useful without something of a framework on top. I tried hard to use them directly, but found that it was untenable without sensible template interpolation, and without helpers for event binding. Here's my shot at the smallest possible "framework" atop Web Components that make them workable (and even enjoyable) as an application developer: https://github.com/dchester/yhtml https://github.com/dchester/yhtml It's just ~10 SLOC, admittedly dense, but which make a world of difference in terms of usability. With that in place, now you can write markup in a style not too dissimilar from React or Vue, like... <button @click="increment">${this.count}</button> Whereas without, you need to bind your own events and manage your own template interpolation with sanitizing, handling conditionals, loops, and all the rest. If we could get something in this direction adopted into the spec, it would open up a lot of use cases for Web Components that it just can't address as-is.

throwaway14356 3y ago
meanwhile Im like... <button onclick="innerHTML++">1</button>
- deleted 3y ago
  [deleted]
- jagged-chisel 3y ago
  GP comment shows a simple example, sure. And obviously it’s overkill just to implement incrementing a displayed value. But trivializing the example doesn’t reduce the “framework” to being pointless.
- LudwigNagasena 3y ago
  Meanwhile I’m like… That’s a Content Security Policy violation.
  - throwaway14356 3y ago
    2 men are having lunch, one complaints that he always has cheese on his sandwiches. The other says, just ask your wife for something else? He responds: I always make it myself. Content-Security-Policy: script-src 'self'; script-src-attr 'unsafe-hashes' 'sha256-9lIp1merGZMC6sfoM+OcgpSSRJJr18teLzyFangr0FY='
no_wizard 3y ago
Template Instantiation is suppose to be the answer at least in part, but it’s been held up since 2017[0] The bigger problem is that the web platform stakeholders (IE the committees that industry influence and the browser makers) simply didn’t listen at all to what regular developers have been saying about what they want from the web platform w/r/t better built in platform provided primitives. It’s seems to me like web components have largely not taken lessons of component based development as everyone has come to expect. It’s still a weird imperative API with no rendering or data binding primitives [0]: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md https://github.com/WICG/webcomponents/blob/gh-pages/proposal...
- pjmlp 3y ago
  Basically the problem of any design by comittee stuff.
- thayne 3y ago
  Supposedly more declaritive APIs and data binding are coming eventually. But who knows how long we will have to wait for that.
- jongjong 3y ago
  You don't need reactive data binding. You can simply watch for HTMLElement attribute changes and invoke a render method whenever that occurs. It helps to improve your app architecture if you do this. Reactive rendering can be a foot gun and often leads to unnecessary double or triple rendering. It's better to be able to control the rendering explicitly from a single binding which is exactly what HTMLElement offers; you just need to adhere to good architectural principles. Many modern devs are too deeply involved in the React cult to see past its many over-engineered and flawed abstractions and struggle to see the simpler approach which necessitates adhering to some basic but highly beneficial architectural constraints.
  - rezonant 3y ago
    See that's weird, because the parent comments are about using in HTML template binding, and you seem to have suggested instead that a React-like render function model would be better, while simultaneously bashing React. I am no fan of React, but this comment confuses me.
chrsjxn 3y ago
Yeah, that's where I'm at, too. Authoring web components directly is too low level to be practical. You can easily end up reimplementing a ton of existing framework logic around rerenders, reactivity, event handlers, etc. And there are libraries that handle all of this for you! But then you have tooling and non-standard syntax that puts you a lot closer to other JS frameworks. And once you're in that space, the benefits of web components may or may not stack up against all the features and your team's pre-existing knowledge.
spankalee 3y ago
That approach destroys and rebuilds the entire DOM on every render. This would not work for large compound components and apps.
- _gabe_ 3y ago
  I've always wondered why this notion is so popular (is it just because of what react does)? Wouldn't the native browser be expected to handle a DOM re-render much more efficiently than an entire managed JS framework running on the native browser and emulating the DOM? Maybe in 2013 browsers really really sucked at re-renders, but I have to wonder if the myriads of WebKit, Blink, Gecko developers are so inept at their jobs that a managed framework can somehow figure out what to re-render better than the native browser can. And yes, I understand that when you program using one of these frameworks your explicitly pointing out what pieces of state will change and when, but in my professional experience, people just code whatever works and don't pay much attention to that. In the naive case, I feel like the browser would probably beat react or any other framework on re-renders every time. In the naive case where developers don't really disambiguate what state changes like they're supposed to. Are there any benchmarks or recent blogs/tech articles that dive into this?
  - 8n4vidtmkvmk 3y ago
    I think the reason that the browser is so slow is that every time you mutate something, an attribute or add or remove an element, the browser rerenders immediately. And this is indeed slow AF. If you batched everything into a DocumentFragment or similar before attaching it to the DOM then it'd be fast. I don't know how you do that ergonomically though.
    - AlotOfReading 3y ago
      Modern browsers simply set a bit that may lead to repaint after the next layout pass. Things have changed a bit since React was released in 2013.
    - lelanthran 3y ago
      > I think the reason that the browser is so slow is that every time you mutate something, an attribute or add or remove an element, the browser rerenders immediately. Is it really immediately? I thought that was a myth. I thought that, given toplevel function `foo()` which calls `bar()` which calls `baz()` which makes 25 modifications to the DOM, the DOM is only rerendered once when foo returns i.e. when control returns from usercode. I do know that making changes to the DOM, when immediately entering a while(1) loop doesn't show any change to the DOM.
Xeoncross 3y ago
Thanks for sharing, we need more libraries like this. Even htmx.org is 150kb library over what was a few lines of xhr + el.innerhtml=response.result 10 years ago. Where is the next wave of tiny libs that can make the web feel responsive again?
breadwinner 3y ago
Web Components are very easy to write, here's an example Web Component: https://github.com/wisercoder/uibuilder/blob/master/WebComponentsDemo/elements/ZxListEditor.tsx https://github.com/wisercoder/uibuilder/blob/master/WebCompo... You can even use React-like templates. You need a 500-line lib to do that: https://github.com/wisercoder/uibuilder/tree/master https://github.com/wisercoder/uibuilder/tree/master
sandreas 3y ago
You could use `jsx` / `tsx`. Maybe it's worth for you to look at https://github.com/cyco/WebFun/ https://github.com/cyco/WebFun/ Example for a `tsx` component: https://github.com/cyco/WebFun/blob/master/src/ui/components/button.tsx https://github.com/cyco/WebFun/blob/master/src/ui/components... Pure TypeScript / scss components.
WA 3y ago
Thanks for sharing. Is there a non-golfed version of this that is understandable for grugbrained devs like me?
jongjong 3y ago
You don't really need all that stuff. Sanitization is straight forward to implement and only required for user generated strings (since you want to make it HTML-safe). It could be argued that automatically sanitizing everything including already safe data types like numbers and system-generated content adds an unnecessary performance overhead for certain projects. As for events, binding is really very easy to do and it's already localised to the component so managing them is trivial. Loops are also trivial; you can simply use Array.prototype.map function to return a bunch of strings which you can incorporate directly into the main component's template string. In any case, you can always use the native document.createElement and appendChild functions to create elements within the component and add them to its DOM or shadow DOM. I've built some complex apps with plain HTMLElement as a base class for all my components and found is much simpler than React without any unexpected weirdness and using fewer abstract technical concepts. Code was much more readable and maintainable. I didn't even need a bundler thanks to modern async and defer attributes of script tags among others. I think the reason why people are using React still is just marketing, hype and inertia. The job market which is gatekept by non-technical recruiters demands React. It's all non-tech people making the big decisions based on buzzwords that they don't understand.
- contr-error 3y ago
  Can you share an example?
- rezonant 3y ago
  > Sanitization is straight forward to implement I would not say it's easy. Considering your adversaries are very motivated to do XSS and the web platform is very complicated. > It could be argued that automatically sanitizing everything including already safe data types like numbers and system-generated content adds an unnecessary performance overhead for certain projects. I don't think there's a substantial performance loss from doing a type check on a value to see that it's a number, and then putting it verbatim into the output (within your sanitization code). I don't know what "system generated content" is, and I'd argue that neither does a framework. Which means the far safer route is to assume it came from a user by default and force the dev to confirm that it's not from the user. > Loops are also trivial; you can simply use Array.prototype.map function to return a bunch of strings which you can incorporate directly into the main component's template string Combined with the "it's fine" mentality on data sanitization, it's concerning that we're using the term "string" in relation to building DOM nodes here. I hope we aren't talking about generating HTML as strings, combined with default-trusted application data that in most applications, does in fact come from the user, even if you might consider that user trusted (because it's Dave from Accounting, and not LeetHacker99 from Reddit).
thayne 3y ago
My question is why don't more frameworks use it, especially the more popular ones.

throwaway14356 3y ago

meanwhile Im like... <button onclick="innerHTML++">1</button>

deleted 3y ago
[deleted]
jagged-chisel 3y ago
GP comment shows a simple example, sure. And obviously it’s overkill just to implement incrementing a displayed value. But trivializing the example doesn’t reduce the “framework” to being pointless.
LudwigNagasena 3y ago
Meanwhile I’m like… That’s a Content Security Policy violation.
- throwaway14356 3y ago
  2 men are having lunch, one complaints that he always has cheese on his sandwiches. The other says, just ask your wife for something else? He responds: I always make it myself. Content-Security-Policy: script-src 'self'; script-src-attr 'unsafe-hashes' 'sha256-9lIp1merGZMC6sfoM+OcgpSSRJJr18teLzyFangr0FY='

no_wizard 3y ago

Template Instantiation is suppose to be the answer at least in part, but it’s been held up since 2017[0] The bigger problem is that the web platform stakeholders (IE the committees that industry influence and the browser makers) simply didn’t listen at all to what regular developers have been saying about what they want from the web platform w/r/t better built in platform provided primitives. It’s seems to me like web components have largely not taken lessons of component based development as everyone has come to expect. It’s still a weird imperative API with no rendering or data binding primitives [0]: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md https://github.com/WICG/webcomponents/blob/gh-pages/proposal...

pjmlp 3y ago
Basically the problem of any design by comittee stuff.
thayne 3y ago
Supposedly more declaritive APIs and data binding are coming eventually. But who knows how long we will have to wait for that.
jongjong 3y ago
You don't need reactive data binding. You can simply watch for HTMLElement attribute changes and invoke a render method whenever that occurs. It helps to improve your app architecture if you do this. Reactive rendering can be a foot gun and often leads to unnecessary double or triple rendering. It's better to be able to control the rendering explicitly from a single binding which is exactly what HTMLElement offers; you just need to adhere to good architectural principles. Many modern devs are too deeply involved in the React cult to see past its many over-engineered and flawed abstractions and struggle to see the simpler approach which necessitates adhering to some basic but highly beneficial architectural constraints.
- rezonant 3y ago
  See that's weird, because the parent comments are about using in HTML template binding, and you seem to have suggested instead that a React-like render function model would be better, while simultaneously bashing React. I am no fan of React, but this comment confuses me.

chrsjxn 3y ago

Yeah, that's where I'm at, too. Authoring web components directly is too low level to be practical. You can easily end up reimplementing a ton of existing framework logic around rerenders, reactivity, event handlers, etc. And there are libraries that handle all of this for you! But then you have tooling and non-standard syntax that puts you a lot closer to other JS frameworks. And once you're in that space, the benefits of web components may or may not stack up against all the features and your team's pre-existing knowledge.

spankalee 3y ago

That approach destroys and rebuilds the entire DOM on every render. This would not work for large compound components and apps.

_gabe_ 3y ago
I've always wondered why this notion is so popular (is it just because of what react does)? Wouldn't the native browser be expected to handle a DOM re-render much more efficiently than an entire managed JS framework running on the native browser and emulating the DOM? Maybe in 2013 browsers really really sucked at re-renders, but I have to wonder if the myriads of WebKit, Blink, Gecko developers are so inept at their jobs that a managed framework can somehow figure out what to re-render better than the native browser can. And yes, I understand that when you program using one of these frameworks your explicitly pointing out what pieces of state will change and when, but in my professional experience, people just code whatever works and don't pay much attention to that. In the naive case, I feel like the browser would probably beat react or any other framework on re-renders every time. In the naive case where developers don't really disambiguate what state changes like they're supposed to. Are there any benchmarks or recent blogs/tech articles that dive into this?
- 8n4vidtmkvmk 3y ago
  I think the reason that the browser is so slow is that every time you mutate something, an attribute or add or remove an element, the browser rerenders immediately. And this is indeed slow AF. If you batched everything into a DocumentFragment or similar before attaching it to the DOM then it'd be fast. I don't know how you do that ergonomically though.
  - AlotOfReading 3y ago
    Modern browsers simply set a bit that may lead to repaint after the next layout pass. Things have changed a bit since React was released in 2013.
  - lelanthran 3y ago
    > I think the reason that the browser is so slow is that every time you mutate something, an attribute or add or remove an element, the browser rerenders immediately. Is it really immediately? I thought that was a myth. I thought that, given toplevel function `foo()` which calls `bar()` which calls `baz()` which makes 25 modifications to the DOM, the DOM is only rerendered once when foo returns i.e. when control returns from usercode. I do know that making changes to the DOM, when immediately entering a while(1) loop doesn't show any change to the DOM.

Xeoncross 3y ago

Thanks for sharing, we need more libraries like this. Even htmx.org is 150kb library over what was a few lines of xhr + el.innerhtml=response.result 10 years ago. Where is the next wave of tiny libs that can make the web feel responsive again?

breadwinner 3y ago

Web Components are very easy to write, here's an example Web Component: https://github.com/wisercoder/uibuilder/blob/master/WebComponentsDemo/elements/ZxListEditor.tsx https://github.com/wisercoder/uibuilder/blob/master/WebCompo... You can even use React-like templates. You need a 500-line lib to do that: https://github.com/wisercoder/uibuilder/tree/master https://github.com/wisercoder/uibuilder/tree/master

sandreas 3y ago

You could use `jsx` / `tsx`. Maybe it's worth for you to look at https://github.com/cyco/WebFun/ https://github.com/cyco/WebFun/ Example for a `tsx` component: https://github.com/cyco/WebFun/blob/master/src/ui/components/button.tsx https://github.com/cyco/WebFun/blob/master/src/ui/components... Pure TypeScript / scss components.

WA 3y ago

Thanks for sharing. Is there a non-golfed version of this that is understandable for grugbrained devs like me?

jongjong 3y ago

You don't really need all that stuff. Sanitization is straight forward to implement and only required for user generated strings (since you want to make it HTML-safe). It could be argued that automatically sanitizing everything including already safe data types like numbers and system-generated content adds an unnecessary performance overhead for certain projects. As for events, binding is really very easy to do and it's already localised to the component so managing them is trivial. Loops are also trivial; you can simply use Array.prototype.map function to return a bunch of strings which you can incorporate directly into the main component's template string. In any case, you can always use the native document.createElement and appendChild functions to create elements within the component and add them to its DOM or shadow DOM. I've built some complex apps with plain HTMLElement as a base class for all my components and found is much simpler than React without any unexpected weirdness and using fewer abstract technical concepts. Code was much more readable and maintainable. I didn't even need a bundler thanks to modern async and defer attributes of script tags among others. I think the reason why people are using React still is just marketing, hype and inertia. The job market which is gatekept by non-technical recruiters demands React. It's all non-tech people making the big decisions based on buzzwords that they don't understand.

contr-error 3y ago
Can you share an example?
rezonant 3y ago
> Sanitization is straight forward to implement I would not say it's easy. Considering your adversaries are very motivated to do XSS and the web platform is very complicated. > It could be argued that automatically sanitizing everything including already safe data types like numbers and system-generated content adds an unnecessary performance overhead for certain projects. I don't think there's a substantial performance loss from doing a type check on a value to see that it's a number, and then putting it verbatim into the output (within your sanitization code). I don't know what "system generated content" is, and I'd argue that neither does a framework. Which means the far safer route is to assume it came from a user by default and force the dev to confirm that it's not from the user. > Loops are also trivial; you can simply use Array.prototype.map function to return a bunch of strings which you can incorporate directly into the main component's template string Combined with the "it's fine" mentality on data sanitization, it's concerning that we're using the term "string" in relation to building DOM nodes here. I hope we aren't talking about generating HTML as strings, combined with default-trusted application data that in most applications, does in fact come from the user, even if you might consider that user trusted (because it's Dave from Accounting, and not LeetHacker99 from Reddit).

thayne 3y ago

My question is why don't more frameworks use it, especially the more popular ones.