6 ms·

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 jus

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 "replace" HTML (re: "XHTML wanted to replace HTML4, but HTML5 wanted to augment it. HTML5 won.", in the "On The Web, Augmentation Wins in the Long Run" section), they are taking HTML/CSS/JS and building on top of them. If they all used canvas to render instead I might buy that argument but they don't. They absolutely push those technologies to their breaking point but it's nothing short of amazing in my book what you can accomplish with them compared to just HTML/CSS/JS and even "web components". I was excited when Web Components were first announced but they are incredibly lackluster with no "Batteries included" and feel like they don't really help you build web _apps_ like the frameworks do. Every alternative to the big frameworks (looking at you htmlx) feel like minor syntaxic sugar for jQuery and friends which feels like a massive step backwards and completely the wrong choice for building a web app.

continuational 3y ago
> I was interested to see this article explain what `user-avatar` actually did/provided but it never did. Yeah, the lack of concrete examples makes this feel a bit too much like a shower thought to me.
- yohannparis 3y ago
  This is a purpose of a blog. This was not a tutorial or an article on how to use Web Components.
  - continuational 3y ago
    I mean, anybody is free to write how they like on their blog. I just don't find arguments like these convincing without realistic non-trivial examples.
    - hasanhaja 3y ago
      What would a non-trivial example look like to you? I'm working on building exactly this resource alongside a series of posts on web components.
      - continuational 3y ago
        One example would be a search field that shows suggestions from the server while typing.
        hasanhaja 3y ago
        Here's a pre-built one that I found that even lets you customize the debounce amount: https://ionicframework.com/docs/api/searchbar#debounce https://ionicframework.com/docs/api/searchbar#debounce The Stackblitz example is quite good too. I'll give it shot to build a super simple one with just vanilla JS without helper libraries like Lit or Stencil. I think I'd take the same approach as I would with React, and I think the biggest difference would be where the fetch gets executed. In React you'd expose a prop like "submitHandler", but here I would emit an event from the component (after whatever debounce amount) and expect the caller to attach an event listener to my custom event to perform the fetch.
- davedx 3y ago
  Lack of substantial concrete examples is an issue with many of these anti-react technologies. Even svelte doesn’t seem to have many (any?) examples of large scale commercial projects using it. In the last 10 years the only new web tech I’ve seen get traction outside of tech communities - so actual job postings etc - is vue.
reactordev 3y ago
>"with no "Batteries included" and feel like they don't really help you build web _apps_ like the frameworks do." Define _app_. React doesn't have batteries, it has composability. Web Components do too but you have to know how (it's a lot easier in React, just return (html)) but in Web Components, you can register your custom element and provide the functionality that you call "batteries". [1] So if you don't care about attributes and just want semantic composable things, just call it whatever you want to. <user-avatar></user-avatar>. Conceptually it's a web component that extends HTMLDivElement. [1] https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_custom_elements https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...
boredtofears 3y ago
I think the Eric Meyer post demonstrates the intention of that much better: https://meyerweb.com/eric/thoughts/2023/11/01/blinded-by-the-light-dom/ 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.
- webstrand 3y ago
  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?
  - sirwhinesalot 3y ago
    Yup, connectedCallback is a lot nicer than a for loop applying the right code to the right divs.
- joshstrange 3y ago
  That still doesn't click for me. Why wouldn't you make the label/slider part of the component itself. It feels like you have the worst of both worlds. You more or less need/expect it to always wrap those elements but nothing enforces that so this seems very brittle to me, not to mention verbose. They mention not wanting to pass though all those props: <super-slider type="range" min="0.5" max="4" step="0.1" value="2" unit="em" target=".preview h1"> We will ignore the last 2 since those are required anyway. How is `type="range"` not the default that you would just set, no attribute/prop needed? Then min/max/step/value all feel like things you could have defaults for and then, yes, pass them through. In forms I'm always pushing towards consistency, I don't want to make it easy to just set random attributes on the underlying element, it needs to be deliberate. I can believe I'm just missing something but Web Components just seem like extra work with very little gain.
