Ignoring @seldo's intemperate, self-owning ad-homenim, let's consider what it might mean...there are many versions! A few:
1.) *literally do exactly this*
2.) add building blocks
3.) start from syntaxhttps://twitter.com/seldo/status/1135150260425318400 …
-
-
...which gets to our interest. The benefit to browsers from integration is potential for efficiency; less code on the wire. Current JS ecosystem practice (which
@seldo's product has done more than any other to exacerbate) is to externalize costs onto users at runtime.Show this thread -
That's not great for the ecosystem we tend, particularly at the low end (where most users but few developers are). So we'd need to be pretty convinced that we were picking the "right version" to pre-integrate. Thus far, there isn't strong reason to believe such a thing exists.
Show this thread -
As for bringing up the platform to meet libraries (#2), we've been hard at work on this! Modern, responsible frameworks have taken advantage of the work I and my team ("Parkour") did from '10-'15, removing polyfills and bloat in favour of modern ES and DOM. It's great!
Show this thread -
...but React isn't on this list today, at least not as practiced by the tools their team recommends developers start with (Next being the best of the bunch): https://reactjs.org/docs/create-a-new-react-app.html … It's a bloody shame.
Show this thread -
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?
Show 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.Show 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
Show 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.
Show 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.
Show 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.)?
Show 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.
Show 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.
Show 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.
Show 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.
Show this thread -
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.
Show 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.Show 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.