I'm not buying this argument. Can you unpack it more, especially as it relates to people who are developing content for the web?
-
-
Replying to @wycats
The quality of primitives on the web is poor. E.g. contextual menus, stack navigation, buttons, video controls, infinite scrolling lists with context, date pickers etc. This was known before the mobile era. Many reimplementations of <select /> and jQuery UI solved a real problem.
4 replies 2 retweets 15 likes -
Replying to @sebmarkbage
Every reimplementation of <select> on the web since the beginning of time that I have come into contact with has made my experience worse. It got even worse on mobile. Flex was not an improvement.
2 replies 0 retweets 10 likes -
Replying to @wycats
Fair but native <select> is also terrible. If we built web with only native components we'd never get a decent experience. That's my point. We shouldn't necessarily rely on people reimplementing. The browsers could do it but they have to try harder.
1 reply 0 retweets 5 likes -
Replying to @sebmarkbage @wycats
The status quo is that both browsers and JS ecosystem are doing a poor job. The JS ecosystem often has an excuse because we don't have access to the primitives that are needed. That's not to say that it would be good even if we did. The game theory might not align.
2 replies 0 retweets 6 likes -
Replying to @sebmarkbage @wycats
One exception is scrolling and things like position: sticky. That's an area where browsers focused on using their leverage to build one UI component well. (Although they also didn't give us the control to fix it ourselves.) But that's just one of many features that needs fixing.
1 reply 0 retweets 3 likes -
Replying to @sebmarkbage @wycats
Couldn't agree more with Seb here. WC relatively was never what developers wanted but what some browsers wanted to try and work around _them_ needing to solve the above problem. Better primitives are what developers want and need, at the platform level, not API/WC level.
2 replies 0 retweets 2 likes -
Replying to @TheLarkInn @wycats
It might be possible for developers to solve this in user space but what we need is not WC/convenience APIs. We need access. Access to compositor threads, access to cache, access to hardware, access to local data, access to OS level UI outside the browser frame...
2 replies 0 retweets 7 likes -
These are hard problems to solve while also retaining the security model of the browser. Therefore it is probably *easier* for the browsers to just do it themselves.
2 replies 0 retweets 2 likes -
Replying to @sebmarkbage @wycats
Precisely. Maybe the solution is surfacing a shared OSS lib that allows much of this to be open and rapidly developed and not as "time and work" intensive to create more of these primitives. (And no that's not what WC are)
1 reply 0 retweets 3 likes
I mean web components were a sham of an extensible web primitive. Over time, they inched closer, but from the moment they entwined CSS isolation with event retargeting and tried to solve the "brain transplant" problem they were out of the "extensible primitive" business.
-
-
Does a library like
@skate_js manage to work around that particular flaw in WC?0 replies 0 retweets 1 likeThanks. Twitter will use this to make your timeline better. UndoUndo
-
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.