sylware 3y ago
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 interop portal with noscript/basic (x)html browsers to avoid, at least for critical online services, Big Tech lock-in and unreasonable exit cost. That said, it may be a good idea to be able to drive the display or not of <table> rules with the default styling (css or hardcoded) from the 2D semantic HTML document attributes (I should check the hardcoded style of links and lynx for <table> rules). (I am not talking about the abomination of the "semantic" web we had a decade ago)
- Ambolia 3y ago
  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.
  - sylware 3y ago
    I don't agree, what you call "back-and-forth" is not negative, actually it appears more like "consistency" to me... and in the end, more than enough for a bazillions of online services and that at a ridicule technical cost compared to the one from Big Tech (not to mention all the corollary issues). Of course, it is a trade-off, bells-and-whistles from rich GUIs are sexy, but the technical cost of such bells-and-whistles in a web context is grostesquely and absurdely unbalanced compared to what can be achieved with simple and consistent noscript/basic (x)html portals for any pertinent goal of a bazillions of online services.
- joshstrange 3y ago
  If you don't care about UI/UX then I agree. I do and even if I didn't the companies I work for absolutely do and the customers expect a certain level of UI/UX that is absolutely not possible with no script. I also work primarily on web apps which cannot be done without JS.
flanbiscuit 3y ago
React has `props.children`, Web Components have `this.innerHTML`. But also, anything inside the custom tag you can query using regular DOM querying. Here's an example I just created: https://jsfiddle.net/qc35an1s/2/ https://jsfiddle.net/qc35an1s/2/ I actually have zero Web Component experience so I'm not sure if I'm following best practices there, but I was able to get that working pretty quick
Xeamek 3y ago
>Every alternative to the big frameworks (looking at you htmlx) feel like minor syntaxic sugar for jQuery and friends True >which feels like a massive step backwards and completely the wrong choice for building a web app. Why? I mean, I'd agree if by 'web-app' you mean something like google-sheets. But I believe this whole "anti-react" movement isn't talking about such usecases, but rather against defaulting frameworks and building using them 'from the ground up', where trully all the website actually need is the "sparkling of interactivity on top"
- joshstrange 3y ago
  > But I believe this whole "anti-react" movement isn't talking about such usecases, but rather against defaulting frameworks and building using them 'from the ground up', where trully all the website actually need is the "sparkling of interactivity on top" We absolutely don't have shared language for these things and we aren't always talking about the same things. The thing is there are just vanishingly few places where you only need a "sparkling of interactivity on top". Yes your blog probably doesn't need a full framework, nor does your news site (which is just a blog++) or your marketing web page. But so many other things really do or things break down quickly. Also what your web site needs today might not cover what it needs tomorrow. I've seen a number of "web admin"/backend control panels (customer-facing for config) start simple then grow until they start to collapse under their own weight with just added jQuery as needed. Sure, at the start, htmlx/jQuery might cover all you need but soon you are building custom UI to represent business logic/ideas and managing with that gets very unwieldy. The people that say "all you need is the built-in HTML elements" are living in a fantasy land, try using the default date/time picker and get back to me. I'm sure there are things I'd agree with the anti-react crowd on (places you don't need a framework) but all their examples are incredibly contrived and feel like the "TODO app examples" you often see for frameworks or learning a language. They don't even scratch the surface of what's needed for complicated apps, they are great to show off the simple things but it seems like the anti-react/anti-framework crowd thinks those simple examples are all you need and that's just silly. At the end of the day I'll admit I reach for a framework earlier than I absolutely need it and that's because I've built 10's and 10's of sites (web apps) from the ground up and eventually you either use a framework or you end up creating a shitty version of one. So yeah, day 1 I might not need Vue but day 100 I'm sure glad I have all of Vue to build on.
