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?
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?
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.
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.
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'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).
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.
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.
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.
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...
It's been really great to work with Facebook on this API proposal! Available in Origin Trial in Chrome 74. Feel free to DM if you want to participate in the Origin Trial and want more info.
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.
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.
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
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.
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.
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.
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.
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*