I mean, if you're saying "we want syntactic support for a version of HTML that relies on properties", that's doable but a big lift. Size of effort is perhaps part of why JSX crowd continues with fork instead of proposing new parsing mode?
-
-
Replying to @slightlylate @dmitryshimkin and
> What's missing? Predictability. Consistency between components. The React model is so successful in part because of its obviousness — there's only one way to get data into a component > if you're saying ... I'm not. I think HTML is fine
1 reply 0 retweets 3 likes -
Replying to @Rich_Harris @dmitryshimkin and
...but it's HTML that *creates* this split. WC only give you high fidelity access to both sides. If you want property-only components, go nuts! It's all there.
1 reply 0 retweets 6 likes -
Replying to @slightlylate @dmitryshimkin and
"go nuts, it's all there" is *the whole problem*. When an API is well-designed, there's usually only one way to do something
2 replies 0 retweets 5 likes -
Replying to @Rich_Harris @dmitryshimkin and
Then don't use attributes in your elements! Ignore them! Throw or ignore in post-construction attr changes! Preach the no-semicolon-but-for-components message! WC open up the guts of HTML and DOM. What you do with that power *is up to you*.
1 reply 0 retweets 4 likes -
Replying to @slightlylate @dmitryshimkin and
And that's the problem. Really don't understand why you're not getting this. But it strikes at the heart of the disconnect between WC and framework camps — frameworks only succeed when the APIs are logical and learnable
2 replies 1 retweet 5 likes -
Replying to @Rich_Harris @slightlylate and
So, just for clarity, you would prefer a WC model that doesn't mirror how built in elements behave?
1 reply 0 retweets 0 likes -
Replying to @lamplightdev @slightlylate and
No, I'm not saying that — built-in elements don't give you hooks to respond to changing attributes. I'm saying that if you're designing custom elements, you could do so in a way that doesn't inherit the long standing confusion about attroperties — one of the DOM's worst aspects
1 reply 0 retweets 2 likes -
Replying to @Rich_Harris @lamplightdev and
Built-ins absolutely have internal hooks for responding to attributes they are defined to care about. That's what attributeChanged gives you too.
1 reply 0 retweets 2 likes -
Replying to @slightlylate @lamplightdev and
Again, Alex, I *could not care less* about the C++ inside browsers. As a component author and consumer that is just not in any way pertinent
1 reply 0 retweets 2 likes
Which is why I keep reiterating that *you don't have to use any of it* if you don't want HTML integration. We opened up DOM and the HTML parser to you, warts and all. Feel free to reject whichever don't serve you!
-
-
Replying to @slightlylate @lamplightdev and
It's not about the choices I make or reject when writing my own components! It's about navigating the choices made by the authors of every component I ever come across while building an app. Why is this so hard to grok?
2 replies 0 retweets 8 likes -
Replying to @Rich_Harris @lamplightdev and
It's not! The most interoperable WC work like HTML. There's plenty of space for a sect that rejects some of that interop advantage for other conveniences. They'll need to name this variant for themselves to avoid confusion, tho.
1 reply 0 retweets 2 likes - 10 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.