W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

From: Brendan Eich <brendan@secure.meer.net>
Date: Thu, 12 Feb 2015 11:33:56 -0800
Message-ID: <54DD0024.9060708@secure.meer.net>
To: Marc Fawzi <marc.fawzi@gmail.com>
CC: Aryeh Gregor <ayg@aryeh.name>, Boris Zbarsky <bzbarsky@mit.edu>, public-webapps <public-webapps@w3.org>
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


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
Received on Thursday, 12 February 2015 19:34:31 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:25 UTC