Re: do not deprecate synchronous XMLHttpRequest

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

Received on Wednesday, 11 February 2015 03:20:07 UTC