←back to thread

367 points lemonberry | 1 comments | | HN request time: 0.415s | source
Show context
pfraze ◴[] No.24641307[source]
I completely agree with the author that WCs fail to push more behaviors into HTML. As she describes, you really want to be able to import the WC's script and then have new useful HTML tags.

I use LitElement pretty extensively, which is a wrapper around WCs, and I like it quite a bit - but it's only a minor improvement in my mind compared to React, and that improvement is just reducing the abstractions from the DOM API. It's still a mega codebase.

I've also tried multiple times to just work with vanilla WCs, and it's sensible only up to a very limited point. If you got a JSX/lit-html module involved it would go further, but at that point it's pretty past "vanilla." And even then, you're not in the realm of "just using HTML."

Author lays a lot of that on the developers having a proclivity for JS, and that may be true, but I've been trying to figure out if this is just complexity in the stack that hasn't yet be solved. UIs are complex, you have lots of stateful interactions between them, and I'm really not sure what the right solution would be for a "do lots via HTML" goal.

replies(3): >>24641667 #>>24641689 #>>24641730 #
hinkley ◴[] No.24641689[source]
Would it help if we made a standard for communication between web components, so whatever tools they use internally, you can wire them into your code or to each other?

Web components are abstraction boundaries, and you have to define boundaries carefully or you still end up with a big ball of mud, now with extra layers of indirection to make your life even worse.

replies(2): >>24642094 #>>24642745 #
1. pfraze ◴[] No.24642745[source]
Yes, but I'm unsure what a well-designed execution of that would look like.