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

2015-04-02 Thread Marc Fawzi
Boom! http://pixelscommander.com/en/web-applications-performance/render-html-css-in-webgl-to-get-highest-performance-possibl/ This looks pretty amazing. On Sat, Feb 14, 2015 at 4:01 PM, Brendan Eich bren...@secure.meer.net wrote: Hang on a sec before going off to a private or single-vendor

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

2015-02-14 Thread Brendan Eich
Hang on a sec before going off to a private or single-vendor thread because you think I sent you packing on topics that are of interest (as opposed to Thread-Safe DOM). I'm sorry I missed Travis's mail in my Inbox, but I see it now in the archives. The topics listed at the link he cites *are*

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

2015-02-13 Thread Travis Leithead
://www.w3.org/wiki/Improving_Parallelism_Page -Original Message- From: Boris Zbarsky [mailto:bzbar...@mit.edu] Sent: Wednesday, February 11, 2015 12:34 PM To: public-webapps@w3.org Subject: Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest On 2/11/15 3:04 PM, Brendan

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

2015-02-13 Thread Marc Fawzi
notes). [1] https://www.w3.org/wiki/Improving_Parallelism_Page -Original Message- From: Boris Zbarsky [mailto:bzbar...@mit.edu] Sent: Wednesday, February 11, 2015 12:34 PM To: public-webapps@w3.org Subject: Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

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

2015-02-12 Thread Brendan Eich
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

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

2015-02-12 Thread David Rajchenbach-Teller
On 12/02/15 03:45, Marc Fawzi wrote: this backward compatibility stuff is making me think that the web is built upon the axiom that we will never start over and we must keep piling up new features and principles on top of the old ones this has worked so far, miraculously and not without

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

2015-02-12 Thread Aryeh Gregor
On Thu, Feb 12, 2015 at 4:45 AM, Marc Fawzi marc.fa...@gmail.com wrote: how long can this be sustained? forever? what is the point in time where the business of retaining backward compatibility becomes a huge nightmare? It already is, but there's no way out. This is true everywhere in

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

2015-02-12 Thread Brendan Eich
Aryeh Gregor wrote: This is all horrible, but that's life. Indeed, nature is nasty. Search for sacculina carcini life cycle for but one example. The Web and the Internet are evolving systems with some parallels and analogies to biological evolution. See http://www.cc.gatech.edu/~dovrolis/

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

2015-02-12 Thread Brendan Eich
Brendan Eich wrote: over-the-top work Apologies if this overloaded trope is confusing without more context -- it could mean wildly excessive, or doing what soldiers in trenches did in WWI when the whistle blew (see https://www.youtube.com/watch?v=fssPqRWx9U0 :-/), but I meant build on top

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

2015-02-12 Thread Marc Fawzi
Legacy problems Across the computing industry, we spend enormous amounts of money and effort on keeping older, legacy systems running. The examples range from huge and costly to small and merely annoying: planes circle around in holding patterns burning precious fuel because air traffic control

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

2015-02-11 Thread Brendan Eich
Marc Fawzi wrote: even if the DOM must remain a single-threaded and truly lock/barrier/fence-free data structure, what you are reaching for is doable now, with some help from standards bodies. ***But not by vague blather*** Sorry, I was too grumpy -- my apologies. I don't see much

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

2015-02-11 Thread Boris Zbarsky
On 2/11/15 3:04 PM, Brendan Eich wrote: If you want multi-threaded DOM access, then again based on all that I know about the three open source browser engines in the field, I do not see any implementor taking the huge bug-risk and opportunity-cost and (mainly) performance-regression hit of

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

2015-02-11 Thread Boris Zbarsky
On 2/11/15 9:45 PM, Marc Fawzi wrote: this backward compatibility stuff is making me think that the web is built upon the axiom that we will never start over and we must keep piling up new features and principles on top of the old ones Pretty much, yep. this has worked so far, miraculously

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

2015-02-11 Thread Marc Fawzi
this backward compatibility stuff is making me think that the web is built upon the axiom that we will never start over and we must keep piling up new features and principles on top of the old ones this has worked so far, miraculously and not without overhead, but I can only assume that it's at

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

2015-02-11 Thread Tab Atkins Jr.
On Thu, Feb 12, 2015 at 1:45 PM, Marc Fawzi marc.fa...@gmail.com wrote: this backward compatibility stuff is making me think that the web is built upon the axiom that we will never start over and we must keep piling up new features and principles on top of the old ones Yup. this has worked