BUILD REACT INTO THE BROWSER YOU COWARDS

is there a precise element that browsers don't implement?

No thanks

They said this before hooks, and they’ll say it after hooks, too.

What part of React would you like to use in Browsers?

Can you imagine a world where Google admits angular’s defeat by putting React in Chrome?

Can imagine a world where Google have given up on Angular once a year for each of all of its 9 years of its pitiful existence.

This sounds interesting but it would face many problems: which version should the browser carry? What when it’s updated? What happens to users of not-so-new browsers? How about dependencies and packages? Why react and not any other of the many frameworks in the JS landscape?

I remember that call with prototypejs. And later with jquery. And later with ______

We built browser APIs based on both of those technologies.

That wasn’t the call though. People wanted $() for example. They didn’t want partial versions. BTW: $() was a pain when copied from firebug. One returned an element, one returned a stack.

My real position is that there are some stable features within React and common to the other frameworks and we should be looking at promoting them to web APIs. This would allow all the frameworks to get smaller and the web to get faster.

Same argument for jquery (smaller and faster web pages). Jquery had far higher adoption. I’d say only 10% knew $ returned a stack. 😢 It also means the apis can’t change. There is work on built in modules though (KV storage, for example). What react stuff do you propose?

I'm not an expert, but all the frameworks do virtual DOM diffing so making it faster by making it native seems like an obvious win.

The virtual dom being such the “right idea” universally means that it will likely soon be usurped by something new. Vdom will become legacy, and when the modern code hits the frameworks, the old vdom will finally hit the browsers and no one will use it. Deprecated in 10yr.

There's lots of stuff that was useful in browsers 10 years ago that we don't support or use any more. I don't think that's not a reason to implement it. 10 years is a long and useful life.

Not if it will be EOL by the time it ships.

You think it will take 10 years to ship? 5? 2?

Two years. React 19 might be using incremental dom instead of virtual dom by then, since the whole vdom thing is such a memory hog and slow. I see why you would want the browser to do it though.

vdom is a cool experiment and it should have stayed that way.

It's not the browsers that matter, it's the pages. The essential agreement about the internet is that it supports what's been written for it, according to standards, now and forevermore. The browsers are not the internet, they are the merely the displayers of the content.

It's not about "virtual dom" which is an implementation detail it's about "UI as a value", that's the concept we should be encouraging browsers to support

It seems like making it faster by making it wasm would be the more robust strategy? Smaller interface for browser makers, no legacy API to clean up when everyone moves on to something else, still very fast. Also, you could do it today.

I’ve heard of people using web workers, but haven’t seen WASM version. Write in TypeScript and compile with AssemblyScript. Surely someone has tried?

A few tries: @fitzgen

I'm no expert but my impression is WASM->JS message passing is currently not fast enough for this to be an optimization, although work to fix that is well underway.

That's my understanding as well. But surely finishing that work will take less time and be more broadly useful than getting vendors to agree upon, implement, and release a vDom API?

