If what you're saying is "there is potential that this ship could turn", I agree! And I've agreed at every single moment from when I got so frustrated that I had to give a talk like this: https://www.youtube.com/watch?v=4bZvq3nodf4 … ...and still, failure rates of React sites have not decreased.
-
-
Replying to @slightlylate @TaelurAlexis
What do you say to the proposal that browser vendors do an inventory of the most common components in open source (pick, say, 10) and build them into the platform? Obviate the need for frameworks for 90% of use cases. Multi select, simple charts etc
1 reply 0 retweets 1 like -
Replying to @chofter @TaelurAlexis
I am a fan of extending the platform to integrate userland needs....but this has also been my biggest professional failure: I helped push classes, promisies, and other improvements over the line only to see developers (*cough* React *cough*) care more for OldIE than users
1 reply 0 retweets 0 likes -
Replying to @slightlylate @TaelurAlexis
Is anyone driving this? What end user facing component has been added in the last 10 years? Why do custom date pickers even exist?I just hand built yet another multi select component, & don’t get me started on dynamic lists again.... Can we aim for 5 new components a year?
3 replies 0 retweets 4 likes -
I need to write about this, I guess, because this keeps coming up but in short words: I think no. This assumes that the view from the outside about how long any of this takes is accurate - it isn't.
@gregwhitworth@stubbornella2 replies 0 retweets 0 likes -
Replying to @briankardell @chofter and
The past is full of challenges that are different and dysfunction and so on, it isn't a real limit but it is illuminating and helpful in understanding the realities. I talk about this some on https://thewebplatformpodcast.com/195-platforms-and-priorities … andhttps://shoptalkshow.com/407
1 reply 0 retweets 0 likes -
Replying to @briankardell @chofter and
but we can get things in the queue, and do better work via web components to figure this stuff out in a way that is far better aligned with real world economics if you want developer involvement (we do!). Getting things moving (people are trying) will keep mature things coming.
1 reply 1 retweet 3 likes -
Replying to @briankardell @chofter and
I think we could absolutely shoot for a few components a year, and there's no better time than now to start! That said, I'm also not optimistic that it will make a dent on the universe. My experience of tracing sites suggests that the primary effect of ES6 was polyfill bloat.
3 replies 0 retweets 1 like -
Replying to @slightlylate @briankardell and
We don’t have to choose one or the other. If we can solve the problem of form inputs being stuck in the 90s then a huge number of mobile sites simply won’t need frameworks any more, just some even handlers and fetch() calls
1 reply 0 retweets 2 likes -
Replying to @chofter @briankardell and
That as the theory under which I helped design `fetch()`, ES6, WC, etc. etc. etc. I don't mean to be a wet blanket, but there is scant evidence that when an improved version becomes widely available it results in anything more than continued over-polyfilling.
2 replies 0 retweets 1 like
*some* tools do a good job of this! The most heavily used tools do not, which makes sense when you consider over-polyfilling as a DX matter: by insulating you in it, you don't have to think about what to include when. And so we overpolyfill/overtranspile pervasively.
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.