sandreas 3y ago
Basically, HTML Web Components are classes extending HTMLElement registered manually via JavaScript / DOM API. class superSlider extends HTMLElement { connectedCallback() { let targetEl = document.querySelector(this.getAttribute('target')); let unit = this.getAttribute('unit'); let slider = this.querySelector('input[type="range"]'); } } customElements.define("super-slider",superSlider); For a more sophisticated example with scss, jsx/tsx and ES20.. you could take a look at https://github.com/cyco/WebFun https://github.com/cyco/WebFun My personal problem with these "native" components is, that the shadow DOM is pretty restricted compared to component frameworks like React, Vue or Svelte.
- toasted-subs 3y ago
  I don't understand why people use the shadow Dom. Why not edit the Dom directly?
  - lpedrosa 3y ago
    You are correct. You don't have to use the shadow DOM, when you create a new Custom Element. The shadow DOM provides two things: - style encapsulation (as well as `id` attributes) - ability to use `<slot>` for templating You should use it if you require one of the above or both.
fuzzy2 3y ago
My take is: As explained in the article, user-avatar does absolutely nothing. If anything, it could only enhance the existing markup (with behavior), but never replace it. It’s… semantic markup, if you will. Baloney if you ask me.
- keepamovin 3y ago
  Yeah I was thinking about what it could do, but I don't get it. The point of custom elements is to define a class in JavaScript that does something. Custom elements are just a part of web components tho, and you can use shadow DOM, more JS, and templating with slots. I guess user-avatar could define a template that includes styles and slots to turn the image into a round image and maybe add some caption and link to it. But that would still require JS to print the template.content.
andai 3y ago
> lackluster with no "Batteries included" I wish this weren't so, but it perfectly describes my experience with every single web technology. JavaScript, DOM, Canvas, Web Audio... they all remind me of this quote: "Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy." -Alan Perlis
- andai 3y ago
  I am of course, slightly exaggerating, but... by way of analogy: I used a PDF library that didn't automatically flow text onto the page. You had to do it yourself. Line by line. Page by page. So, I wrote a few routines to do it. Maybe 50 lines? And I'm just like... this PDF library is twenty eight thousand lines lines long... and they couldn't have included those fifty?! Why! Meanwhile, a browser is 10-20 MILLION lines of code, and ... I originally ranted for several pages, but I'll just go and say that I never want to see the string "undefinedundefinedundefined" show up during runtime (and that this is 100% realistic and achievable in a dynamic language, without type annotations).
  - quickthrower2 3y ago
    > 100% realistic and achievable in a dynamic language Achievable by just removing automatic type coercion. Throw errors instead. Would need to be feature flagged for backwards compatiability.
    - andai 3y ago
      Exactly! You put that very elegantly. (I call that proposed flag "use sane") I always thought JS needed static types to fix the insanity until I tried Python and realized that almost all the insane BS I get in JS are all runtime errors in Python. There's a very good case to be made for reducing runtime errors, but it's a hell of a good start to at least have them! Rather than what we have now, which is "assume the programmer is a beginner, who also never makes mistakes", and "given nonsensical commands, just do nonsense, and propagate garbage data throughout the entire program".
  - mewpmewp2 3y ago
sph 3y ago
> Every alternative to the big frameworks (looking at you htmlx) feel like minor syntaxic sugar for jQuery and friends which feels like a massive step backwards and completely the wrong choice for building a web app. Building an entire web app out of Javascript has been an incredibly dumb idea, and some ecosystems are trying to return us to the roots: most of the heavy lifting is done server-side, and JS is a sprinkle of interactivity on top, like the golden age of jQuery. Before you bite my head off telling me about apps that necessarily have to be SPAs, how many apps are people using React for when a modern server-side framework would do (i.e. Phoenix Live View)?
- quickthrower2 3y ago
  I wouldn't put Phoenix in the "would do" pile. That looks like a decent learning curve. PHP Laravel and Ruby on Rails are in the "would do" pile. This doesn't take away from your point though!
jonahx 3y ago
> Every alternative to the big frameworks (looking at you htmlx) feel like minor syntaxic sugar for jQuery Have you used htmx? Since it doesn't solve the same problem jquery did (UX for client side JS), the accusation is misplaced. htmx is (primarily) a way of avoiding writing JS by extending the server-side rendered html paradigm to partial pages instead of full page re-loads.
- bluewalt 3y ago
  I think he knows that. The comparison with jQuery comes from the fact it is a DOM replacement logic too. Even if the syntax is way better, in the end, it’s still a way of working that scales badly, compared to components which embed their own logic. htmx shines to add dynamic behaviour on some pages, but is not appropriate to replace a medium-sized SPA in my opinion.
  - dreadnip 3y ago
    I personally think htmx augmenting a MPA approach is perfect for medium-sized apps.
