...to take both arguments to the extreme; JavaScript and the <canvas> element exist so we can all pack up and go home. I've said that numerous times to colleagues when talking about CSS color functions, CSS Grid, custom properties, new HTML elements & styling, etc.
-
-
Replying to @gregwhitworth @Rich_Harris and
Ultimately, it's a fine line and I think as long as the folks are creating solutions, getting feedback and ensuring that they're building something people want to use - then I say carry on. IF that isn't happening then we're just creating bloat not only to the binaries but...
1 reply 0 retweets 3 likes -
Replying to @gregwhitworth @Rich_Harris and
...also to webdev ramp up, our own engineers having to maintain the code for patches, etc. So it's in everyone's best interest to continue to collaborate :)
1 reply 0 retweets 3 likes -
Replying to @gregwhitworth @slightlylate and
I get what you're saying, but whereas 'these features could be designed differently' is considered valid collaboration, 'these features are unnecessary' doesn't seem to be
3 replies 0 retweets 5 likes -
Replying to @Rich_Harris @gregwhitworth and
Let's break this down. On one hand, could argue that there is an opportunity cost; that there's some other thing you wish these particular engineers had done instead of this feature. Can you identify it? On the other, classic non-rival goods. Perhaps not for you, but
1 reply 0 retweets 2 likes -
Replying to @slightlylate @Rich_Harris and
Put differently, folks building a system have heavy users who say "we have this problem", then work to solve it. If folks who *don't* have that problem say "WTF?", it seems incumbent on the latter population to present some argument as to why that *is* constructive.
1 reply 0 retweets 2 likes -
Replying to @slightlylate @Rich_Harris and
Generalized detraction isn't contribution. Specific proposed alternatives are. What are those?
1 reply 0 retweets 4 likes -
Replying to @slightlylate @gregwhitworth and
I wasn't talking about opportunity cost, I was talking about the fact that adding features *itself* has cost. Scroll up!
1 reply 0 retweets 2 likes -
Replying to @Rich_Harris @gregwhitworth and
Oh, I got that. Asking for specific alternatives. Do you have a rubric for importance that would pierce your threshold?
1 reply 0 retweets 1 like -
Replying to @slightlylate @gregwhitworth and
idk, 'can't be implemented in userland' + 'doesn't have a sensible alternative proposal'
2 replies 0 retweets 2 likes
The memory + perf savings for Constructible Stylesheets meet this bar.
-
-
Replying to @slightlylate @Rich_Harris and
My own take-these new web APIs, some of which may indeed be impossible w/o engine support, presuppose that the existing Web Component APIs are fully baked and ubiquitous. Meanwhile, per AMP announcement/discussion, it’s unclear if WC APIs are actually solving real-world problems
1 reply 0 retweets 1 like -
Replying to @jkohlmann @slightlylate and
The AMP announcement was unrelated to web components. They are still using web components. It's solving real-world problems for them (as evidenced by the fact that they are using them).
1 reply 0 retweets 4 likes - 7 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.