My broader point: Rather than asking for new Web APIs to make XYZ feature fast, I think we should be asking “what prevents wasm from addressing this?” and fixing that (or, if the answer is “nothing,” start rusting up the ol' toolchain).

Smart approach, though I can imagine a world where we are complaining about how much WASM we have to ship to a browser to enable "modern" apps.

Sure, but (1) it'll most likely be smaller than a comparable amt of JS, (2) wasm modules will help separate that code into separately delivered chunks, and CDNs|p2p content networks can help reduce the number of times those go over the wire.

You may well be right.

I mean, I don't doubt we'll have these problems, but I think there's ways to address them, and I'm inclined to be very careful about adding new APIs to what is already an enormous API surface with implementations that are sometimes frustratingly divergent.

OTOH: put Vulkan/Metal/DX in the browser, you cowards! (The trifurcated shape of that aggro demand being, of course, The Problem)

If the end result is that I can throw components together into a web app that is more performant than today I'm agnostic about the implementation method, and your point that this is the shortest path to that goal is well made.

it’s likely JS will be a smaller bundle since (even though it’s not a binary format) it’s a much higher level language

mmm. i feared this might be the case as soon as i said that. alas.

HOWEVER—she said, grasping at straws—this fact implies the existence of a compression scheme which could be as efficient as JS. Perhaps it could *be* JS. Introducing WASMScript...

Somebody beat you to this, and presented it at JSConf EU yesterday.

It actually started that way in the first draft.

Not to mention asmjs

We are working on primitives that can help all (with Facebook/React team and others) twitter.com/shubhie/status…

I saw that! Seems great but also just scratching the surface.

That's only one piece. There are many scheduling APIs, and ways to patch a DOM set and ..... But done in a way that moved the needle for all. I definitely want React to be able to slim down (both in size and runtime etc.... The work in user space is more than everyone would like.

Strongly agreed, and you would certainly have a better idea than I on the best strategy to achieve that goal.

But I like hearing your thoughts and what you want to see! Looking to learn not shut down.

My base position is it would be great if the 65% of devs building things in React could all get a performance (and probably accessibility) boost at the same time by pulling some of the work out of user space. I am mostly agnostic about the implementation.

Yes. It pains me that the current default paths that are used in the ecosystem end up in really slow experiences. It's not about React, but the stacks. We want to help React devs have good results with a happy path.

Also, with respect to "scratching the surface", well, you gotta start somewhere

I think “primitives” is the key term. Perhaps accelerating hot code rather than implementing higher order concepts. Paradigms change.

Svelte, lit-html, HyperHTML don't have or need virtual DOM diffing. It's not unlikely future frameworks will let go of it too

Love lit. It’s so close to “the metal” yet augments things just enough to make them a lot easier to use. I don’t think it has enough evangelists 😁

Not all frameworks do that (it’s slower because of how the DOM APIs work). However, there have been some calls to create batch update APIs that could plug into diffing engines to make them really performant. I like those generic APIs that React and others could take advantage of

That solution would also be fine with me.

Also need to know how dom apis work. Many years ago frameworks started using the dom api to get size information for layouts in JS but did a get then set and put them both in a loop and in tree traversal. 😨🤢🤮 BTW: the get did a browser layout & set cleared the layout cache.

This is a great example actually. Google looked at putting in hooks so layout could happen via custom JavaScript, which would be faster for those frameworks. But frameworks went a different direction and having things like a flex box and grid ment that no-one is asking for it now

Virtual DOM diffing is wasteful and making it native won't change that. It's also entirely unnecessary, and proposals like Template Instantiation achieve the same goals in a much more platform cohesive way.

It's also worth noting that we built *tons* of other stuff into the browser that the median React app uses (Promises, Classes, generators, the rest of ES6) and those apps, to near-unit likelihood, still tax users with polyfills for all of them 🤷‍♂️🤷‍♂️🤷‍♂️

Find me the FB-sponsored/endorsed React starter kit that doesn't tax 97.5% of users for the benefit of the 2.5% and I'll be more convinced that rising the road up to meet them is a worthy cause:

Hell, just show me a React-team endorsed path that doesn't polyfill Object.assign, Promises, and Classes *by default* for the 100% of Android users that don't need them (that is, 80% of mobile) and it'll be a new day.

I've put my oar into this water for these folks for *so* many years, and the retort is "do more or we won't start down the path of mildly inconveniencing ourselves"? @seldo, you're smart, would *you* volunteer the careers of your teammates for that cause given the evidence?

...or perhaps you mean this in the style of "let's put things into the browser so that folks don't need to pick React"? If so, we've got a lot of 'em to pick from already! Lit, Stencil, Preact, Svelte, etc. etc. Interested teams are spoiled for choice.

(And there it goes again @sveltejs!😎)

Native is not a magic "be faster" button. O(n) algorithms are still slow, no matter if they're in C++ or JS.

While this seems like a good idea (and folks from every framework propose it) in practice it's not what developers or framework builders want. Imagine being stuck on React 14 semantics forever! Hooks is a great example. The class API was "stable" too.

I pushed back for years against adding high level framework features to the web natively. Look how much React, Angular, Vue have changed in the past 5 years. Even changing stable APIs (ex. UNSAFE_ deprecation). Frameworks don't want 10+ year lock in but that's how the web works.

web components?

⛔. React isn't about encapsulation (style isolation or any of that). It's about efficient, declarative programming of a mutable object model.

DUMBEST IDEA YET

Great idea, for a few months. Then years of clean up and answering "what were they thinking?"

document.write?

Which part? DOM diffing? The whole component model? Does this include context & hooks?

Would browser standardization of classList and querySelectorAll have been as important if npm had taken off by then?

So probably DOM diffing or perhaps a data structure that enables it, almost certainly not hooks, not sure about the rest.

The web definitely needs a higher level abstraction for components and Web Components do not seem to be it.

👌👌👏👏👏👏👏👏

I can't tell if having the existing web components spec is the problem? But yes, the existence of Svelte.js alone should make this obvious.

Hmm. A document.apply(newDocument) that implements native DOM diffing could make sense.

Are you sure they aren't already? html.spec.whatwg.org/multipage/cust… drafts.csswg.org/css-scoping/ drafts.csswg.org/css-shadow-par… w3.org/TR/shadow-dom/ ...

There is strong appeal from the community towards this spec.

That’s a terrible idea.

Electron is probably a good candidate to start :)

Hard pass for me.

I will like it woulda already happened except we have this web components standard no one knows what to do with.

Eh. Let's just wait, until a react native port, driving the DOM from WASM, doesn't sound like a stupid idea any more 😂

I know it’s 15 years too late, but it should gave been the Flash player.

maybe a virtual dom API

Why not an open standard? You know.... like WebComponents?

Frameworks like React come and go. Standards like Web Components, for all their warts, are baked into the web (browser) and evolve with it. Choosing React or anything that doesn’t ply 100% nice with WC is a losing proposition.

No. No. No.

Yrs ago *Some* browser devs said they would rather to make DOM faster; also they said they don't understand "why frontend devs need frameworks: just using bulit-in APIs!" while they never wrote JS for production website. Although they did JSing: wrote a 16KLOC monster *manually*

So I don't think to ask them to make a builtin react will be a good idea...