keepamovin 3y ago
I think the confusion caused by this article is because the author presents a false "pick your side" choice: "React-style" custom elements with props, or, custom elements with light DOM. Unfortunately, discussion of web frameworks often seems to occur with tribalistic attitudes, which can obscure a clear understanding of appropriate choices for a given application. The author's dichotomy could be seen as unnecessarily divisive by creating an artificial distinction and suggesting only one must be chosen. It also seems not to reflect an underlying technical reality nor suggested best practice. In reality, both React and custom elements can enable either style, and the choice should depend on what's most appropriate for the situation. Not only can both frameworks do both approaches, they can do them at the same time! You can have a wrapper style elements that also takes props. A window-box that provides diverse content with an OS-style draggable-window capability is a good example. As to the author's suggestion that HTML components (which appear nevertheless to still require JavaScript) are better, and prop-style is to worse, in general, I'll have to think more about it. I may have underappreciated the light DOM style in my creation of Hyphen: https://github.com/00000o1/- https://github.com/00000o1/- Instead of focusing on slots for templating (which you can still use if you want) in Hyphen, I made templates easy with JS template literals, because it's not always just elements you may want to insert, but rather class names, attributes, and so on. Check it out if you are interested in new approaches to custom elements! It's only 3K and less than 300 lines, aiming to provide maximal utility with minimal code.
hasanhaja 3y ago
This is a better and more concrete example of the point made in the article: - https://www.zachleat.com/web/details-utils https://www.zachleat.com/web/details-utils The `details-utils` component enhances the behavior of the built-in HTML `detail` component. If for any reason you have JavaScript disabled, then using a web component like this would be just fine because the `detail` component would continue to behave like it always does. If you have JS enabled (or it's finished downloading) then you have an enhanced version of it that has features like collapsing when you click outside of it, etc. That's the part that's reusable when used like this. That web component from the creator of 11ty is what made the point made in the article click for me. When I first started looking at web components I was like, "this still requires JavaScript and doesn't work without it," and that was the same point Rich Harris made in this article: https://dev.to/richharris/why-i-don-t-use-web-components-2cia https://dev.to/richharris/why-i-don-t-use-web-components-2ci...

continuational 3y ago

> I was interested to see this article explain what `user-avatar` actually did/provided but it never did. Yeah, the lack of concrete examples makes this feel a bit too much like a shower thought to me.

yohannparis 3y ago
This is a purpose of a blog. This was not a tutorial or an article on how to use Web Components.
- continuational 3y ago
  I mean, anybody is free to write how they like on their blog. I just don't find arguments like these convincing without realistic non-trivial examples.
  - hasanhaja 3y ago
    What would a non-trivial example look like to you? I'm working on building exactly this resource alongside a series of posts on web components.
    - continuational 3y ago
      One example would be a search field that shows suggestions from the server while typing.
      - hasanhaja 3y ago
        Here's a pre-built one that I found that even lets you customize the debounce amount: https://ionicframework.com/docs/api/searchbar#debounce https://ionicframework.com/docs/api/searchbar#debounce The Stackblitz example is quite good too. I'll give it shot to build a super simple one with just vanilla JS without helper libraries like Lit or Stencil. I think I'd take the same approach as I would with React, and I think the biggest difference would be where the fetch gets executed. In React you'd expose a prop like "submitHandler", but here I would emit an event from the component (after whatever debounce amount) and expect the caller to attach an event listener to my custom event to perform the fetch.
davedx 3y ago
Lack of substantial concrete examples is an issue with many of these anti-react technologies. Even svelte doesn’t seem to have many (any?) examples of large scale commercial projects using it. In the last 10 years the only new web tech I’ve seen get traction outside of tech communities - so actual job postings etc - is vue.

reactordev 3y ago

