I’ve seen a few related posts but nothing really definitive here: Can native web components be defined and used in Hugo sites (and I’m just learning these so apologies if I’m not using the correct terminology here, let alone understanding the scope of usage)?
I understand partials and shortcakes can be utilized in some of the same ways, but I also want to practice using web components and utilize them as it makes sense (if at all).
A web component is nothing else than a shortcode that is a little bit more sophisticated in my opinion. I would still separate the template/html part from the javascript part and load the javascript conditionally when either a partial is used or a shortcode. The shortcode should only be a bridge to the partial. Then add parameters and call your web-component like a shortcode in your markdown and like a partial in your template files.
Web components are JavaScript with ideology. There’s nothing special or interesting about them compared to any other JavaScript, but they seem like “a standard” (they aren’t really), so people latch onto them as though they were. Hugo can handle them as well as anything else, but if you’re deciding where to spend your time when learning JS, I wouldn’t bother to mess with them until after you get used to regular vanilla JS and then one of the popular frameworks, like React, Vue, Alpine, etc. Once you know vanilla and a framework, you can see that Web Components are just a scaffolding for new frameworks, but the scaffolding doesn’t really offer very much except in some very niche situations.
Anyway, I recommend avoiding the hype, keeping an open mind, and trying lots of things before buying into something just because someone says “it’s the standard.”
Assuming you mean web components as per the link I have included. I agree with @carlmjohnson first and foremost I would get a handle on vanilla JS but I think web components are very useful.
I’ve used Alpine JS quite a lot this year and I like it a lot but I have recently discovered something that is a big concern - it is support, or lack of, for legacy browsers. Its not documented at all and I recently noticed that the most recent version of Alpine JS, v3, doesn’t have very good legacy support for iOS. Its like it gets blocked and it completely renders all JS on the site not working and with responsive versions of websites the nav/menu systems are often entirely dependent on JS so it makes the site almost unusable.
I haven’t seen any problems with Alpine and old iOS. As for IE 11, I don’t support it anymore: Dropping Support For IE11 Is Progressive Enhancement · The Ethically-Trained Programmer
I only happened to be testing on iOS 10.3.3 by chance and Alpine JS v3 doesn’t work at all in iOS 10.3.3. I appreciate the hardware that will be running that version of iOS as it will be the last available update is very old but the last release of 10 was only in 2019. Yes its only a small fraction of users but surely it could be graceful in some way rather than make an Alpine JS v3 site unusable - v2 is fine.
It’s my understanding it’s something to do with v3 using queueMicrotask so you actually need iOS 12.2 or newer to use Alpine JS v3. That would mean anything older than 12.2 doesn’t support Alpine JS v3 to me that seems like weak legacy support for iOS.