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
