- From: Marc Fawzi <marc.fawzi@gmail.com>
- Date: Tue, 10 Feb 2015 19:01:35 -0800
- To: Brendan Eich <brendan@secure.meer.net>
- Cc: Jonas Sicking <jonas@sicking.cc>, Michaela Merz <michaela.merz@hermetos.com>, Florian Bösch <pyalot@gmail.com>, Glenn Adams <glenn@skynav.com>, Ashley Gullen <ashley@scirra.com>, George Calvert <george.calvert@loudthink.com>, "public-webapps@w3.org" <public-webapps@w3.org>
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. 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. 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. 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? Also I was mentioning immutable and transient types because they are so necessary to performant functional programming, as I understand it. 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. 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 really don't understand the arrogance here. Sent from my iPhone > On Feb 10, 2015, at 6:43 PM, Brendan Eich <brendan@secure.meer.net> wrote: > > Your message to which I replied is not cited accurately below by you. The text you wrote is here, in between """ lines: > > """ > How about a thread-safe but lock-free version of the DOM based on something like Clojure's atom? So we can manipulate the DOM from web workers? With cursor support? > > How about immutable data structures for side-effect-free functional programming? > > How about .... Will think of more > """ > > This message text is exactly what I wrote my reply against. > > It's useless; sorry, this happens, but don't make a habit of it, or most practitioners will unsubscribe to public-webapps. The DOM is a mutable single-threaded store, so there's no lock-free version possible. You'd have snapshots, with some cost in the snapshotting mechanism, at best. Then, you wouldn't be able to "manipulate" in any shared-state sense of that word, the DOM from workers. > > Sorry, but that's the way things are. Dropping words like immutable and lock-free doesn't help. That, plus a lot of attitude about deprecating sync XHR (on all sides; I'm not in favor of useless deprecation, myself -- good luck to browsers who "go first" on actually *removing* sync XHR support), adds up to noise in this list. What good purpose does noise to signal serve? > > /be > >> Marc Fawzi <mailto:marc.fawzi@gmail.com> >> February 10, 2015 at 6:24 PM >> What? a good cop bad cop routine? Jonas asks for a constructive contribution or ideas for missing functionality in the web platform and the inventor of JS honors me with a condescending response, as if ... >> >> What the hey! Mr. Eich! >> >> I guess this explains the origin of JS: a knee jerk reaction to then-trendy ideas... >> >> That's not the way to go about all inclusive debate. >> >> Thank you. >> >> Sent from my iPhone >> >> >> Brendan Eich <mailto:brendan@secure.meer.net> >> February 10, 2015 at 5:44 PM >> Please stop overloading public-webapps with idle chatter. >> >> React and things like it or based on it are going strong. Work there, above the standards. De-jure standardization will follow, and we'll all be better off for that order of work. >> >> /be >> >> >> >> Marc Fawzi <mailto:marc.fawzi@gmail.com> >> February 10, 2015 at 12:51 PM >> i agree that it's not a democratic process and even though some W3C/TAG people will engage you every now and then the end result is the browser vendors and even companies like Akamai have more say than the users and developers. It's a classic top-down system, but at least most debates and discussions happen over open-access mailing lists. >> >> I wish there was an app like Hacker News where browser vendors via W3C, TAG, webapps etc engage users and developers in discussions and use up/down votes to tell what matters most to users and developers. >> >> But design by committee is really hard and sub-optimal, and you need a group of true and tried experts (open minded ones) to call the shots on various technical aspects. >> >> >> >> >> >>
Received on Wednesday, 11 February 2015 03:02:05 UTC