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

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

You're contradicting yourself within a single two-line paragraph, being
vague in your own statement ... that what I'm reaching for is doable.

I know you know what you're talking about and I know what I'm reaching for
is doable.

What I don't know are the details of how that might be doable. I think a
lot of developers would be interested in that. Not just me. I think you
dropped some hint there but it's no where near a detailed and clear answer,
so again shutting down the discussion because you know more? What the hey!
Mr. Eich. This is a public discussion forum. If it wasn't open to the
public, it would be private. In discussions, vagueness is not the enemy of
the truth, only part of the journey... Relax.

On a more serious basis, please provide us with clarity or point us to
discussions on this topic that might help us understand how to get _to_
there!




On Tue, Feb 10, 2015 at 7:19 PM, Brendan Eich <brendan@secure.meer.net>
wrote:

> Marc Fawzi wrote:
>
>> I've recently started using something called an atom in ClojureScript and
>> it is described as a mutable reference to an immutable value. It holds the
>> state for the app and can be "safely mutated" by multiple components, and
>> has an interesting thing called a cursor. It is lock free but synchronous.
>> I think I understand it to some degree.
>>
>
> The win there is the mutations are local to the clients of the atom, but
> the underlying data structure it reflects is immutable. The DOM is not
> immutable and must not be for backward compatibility.
>
>  I don't understand the implementation of the DOM but why couldn't we have
>> a representation of it that acted like the atom in clojure and then write
>> the diff to the actual DOM.
>>
>
> Because browsers don't work that way. I wish they did, but they can't
> afford to stop the world, reimplement, optimize (if possible -- they will
> probably see regressions that are both hard to fix, and that hurt them in
> the market), and then restart the world.
>
>  Is that what React does with I virtual DOM? No idea but I wasn't dropping
>> words, I was describing what was explained to me about the atom in clojure
>> and I saw parallels and possibility of something similar in JS to manage
>> the DOM.
>>
>
> I'm a big React fan. But it can virtualize the DOM using JS objects and do
> diffing/patching, without having to jack up the browsers (all of them; note
> "stop the world" above), rewrite their DOMs to match, and get them
> optimized and running again.
>
>  With all the brains in this place are you telling me flat out that it is
>> impossible to have a version of the DOM (call it virtual or atomic DOM)
>> that could be manipulated from web workers?
>>
>
> I'm not. People are doing this. My explicit point in a previous reply was
> that you don't need public-webapps or browser vendors to agree on doing
> this in full to start, and what you do in JS can inform smaller, easier
> steps in the standards body. One such step would be a way to do sync i/o
> from workers. Clear?
>
>  Also I was mentioning immutable and transient types because they are so
>> necessary to performant functional programming, as I understand it.
>>
>
> Sure, but we're back to motherhood-and-apple-pie rhetoric now.
>
>  Again the clojure atom is lock free and synchronous and is mutable and
>> thread safe. Why couldn't something like that act as a layer to hold DOM
>> state.
>>
>
> First, lock-free data structures are not free. They require a memory
> barrier or fence, e.g., cmpxchg on Intel. Study this before endorsing it as
> a free lunch. Competing browsers will not add such overhead to their DOMs
> right now.
>
> Second, 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, and
> nothing to do with sync XHR, to get back on topic.
>
>    Maybe that's how React's virtual DOM works? I don't know but I find the
>> idea behind the atom very intriguing and not sure why it wouldn't be
>> applicable to making the DOM thread safe. What do the biggest brains in the
>> room think? That's all. A discussion. If people leave the list because of
>> it then that's their right but it is a human right to speak ones mind as
>> long as the speech is not demeaning or otherwise hurtful.
>>
>
> I think you're on the wrong list. This isn't the place for vague albeit
> well-intentioned -- but as you allow above, uninformed ("I don't know") --
> speculations and hopes.
>
>  I really don't understand the arrogance here.
>>
>
> Cut it out, or I'll cite your faux-humility as tit-for-tat. We need to be
> serious, well-informed, and concrete here. No speculations based on
> free-lunch (!= lock-free) myths.
>
> As for sync XHR, I agree with you (I think! I may be misremembering your
> position) that compatibility trumps intentions on the Web. This favors the
> React "built it in JS on top" approach, with future DOM (and other, e.g.
> WebComponents) standards following fast.
>
> /be
>