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.
-
-
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 -
Replying to @slightlylate @0xcda7a and
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.1 reply 3 retweets 22 likes
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.
-
-
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 -
Replying to @wycats @slightlylate and
JS frameworks participate in an economy of mindshare. The more mindshare, the more contributors/ecosystem influence available to the framework builder, w/ compounding network effects. Interop comes with risk to mindshare, so I would be surprised if it is ever seen as a good fit.
3 replies 1 retweet 8 likes - 40 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.