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
It's true that <template> and HTML Imports were new concepts, but basically everything else under Web Components explains the web platform. Apparently someone thought it would be nice if we also had a coherent bundling format and fewer tools.
1 reply 0 retweets 1 like -
It’s maybe a question of whose cow paths got paved? Maybe this paved browser cow paths and exposed internals rather than paving ecosystem cow paths? (To be fair the ecosystem was a lot less sophisticated a decade ago)
1 reply 0 retweets 1 like -
Replying to @stubbornella @wycats and
An essential agreement of the EWM seemed to be that these cowpaths overlapped more often than not. As implementers explain more of the platform, it was assumed this would free libraries to do the hard API design work while implementers focused on perf.
1 reply 0 retweets 2 likes -
Replying to @0xcda7a @stubbornella and
Maybe we were a speaking the same language but hearing different messages..
1 reply 0 retweets 0 likes -
Replying to @0xcda7a @stubbornella and
OTOH I wouldn't say that Web Components set out to pave implementer-specific cowpaths. Maybe they paved Chrome's (I wasn't there at their inception, so I wouldn't know). But let's not forget that Web Components were met with a fair amount of contention by other implementers.
1 reply 0 retweets 3 likes -
Replying to @0xcda7a @stubbornella and
I think the designers were working in good faith to explain e.g., how <video> has complex internal UI that cannot be directly styled; the life-cycle of DOM elements; how psuedo-selectors work. I believe they did this so that frameworks could also do these things without hacks.
1 reply 0 retweets 7 likes -
Replying to @0xcda7a @stubbornella and
That's certainly how we aspired to work. We weren't inventing the new so much as doing the archeology of the existing.
1 reply 0 retweets 4 likes
This, BTW, is why reducto absurdum arguments about "but you still need a (tiny) framework, so WC failled!!!!" always cause me to 

Goal wasn't to replace all framework value. Goal was to enable the sort of seamless interop that DOM has and move FW work/value up the stack.
-
-
Replying to @slightlylate @0xcda7a and
Web Componemts were never about winning a framework battle; they're about allowing FWs to have *different*, better debates at lower local (FW size) and global (interop) cost.
1 reply 4 retweets 23 likes -
Replying to @slightlylate @0xcda7a and
And yet frameworks weren't really part of the discussion and in general agree that WCs are a poor fit for our interop needs.
4 replies 0 retweets 9 likes - 41 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.