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
-
-
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 -
Replying to @slightlylate @chofter and
this seems the real nature of the problem tho
@slightlylate, as I have argued before. If there was one thing we could do which would make a huge difference it would be to make that story better. It is unfortunately v hard.1 reply 0 retweets 0 likes
Indeed. It's going to require browsers (and others) to be better agents for the user and help create back-pressure to avoid too much code. That isn't the direction of travel, I'm afraid.
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.