Thread by @slightlylate

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 syntax

https://twitter.com/seldo/status/1135150260425318400

@seldo The first is a re-casting of the old "why don't you put jQuery into the browser?" saw. This doesn't work for a few reasons, starting with compat. Which version *specifically*? We can't bloat our binary infinitely, so there are limits. Does everyone get upset when we evict one?

@seldo Next, security updates will now require browser engineers to pay attention to all the ways in which a specific bit of 3p code can be subverted and tend to updates accordingly...updates that can break users. This is a big tax.

@seldo But the biggest reason we never did this with jQuery (and it likely holds for React) is that *not enough people use the same version*. There's a constituency that looks like "all jQuery developers", but when you look at it closely, it's a small, narrow per-version constituency.

@seldo ...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.

@seldo 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.

@seldo 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!

@seldo ...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):

reactjs.org/docs/create-a-…

It's a bloody shame.

@seldo React itself contains a ton of platform-level duplication, e.g. the events system: github.com/facebook/react…

@seldo ...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?

@seldo 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.

@seldo @shubhie 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: extensiblewebmanifesto.org)
- must serve more than one customer

@seldo @shubhie 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.

@seldo @shubhie ...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.

@seldo @shubhie 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.)?

@seldo @shubhie ...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.

@seldo @shubhie 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.

@seldo @shubhie 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.

@seldo @shubhie 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.

@seldo @shubhie 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.

@seldo @shubhie 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.