691–700 of 715 posts
Also, at the beginning of the first chapter, I read:
> In theory it's possible to extend other classes.. but in practice this doesn't work yet in Safari.
And was like, Ugh! It's always Safari that ruins the party!
I'm not against frameworks, but in many cases, they're unnecessary. I've always questioned why we should add 100KB of JavaScript to a page before writing a single line of real code. My team and I built https://restofworld.org without any frameworks. The feedback, from surveys, outreach, and unsolicited emails, has been overwhelmingly positive, especially around usability and reading experience. We might adopt a frame…
Puter (https://news.ycombinator.com/item?id=39597030) was also built purely using vanillaJS (or, JQuery to be more precise)
Earlier quoted context omitted.
> I’m happy to do whatever makes the most sense in any given situation What makes the most sense in this situation: you walk to the nearest pizza place, you buy your pizza, done. To an able-bodied person it shouldn't take more than 5 minutes. Bonus points: you know the way back to your home. > because problem-solving is work You know who made someone else's problem a problem=solving problem? You. The delivery guy wil…
This is a completely unhinged response to the idea of getting pizza delivered...
while wanting to monitor what the delivery guy does while doing his job and pretending to "help" him because you truly believe that having tipped a couple dollars makes him your butler, that's completely normal...
alright...
There’s a reason why everyone hates the USA right now — one major reason is that, unlike in much of the world, you truly believe that workers don’t have rights.
I'm not against frameworks, but in many cases, they're unnecessary. I've always questioned why we should add 100KB of JavaScript to a page before writing a single line of real code. My team and I built https://restofworld.org without any frameworks. The feedback, from surveys, outreach, and unsolicited emails, has been overwhelmingly positive, especially around usability and reading experience. We might adopt a frame…
Earlier quoted context omitted.
I sell urns online and my website just has an email link. No shopping cart. A brick-and-mortor urn shop would never have a shopping cart, so why would a virtual one? I've purchased specialized woodworking tools online that simply involved filling out a form. I later received the parts with an invoice to send payment. You can simply not pay if you choose not to. There are so many way to do commerce both on and offline…
There's so many different people, and it's hard to know if that's made you lose customers. I would immediately discard any website that makes me send an email to order.
Once you're building custom components in JS files, aren't you basically writing your own microframework? Sure you don't need bundlers and compilers (such as TS to JS), but at some point you might need async updates on `fetch()` of components that also share state with other components. At this point you're into framework territory, whether using your own or someone else's. Producing a framework with those features t…
> (without updating the DOM each turn, hence shadow DOM).
Uh, Shadow DOM doesn't help with DOM performance and can make some things worse. If your Web Component has terrible DOM performance in the Shadow DOM that can still noticeably degrade DOM performance of the entire DOM.
I'm of the growing opinion that the Shadow DOM is over-complicated for what it tries to do and most Web Components don't actually need the Shadow DOM and would be better without it and would have a better idea of their own performance (issues) without it.
Hot take: The Shadow DOM is built for advertisers that want beefier iframes, not for building good performance.
Earlier quoted context omitted.
Web Components don't solve the problems I do have and add new problems I don't want. Many of the 25 mentions of Shadow DOM in the Components Page and 14 mentions of it in the Styling page are about solving problems you now only have because the site recommended you use Shadow DOM, and the problem Shadow DOM itself is _trying_ to solve is one I don't have in components written specifically for my app, which will only…
Hard agree, from practical experience also. One thing will push you towards shadow dom (slots, for example) then ten things will push you back towards light dom. I don't exactly understand what the spec is aiming to solve with the way things currently are. But I do appreciate no build process.
I don't find WebComponents a good replacement for what in other web frameworks are called components. For one thing they don't support complex values like Objects and Arrays as attributes. The amount of boilerplate you have to write is way too high, and you still don't have reactivity. I do vanilla-ish JS using signals[1]. Not everything the W3C releases should be canon, XHTML is a testament to that. [1] https://wrnr…
They can support objects and arrays as attributes in the same way as the old Progressive Enhancement era (jQuery/Knockout-era) web: via data- attributes and the dataset property. Similar to that era you probably still want to support JSON serialization/deserialization to those attributes for SSG/SSR support.
Earlier quoted context omitted.
Web components only solve the interoperable, encapsulated component problem. Rendering libraries like Lit handle declarative templates, and there are many state management solutions, the same ones you can use with React, etc.
Encapsulated - yes. Interoperable - can you expand on this?
Very cool overview and a great article—it’s fascinating to see how far web components have come. Data passing, interactivity, and state management still seem pretty tedious in vanilla, though!
Data passing seems inherently broken in web components, because all HTML attrs must have string keys and values. Such a model just can't be built on top of.