If you want to do immediate mode, then why would you use the DOM at all? Canvas is supported in IE9+, and is much less complicated for such applications.
I'm uncertain that having to reimplement all your high-level drawing routines by hand and figuring out how to handle responsive and reimplementing all activation and behaviors on top of that is less complicated than just using what the DOM provides.
Even text wrapping must be done by hand when you're using canvas.
I've written text wrapping and responsiveness code for canvas, in javascript - I don't think the complexity is even of the same order of magnitude as React or Angular.
What about line height? Judging by some of the responses I've seen on Stackoverflow, calculating this involves running a loop and querying the pixel colours from the canvas's buffer; a very ugly hack, if you ask me!
line height is straightforward enough, if you draw text with line height on N then you should move N pixels down for the next line.
Text baseline is the tricky part - if you want to e.g. put a taller piece of text next to a shorter one, then they should be put together so they share a baseline, but there's no decent way to get the text baseline.
The hack I use is to draw the text in a hidden span, and put a 1px inline-block span next to it, and check where the 1px span ends up. This works though it is ugly.
Why don't you precompute the space things use, including the text that is drawn using a matrix? You could easily calculate the baseline of anything by just doing matrix multiplications then.
However, I think you would still end up using a hack. The general idea of creating a replacement for the DOM has bugged me for a while too. It is a great to replace the DOM completely by a statemachine, I think. We need a New Document Model that supports "Batch Operations", is "Stateful" and uses the latest best performing algorithms published to do so.
Components are the CORRECT way, I fully agree with the facebook team here.
It seems that there is one guy who ALREADY DID all those things and replaced the DOM by something that's more akin to 2013's technology requirements. Link: http://www.nidium.com/
We have a tool that does Canvas drawing from React too. Currently some pieces are cached in retained mode but it's just an implementation detail for certain performance characteristics.
Canvas APIs are currently not as fast as the DOM renderer. There's also a lot of added complexity with regards to layout, text flows and text input. The code you'd have to ship down to solve all that with pure Canvas isn't worth it for a lot of applications.
There are many cases (e.g. accessibility for people using screen readers) where having your web site be a machine-parseable document is very valuable. There are cases where using Canvas for everything makes sense, but having it be the default feels like a step back in many respects.
"Immediate mode" is used as a metaphor here. He doesn't want to actually do graphics work. He wants to send things out to get drawn and have them get batched up appropriately and only rendered when needed.
The goal isn't to do immediate mode, it's to implement UI in the simplest manner possible. Throwing away the DOM and reimplementing significant parts of its functionality in Canvas doesn't make life simpler.
I'm uncertain that having to reimplement all your high-level drawing routines by hand and figuring out how to handle responsive and reimplementing all activation and behaviors on top of that is less complicated than just using what the DOM provides.
Even text wrapping must be done by hand when you're using canvas.