Marc Fawzi wrote:
This guy here is bypassing the DOM and using WebGL for user interfaces

He even has a demo, with no event handling other than arrow keys at this point, and as the author admits ugly graphics, but with projects like React-Canvas (forget the React part, focus on Canvas UIs) and attempts like these it looks like the way of the future is to relegate the DOM to old boring business apps and throw more creative energy at things like WebGL UIToolKit (the idea that guy is pursuing)

I know Rik and keep in touch. OneJS is the kind of over-the-top work (not changing the DOM in-situ) that I recommended previously, in addition to incremental Web evolution. So once again, I'm not sure we disagree, but I am pretty sure your posts are misdirected to this list. Philosophizing about backward compatibility painting the Web into corners that kill it don't really move anything forward here.

There is a gap to fill with respect to the GPU, which WebGL-based toolkits won't bridge. I think Rik would agree that we can't replace the web with raw JS+WebGL. Meanwhile, since the first iPhone, the major engines have all offloaded parts of their CSS rendering to the GPU (ideally with a big shared texture memory, bigger than the display viewport), in order to use a separate thread from the main UI event loop thread, for 60fps touch response.

Of course the CPUs (multicore + SIMD) need to be used, so we don't want to marry a paritcular processing unit, or (worse) one GPU microarchitecture. Standards and even languages/toolkits (one.js is young) need to mature and abstract enough over hardware variation to be worth their weight -- but not so much they collapse like all the big OOP skycastles of the Java UI toolkit era have.

The more we can do with incremental standards to expose this OMTC/A CPU+GPU-based computation in first class ways on the Web, the less anyone will have to make a "old wolf or new tiger" decision between Web and non-Web approaches.

One concrete example: custom view scrolling. See

If we can focus on these sorts of proposals and not "thread-safe DOM" or will-backward-compat-kill-the-Web imponderables, we'll get somewhere better, sooner.


P.S. Meanwhile, are we done (for now) with deprecate-sync-XHR angst, and no browser actually plans to remove it? Not directed at Marc, rather my cc: list browser buddies. :-P

Reply via email to