I'm afraid you're confusing data structures (such as vectors, sets and maps) with the document model object.
Not even in JS the DOM and objects are the same - some properties of the DOM have 'magical behavior' attached.
ClojureScript does not provide any functional interface to the DOM - that would involve a Haskell-like model of programming (monads etc), which Clojure programmers rarely do in practice.
i don't think i'm confusing anything. Clojure programmers love their persistent data structures, and in a browser environment, the most important data structure - the document model object - is not persistent and cannot be made persistent in a performant manner because it is a native api.
there is ongoing research into dom manipulaton in clojurescript - Conrad Barski presented one approach[1] at Conj 2012 where the dom is mirrored in clojurescript data structures, and then 'synced' with the dom - so that way the imperative ickyness is tucked away in the sync method - it remains to be seen if that can be made fast enough until we get a native persistent interface to the dom.
Modeling side effects as transformations on data is what functional programmers do all day. I'm not talking about monads - simple things like inserting keys into a map and manipulating collections does not rely on side effects in functional languages.
Comments
I'm afraid you're confusing data structures (such as vectors, sets and maps) with the document model object.
Not even in JS the DOM and objects are the same - some properties of the DOM have 'magical behavior' attached.
ClojureScript does not provide any functional interface to the DOM - that would involve a Haskell-like model of programming (monads etc), which Clojure programmers rarely do in practice.
i don't think i'm confusing anything. Clojure programmers love their persistent data structures, and in a browser environment, the most important data structure - the document model object - is not persistent and cannot be made persistent in a performant manner because it is a native api.
there is ongoing research into dom manipulaton in clojurescript - Conrad Barski presented one approach[1] at Conj 2012 where the dom is mirrored in clojurescript data structures, and then 'synced' with the dom - so that way the imperative ickyness is tucked away in the sync method - it remains to be seen if that can be made fast enough until we get a native persistent interface to the dom.
[1] https://github.com/drcode/webfui
Characterizing side-effects as a series of supposedly functional transformations doesn't sound quite alright to me.
That said I'm curious about such an approach.
Modeling side effects as transformations on data is what functional programmers do all day. I'm not talking about monads - simple things like inserting keys into a map and manipulating collections does not rely on side effects in functional languages.