Marc Fawzi wrote:
This guy here is bypassing the DOM and using WebGL for user interfaces
https://github.com/onejs/onejs
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
http://robert.ocallahan.org/2014/07/implementing-scroll-animations-using.html
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.
/be
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