Imperative coding may be useful to for implementing the API, but that does not mean it is necessary to expose an imperative API to developers. For example, in the browser, W3C and the browser vendors could have exposed a React-like API, implemented via an imperative internal C++ API, but instead they just gave us the DOM. I'm not saying that to complain, just to illustrate that how an API is implemented doesn't have to dictate the API you expose.

> It's funny that one of React's core ideas is to ditch the now old functional/declarative paradigm that is template languages and allows you to use imperative JavaScript to directly build up a virtual DOM.

Its agnostic about how you build up the virtual DOM, but it is common to it in a functional way, for example:

  this.props.searchResults.map(this.renderSearchResult)

I don't think that's true. Under the mutable UI trees, 60 times a second the entire UI is rendered from scratch in the OpenGL (or similar) layer. It seems to me it would be possible to completely skip that part by making a new React-like OpenGL renderer.

I agree with that idea. In my view I think Skia method calls are like assembly and virtual DOM is like a high level programming language. So I decided to try one https://github.com/Quamolit/ my original idea was to write in React way but generates operations that can be finished with Canvas API.

I found it quite hard to finish such a project though. Browser vendor are more likely doing the job of abstracting out hardware and OS powers so people can utilize. There's still much more effect to be done to create an FRP-like(functional reactive programming) system that everybody is happy with.