>"with no "Batteries included" and feel like they don't really help you build web _apps_ like the frameworks do." Define _app_. React doesn't have batteries, it has composability. Web Components do too but you have to know how (it's a lot easier in React, just return (html)) but in Web Components, you can register your custom element and provide the functionality that you call "batteries". [1] So if you don't care about attributes and just want semantic composable things, just call it whatever you want to. <user-avatar></user-avatar>. Conceptually it's a web component that extends HTMLDivElement. [1] https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_custom_elements https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...

boredtofears 3y ago

I think the Eric Meyer post demonstrates the intention of that much better: https://meyerweb.com/eric/thoughts/2023/11/01/blinded-by-the-light-dom/ 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.

webstrand 3y ago
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?
- sirwhinesalot 3y ago
  Yup, connectedCallback is a lot nicer than a for loop applying the right code to the right divs.
joshstrange 3y ago
That still doesn't click for me. Why wouldn't you make the label/slider part of the component itself. It feels like you have the worst of both worlds. You more or less need/expect it to always wrap those elements but nothing enforces that so this seems very brittle to me, not to mention verbose. They mention not wanting to pass though all those props: <super-slider type="range" min="0.5" max="4" step="0.1" value="2" unit="em" target=".preview h1"> We will ignore the last 2 since those are required anyway. How is `type="range"` not the default that you would just set, no attribute/prop needed? Then min/max/step/value all feel like things you could have defaults for and then, yes, pass them through. In forms I'm always pushing towards consistency, I don't want to make it easy to just set random attributes on the underlying element, it needs to be deliberate. I can believe I'm just missing something but Web Components just seem like extra work with very little gain.

sylware 3y ago

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 interop portal with noscript/basic (x)html browsers to avoid, at least for critical online services, Big Tech lock-in and unreasonable exit cost. That said, it may be a good idea to be able to drive the display or not of <table> rules with the default styling (css or hardcoded) from the 2D semantic HTML document attributes (I should check the hardcoded style of links and lynx for <table> rules). (I am not talking about the abomination of the "semantic" web we had a decade ago)

Ambolia 3y ago
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.
- sylware 3y ago
  I don't agree, what you call "back-and-forth" is not negative, actually it appears more like "consistency" to me... and in the end, more than enough for a bazillions of online services and that at a ridicule technical cost compared to the one from Big Tech (not to mention all the corollary issues). Of course, it is a trade-off, bells-and-whistles from rich GUIs are sexy, but the technical cost of such bells-and-whistles in a web context is grostesquely and absurdely unbalanced compared to what can be achieved with simple and consistent noscript/basic (x)html portals for any pertinent goal of a bazillions of online services.
joshstrange 3y ago
If you don't care about UI/UX then I agree. I do and even if I didn't the companies I work for absolutely do and the customers expect a certain level of UI/UX that is absolutely not possible with no script. I also work primarily on web apps which cannot be done without JS.

flanbiscuit 3y ago

React has `props.children`, Web Components have `this.innerHTML`. But also, anything inside the custom tag you can query using regular DOM querying. Here's an example I just created: https://jsfiddle.net/qc35an1s/2/ https://jsfiddle.net/qc35an1s/2/ I actually have zero Web Component experience so I'm not sure if I'm following best practices there, but I was able to get that working pretty quick

Xeamek 3y ago

>Every alternative to the big frameworks (looking at you htmlx) feel like minor syntaxic sugar for jQuery and friends True >which feels like a massive step backwards and completely the wrong choice for building a web app. Why? I mean, I'd agree if by 'web-app' you mean something like google-sheets. But I believe this whole "anti-react" movement isn't talking about such usecases, but rather against defaulting frameworks and building using them 'from the ground up', where trully all the website actually need is the "sparkling of interactivity on top"

