Comment by ibdknox | Hacker News Reader

Comment by ibdknox | Hacker News Reader

We've been thinking about this a lot lately for some of the projects we've been doing for Light Table and we've essentially been doing the same thing as what David's proposing here.

What react ultimately opens up is a way to do immediate mode UI [1] on top of the DOM _efficiently_, which changes things pretty dramatically. It means we can start to treat the browser as just a renderer and get the infectious design decisions of the DOM out of our programs. If nothing else, this gives us freedom, but as david is suggesting, I think this also gives us an opportunity to treat UI much more directly than we currently are. If you want to know what the state of your UI is, you just have to read linearly down through the code that produces your tree. No nest of dependencies, no state hidden in the UI components, you could even get rid of event hierarchies if you wanted.

More important than anything else, this gives us a chance to dramatically simplify our model for UI and magically be even faster than we were before. Sounds like a win to me.

[1]: http://en.wikipedia.org/wiki/Immediate_mode

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.

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.

Because there are millions of developers who can use the DOM and CSS to create their design and only a handful who can do the same with Canvas.

This argument is correct, but you can take it further:

It's not so much about being able to do it with canvas. It's the fact that you have to reinvent all of your tools on top of canvas.

When you're tying your square wheels together into a big circle so they turn better, it's time to start reinventing.

> 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/

This comparison makes no sense at all.

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.

https://github.com/facebook/react-art

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.

For things that has it's own layout and no text input (like charts/data visualizations) or complex editors like Khan Academy's math content editor (http://bjk5.com/post/53742233351/getting-your-team-to-adopt-...) it definitely makes sense.

"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 thought that "Aurora" would be something like OM :)

Reply on news.ycombinator.com