I'm personally torn. Write components in C++ and it isn't extensible and doesn't layer. Write it in JavaScript and well, lots of things get complicated. Not least of which is that the WC model isn't broadly appreciated. I'm still learning about why (technically).
-
-
Replying to @stubbornella @dfabu and
Layering is important but
@slightlylate was right years ago when he talked about archaeology. You don't have to build the perfect layering for new stuff, just incrementally make it better.1 reply 0 retweets 5 likes -
Replying to @wycats @stubbornella and
One example: web components were mostly *not* an "explain the web" layering, but rather a bunch of new primitives for building new stuff. In my view, a closer "layering" approach would be to start with stuff like custom elements + extending form serialization.
3 replies 0 retweets 4 likes -
Replying to @wycats @stubbornella and
The "archaeology" point is about making it easier to drop something in without rebuilding quite as much of the whole stack. Service Worker creates network extensibility, which "just works" with <img> and any other declarative feature that uses the network.
1 reply 0 retweets 3 likes -
Replying to @wycats @stubbornella and
This enables general-purpose network strategies to be implemented without reimplementing half the platform. Form serialization is a similar thing.
1 reply 0 retweets 0 likes -
Replying to @wycats @stubbornella and
On the other hand, shadow DOM and HTML imports were mostly boondoggles that didn't do much at all to reduce the amount of cross cutting reimplementation needed in order to add a little bit of new functionality. Features like that don't do so well.
1 reply 0 retweets 1 like -
Replying to @wycats @stubbornella and
Custom Elements != Shadow DOM or HTML imports, and you can extend built-ins in every browser (except one, but there's a ~2.5K polyfill for that https://github.com/ungap/custom-elements-builtin#readme …)
1 reply 0 retweets 1 like -
Replying to @WebReflection @wycats and
Custom elements are pretty universally appreciated, right?
2 replies 0 retweets 0 likes -
Replying to @stubbornella @wycats and
they've been promoted as dependent of Shadow DOM or HTML imports, requiring polyfills that cannot compete with the native API. So while personally I love Custom Elements, the marketing around these has been pretty bad, hence low adoption. Built-in extends are a game changer tho
1 reply 0 retweets 2 likes -
Replying to @WebReflection @stubbornella and
if only *that team* would cut the DX unfriendly reasoning, every framework could benefit from CE built-ins, even JSX, or forms, via <form is="log-in">, as example, or <input is="re-captcha">, so that instead of fighting, better primitives would be adopted all over the ecosystem.
1 reply 1 retweet 1 like
*that team* should hear about it directly from you; cc: @jonathandavis
-
-
Replying to @slightlylate @stubbornella and
trust me, they heard me over and over, and stated over and over they disagree on implementing CE built-in extends. They're lonely in their decision though, as all other vendors ship CE built-ins, so that WK/SF are the only browsers that need my polyfill after feature detection.
1 reply 0 retweets 1 like -
Replying to @WebReflection @slightlylate and
meanwhile, heresy https://github.com/WebReflection/heresy/#readme … and heresy-ssr https://github.com/WebReflection/heresy-ssr/#readme … are based on CE built-in extends, and the library provides JSX like feature, using just standards all over the place. The poly for WK/SF is Custom Element itself
1 reply 0 retweets 2 likes - 2 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.