I disagree and would feel frustrated if the browser baked DOM diffing directly in. Two reasons: 1. DOM diffing is one of many viable approaches and not very hard to implement 2. React reconciliation is a heuristic (not an algorithm shared in precise details even by vdom folks.)
-
-
The primitive that is needed is: This is a representation of how I'd like the DOM to look. Please make it so.
3 replies 0 retweets 4 likes -
Replying to @cramforce @wycats and
I think
@dan_abramov himself basically said that the “please make it so” thing you’re describing wouldn’t be useful for React, for a variety of reasons. These proxy discussions about which bits of React should be in DOM do without asking the React themselves seems weird to me.1 reply 0 retweets 1 like -
Replying to @mikesherov @cramforce and
Should be a pretty strong signal that React team is not asking for VDOM or whatever in the browser.
2 replies 0 retweets 2 likes -
Replying to @mikesherov @cramforce and
Every day on jQuery I was asking for more stuff in the browser, because the solutions had a lot of overlap. React has asked for none (except scheduling) because there isn’t as much overlap.
1 reply 0 retweets 2 likes -
Replying to @mikesherov @cramforce and
So then why is your conclusion that the web shouldn't pursue this? The fact that React doesn't overlap as much with the web just means that the web (community) has to pursue this on our own without their direct involvement.
1 reply 0 retweets 1 like -
Replying to @matthewcp @cramforce and
The fact that we *think* we want it is because we see React’s dominance with the idea, and their insight as to why they don’t think it’s better in the browser is *key*. Also, web standards are purposely very slow. What we need in the DOM across all FWs isn’t well understood
2 replies 0 retweets 0 likes -
Replying to @mikesherov @cramforce and
I don't think they are really in favor of any user-facing features in the browser; only really super low-level stuff that only frameworks would ever use. Their goal is not to improve ergonomics of web APIs so they can't be looked to for guidance there.
1 reply 0 retweets 0 likes -
Replying to @matthewcp @mikesherov and
Lots of frameworks bet on high-level web platform features all the time, and many adopted classes, promises, arrow functions, etc. We have responsibility to improve across the spectrum.
1 reply 0 retweets 0 likes -
Replying to @slightlylate @matthewcp and
Ok so are you arguing for or against react in the browser.
1 reply 0 retweets 0 likes
Less arguing than listening, but in general, we should put things in the browser that: - developers will use, in the hopes that... - use will lead to smaller wire costs, and... - more room to optimise in the runtime
-
-
Replying to @slightlylate @mikesherov and
Or said another way, we should put whatever bits of React and JSX-ish systems into the browser *that frameworks will actually adopt*. Thus far, the pattern with React has been that we put things into the browser and library doesn't shrink because IE9
1 reply 0 retweets 0 likes -
Replying to @slightlylate @matthewcp and
100%. That’s why I think excluding React from the convo is a non starter (not saying you suggested it
@slightlylate). I know you and I both believe in extensible Web manifesto, which requires close collab between browsers and framework authors.1 reply 0 retweets 0 likes - 1 more reply
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.