The system described in the article is very React-like, and could be used by future versions of React. In both, functions return a description of HTML to render, which can be applied either to create new HTML or to update previously rendered HTML.
I skimmed part of it, but unless I missed some huge caveat I think you’re backwards and GP is definitely right. The article mentions React, then sort of dismisses it later saying the other two strategies are better to implement instead of diffing.
I don’t see any reason a browser level “here’s new DOM you diff and apply it” couldn't exist and be a huge win for React and other libraries, with React so much more popular than every other framework combined, and that being a pretty low level API, it makes sense to start there.
Building the overly abstracted thing first is a mistake web API authors have made too many times (see web components).
I skimmed part of it, but unless I missed some huge caveat I think you’re backwards and GP is definitely right. The article mentions React, then sort of dismisses it later saying the other two strategies are better to implement instead of diffing.
I don’t see any reason a browser level “here’s new DOM you diff and apply it” couldn't exist and be a huge win for React and other libraries, with React so much more popular than every other framework combined, and that being a pretty low level API, it makes sense to start there.
Building the overly abstracted thing first is a mistake web API authors have made too many times (see web components).