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 -
Replying to @sebmarkbage @TheLarkInn
Not all of these are likely to be reasonable long term APIs, but broadly I agree. I wrote the extensible web manifesto after all. Service Worker (w/ network intercept, Cache APIs and push notifications) is probably the best success story. Everything else is mixed.
2 replies 0 retweets 2 likes -
Replying to @wycats @TheLarkInn
Honestly, our experience with Service Workers has been very disappointing. It still has so much overhead that negates the effectiveness. Also, still difficult to truly take advantage of long lived large caches across websites to build user space tooling. :(
1 reply 0 retweets 2 likes
Can't have it both ways. As you said, the initial implementation of a secure user exposed primitive like this is gonna be slow. But having network and Cache exposed is a genuinely good start and massively better foundation than app cache.
-
-
Replying to @wycats @TheLarkInn
If you consider being on the right track as a success story, sure. I'll hold my claim of success until it is also fast and can successfully start large code bases from cache immediately.
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Replying to @wycats @sebmarkbage
Security v Speed is technology motif of the day.
0 replies 0 retweets 0 likesThanks. 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.