joshstrange 3y ago
> But I believe this whole "anti-react" movement isn't talking about such usecases, but rather against defaulting frameworks and building using them 'from the ground up', where trully all the website actually need is the "sparkling of interactivity on top" We absolutely don't have shared language for these things and we aren't always talking about the same things. The thing is there are just vanishingly few places where you only need a "sparkling of interactivity on top". Yes your blog probably doesn't need a full framework, nor does your news site (which is just a blog++) or your marketing web page. But so many other things really do or things break down quickly. Also what your web site needs today might not cover what it needs tomorrow. I've seen a number of "web admin"/backend control panels (customer-facing for config) start simple then grow until they start to collapse under their own weight with just added jQuery as needed. Sure, at the start, htmlx/jQuery might cover all you need but soon you are building custom UI to represent business logic/ideas and managing with that gets very unwieldy. The people that say "all you need is the built-in HTML elements" are living in a fantasy land, try using the default date/time picker and get back to me. I'm sure there are things I'd agree with the anti-react crowd on (places you don't need a framework) but all their examples are incredibly contrived and feel like the "TODO app examples" you often see for frameworks or learning a language. They don't even scratch the surface of what's needed for complicated apps, they are great to show off the simple things but it seems like the anti-react/anti-framework crowd thinks those simple examples are all you need and that's just silly. At the end of the day I'll admit I reach for a framework earlier than I absolutely need it and that's because I've built 10's and 10's of sites (web apps) from the ground up and eventually you either use a framework or you end up creating a shitty version of one. So yeah, day 1 I might not need Vue but day 100 I'm sure glad I have all of Vue to build on.

sandreas 3y ago

Basically, HTML Web Components are classes extending HTMLElement registered manually via JavaScript / DOM API. class superSlider extends HTMLElement { connectedCallback() { let targetEl = document.querySelector(this.getAttribute('target')); let unit = this.getAttribute('unit'); let slider = this.querySelector('input[type="range"]'); } } customElements.define("super-slider",superSlider); For a more sophisticated example with scss, jsx/tsx and ES20.. you could take a look at https://github.com/cyco/WebFun https://github.com/cyco/WebFun My personal problem with these "native" components is, that the shadow DOM is pretty restricted compared to component frameworks like React, Vue or Svelte.

toasted-subs 3y ago
I don't understand why people use the shadow Dom. Why not edit the Dom directly?
- lpedrosa 3y ago
  You are correct. You don't have to use the shadow DOM, when you create a new Custom Element. The shadow DOM provides two things: - style encapsulation (as well as `id` attributes) - ability to use `<slot>` for templating You should use it if you require one of the above or both.

fuzzy2 3y ago

My take is: As explained in the article, user-avatar does absolutely nothing. If anything, it could only enhance the existing markup (with behavior), but never replace it. It’s… semantic markup, if you will. Baloney if you ask me.

keepamovin 3y ago
Yeah I was thinking about what it could do, but I don't get it. The point of custom elements is to define a class in JavaScript that does something. Custom elements are just a part of web components tho, and you can use shadow DOM, more JS, and templating with slots. I guess user-avatar could define a template that includes styles and slots to turn the image into a round image and maybe add some caption and link to it. But that would still require JS to print the template.content.

andai 3y ago

> lackluster with no "Batteries included" I wish this weren't so, but it perfectly describes my experience with every single web technology. JavaScript, DOM, Canvas, Web Audio... they all remind me of this quote: "Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy." -Alan Perlis

andai 3y ago
I am of course, slightly exaggerating, but... by way of analogy: I used a PDF library that didn't automatically flow text onto the page. You had to do it yourself. Line by line. Page by page. So, I wrote a few routines to do it. Maybe 50 lines? And I'm just like... this PDF library is twenty eight thousand lines lines long... and they couldn't have included those fifty?! Why! Meanwhile, a browser is 10-20 MILLION lines of code, and ... I originally ranted for several pages, but I'll just go and say that I never want to see the string "undefinedundefinedundefined" show up during runtime (and that this is 100% realistic and achievable in a dynamic language, without type annotations).
- quickthrower2 3y ago
  > 100% realistic and achievable in a dynamic language Achievable by just removing automatic type coercion. Throw errors instead. Would need to be feature flagged for backwards compatiability.
  - andai 3y ago
    Exactly! You put that very elegantly. (I call that proposed flag "use sane") I always thought JS needed static types to fix the insanity until I tried Python and realized that almost all the insane BS I get in JS are all runtime errors in Python. There's a very good case to be made for reducing runtime errors, but it's a hell of a good start to at least have them! Rather than what we have now, which is "assume the programmer is a beginner, who also never makes mistakes", and "given nonsensical commands, just do nonsense, and propagate garbage data throughout the entire program".
