React itself contains a ton of platform-level duplication, e.g. the events system:https://github.com/facebook/react/tree/master/packages/react-dom/src/events …
-
Show this thread
-
...which is in addition to a great deal of over-polyfilling by default in most of the available toolchains. If you pave a cowpath but nobody uses the road, which lesson should one take from the effort?
1 reply 1 retweet 12 likesShow this thread -
Regardless, there are hardy folks on our team collaborating to add things that the React team says they want but which we don't expose, e.g.
@shubhie's work on scheduling. Because we serve more than one framework (because option #1 isn't "The Plan"), this needs to be generic.1 reply 0 retweets 5 likesShow this thread -
Capabilities we've added over the years live under identical constraints: - must be backwards compatible with existing syntax and semantics - must be usable by any/all developers in granular, layered ways (see: https://extensiblewebmanifesto.org ) - must serve more than one customer
1 reply 2 retweets 16 likesShow this thread -
This, plus standards, makes "just putting something in the browser" much, much, much harder than it looks from the outside (unless you go with #1, which we don't for the previously discussed reasons). We pay a heavy tax for fairness. Is that the right thing to do? Usually, yes.
1 reply 0 retweets 16 likesShow this thread -
...which brings us to #3: starting from the syntax angle. This is where React is *least* able to be integrated. React-flavoured JSX (which is what most people mean by "React") is unlikely to be workable as an addition to the platform w/o major changes.
1 reply 0 retweets 10 likesShow this thread -
JSX is neither HTML nor modern-JS supersetting, meaning you'll need new grammar and parsers. It may not even ben context free. A variant might work, but it *will not* be JSX compatible w/o developers changing their code. ...and if you have to change syntax, why not Lit (e.g.)?
2 replies 2 retweets 14 likesShow this thread -
...and all of that is before we bring in the question of data structures and "diffing". Turns out diffing is slow! Other frameworks are going faster (Svelte, Lit, Vue, etc.) by taking different approaches, but they get similar surface syntax and they are *much* smaller.
2 replies 1 retweet 25 likesShow this thread -
Put yourself in the browser engineer's shoes: you tend a platform that's 20+ years old and which you compete tooth-and-nail on performance about. Someone pitches to you a plan that is slower than other known alternatives and not strict super/sub-setting. Hrm.
1 reply 1 retweet 22 likesShow this thread -
This practice of zooming out ever-so-slightly explains most of the difference in platform vs. app developer behavior in my experience. Platform developers are like Ents; they have responsibility over long time-periods for the things app developers take for granted.
5 replies 8 retweets 61 likesShow this thread
App developers take it for granted that the language doesn't break whenever new browsers are released, that new features are iterative, that things get faster year-on-year without them needing to re-compile their code.
-
-
Platform developers, meanwhile, have incentive to look at the totality of the web rather than the shouty, shiny bits. You know who's a *much* bigger community than React developers? WordPress-ecosystem web developers. What they need matters more, if we're being fair.
5 replies 11 retweets 59 likesShow this thread -
But we listen regardless, and try to balance needs across these differently-geared timescales and balance them with the relatively limited resources available to each individual browser team. We'll keep doing that, no matter what names
@seldo calls us.4 replies 0 retweets 26 likesShow this thread
End of conversation
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.