- mewpmewp2 3y ago

sph 3y ago

> Every alternative to the big frameworks (looking at you htmlx) feel like minor syntaxic sugar for jQuery and friends which feels like a massive step backwards and completely the wrong choice for building a web app. Building an entire web app out of Javascript has been an incredibly dumb idea, and some ecosystems are trying to return us to the roots: most of the heavy lifting is done server-side, and JS is a sprinkle of interactivity on top, like the golden age of jQuery. Before you bite my head off telling me about apps that necessarily have to be SPAs, how many apps are people using React for when a modern server-side framework would do (i.e. Phoenix Live View)?

quickthrower2 3y ago
I wouldn't put Phoenix in the "would do" pile. That looks like a decent learning curve. PHP Laravel and Ruby on Rails are in the "would do" pile. This doesn't take away from your point though!

jonahx 3y ago

> Every alternative to the big frameworks (looking at you htmlx) feel like minor syntaxic sugar for jQuery Have you used htmx? Since it doesn't solve the same problem jquery did (UX for client side JS), the accusation is misplaced. htmx is (primarily) a way of avoiding writing JS by extending the server-side rendered html paradigm to partial pages instead of full page re-loads.

bluewalt 3y ago
I think he knows that. The comparison with jQuery comes from the fact it is a DOM replacement logic too. Even if the syntax is way better, in the end, it’s still a way of working that scales badly, compared to components which embed their own logic. htmx shines to add dynamic behaviour on some pages, but is not appropriate to replace a medium-sized SPA in my opinion.
- dreadnip 3y ago
  I personally think htmx augmenting a MPA approach is perfect for medium-sized apps.

keepamovin 3y ago

I think the confusion caused by this article is because the author presents a false "pick your side" choice: "React-style" custom elements with props, or, custom elements with light DOM. Unfortunately, discussion of web frameworks often seems to occur with tribalistic attitudes, which can obscure a clear understanding of appropriate choices for a given application. The author's dichotomy could be seen as unnecessarily divisive by creating an artificial distinction and suggesting only one must be chosen. It also seems not to reflect an underlying technical reality nor suggested best practice. In reality, both React and custom elements can enable either style, and the choice should depend on what's most appropriate for the situation. Not only can both frameworks do both approaches, they can do them at the same time! You can have a wrapper style elements that also takes props. A window-box that provides diverse content with an OS-style draggable-window capability is a good example. As to the author's suggestion that HTML components (which appear nevertheless to still require JavaScript) are better, and prop-style is to worse, in general, I'll have to think more about it. I may have underappreciated the light DOM style in my creation of Hyphen: https://github.com/00000o1/- https://github.com/00000o1/- Instead of focusing on slots for templating (which you can still use if you want) in Hyphen, I made templates easy with JS template literals, because it's not always just elements you may want to insert, but rather class names, attributes, and so on. Check it out if you are interested in new approaches to custom elements! It's only 3K and less than 300 lines, aiming to provide maximal utility with minimal code.

hasanhaja 3y ago

This is a better and more concrete example of the point made in the article: - https://www.zachleat.com/web/details-utils https://www.zachleat.com/web/details-utils The `details-utils` component enhances the behavior of the built-in HTML `detail` component. If for any reason you have JavaScript disabled, then using a web component like this would be just fine because the `detail` component would continue to behave like it always does. If you have JS enabled (or it's finished downloading) then you have an enhanced version of it that has features like collapsing when you click outside of it, etc. That's the part that's reusable when used like this. That web component from the creator of 11ty is what made the point made in the article click for me. When I first started looking at web components I was like, "this still requires JavaScript and doesn't work without it," and that was the same point Rich Harris made in this article: https://dev.to/richharris/why-i-don-t-use-web-components-2cia https://dev.to/richharris/why-i-don-t-use-web-components-2ci...