Shared publicly  - 
a functional programing architecture on JavaScript/DOM
xah rumination extempore, episode №20131208194112

am gonna type as fast as i can here…

so, today i've been reworking on some of my tutorials on JavaScript/DOM scripting. For example:

JavaScript: Most Frequently Used DOM Methods

and for example, you can use document.getElementById(id) to get a element, then you can use methods such as insertBefor(), and also properties such as firstChild, nextSibling, … etc to work on it.

i always believed that computer languages or most tech don't need object oriented programing. Functional programing should be sufficient. ( for example, see What are OOP's Jargons & Complexities (OOP as Functional Programing) )

So, it occured to me, how'd i do this if it is FP?

that is, DOM is a OOP system. You have objects, and it have methods. It's a big OOP. What would be a FP system of DOM be like? So, i went on to think about that, and in 20 min roughly sketched out.

so, to do the same, as if DOM is a FP architecture, it's like this.

you use a function named
getElementById() to get a element.
this function will take 2 args, first is a data of a particular type, let's call it “document”, which represent a parsed html source code. The second arg would be the usual id.

So, a example call would be like this:
getElementById(document, "x2938")
to get a element.
the “document” there is a global, predefined variable. It is set when the FP DOM system finished parsing the html. (not much different as in OOP DOM)

then, how'd one call the method nextSibling if there's no method?

it's like this. call the function nextSibling(). It'll take one argument, a data of type node.

… so, i think the above is pretty much it. A FP architectured DOM. No OOP “objects” or “methods”. It's just all functions, and data types. The different data types corresponds to different “objects” in dom. And, we have a set of functions. Each, takes parameters, and the parameter much match type, as usual.

just a quick thought. Did i miss anything that'd be problematic for a FP DOM?

addendum: extended, on correspondence to OOP's notion of hierachy, data/methods grouping, reference vs serialization, at
syntax, meaning. node .previousSibling, Return the previous sibling of node , or null if it doesn't exist. node .nextSibling, Return the next sibling of node , or null if it doesn't exist. node .childNodes, Return all children of node as a list. node .firstChild, Return the first child of node .
Nick Alcock's profile photoIvan Pierre's profile photoYuri Khan's profile photoXah Lee's profile photo
For the FP/OO difficulty you typically have the expression problem. Whatever side you take it you're stuck  :D
That looks exactly the same as the OOP DOM except that you've rewritten A.B(C) into B(A,C). You realise that this doesn't make it not OOP, right? That there are entire languages, including some of the first OOP languages, whose only way of calling B on A was B(A,C)?

(I would say that it is more using method containment than full-blown OOP anyway. No polymorphism or inheritance in sight. But those don't seem to be what you're complaining about.)
Xah Lee
+Ivan Pierre thanks a lot. A very nice link. Don't understand it off hand, will have to dig in later.
DOM is in fact a functional data structure, namely, a tree of nodes. Each node can be a text node, an element, or an attribute (or more types which are often ignored, such as comments, processing instructions, character and entity references). There is a restriction that a text cannot have children and an attribute can only have a single text as its child.

To shoehorn DOM into an OOP setting, it was augmented with mutation operations. Without that, we would need to extract parts of the tree and construct a different tree out of them. I believe there are Haskell libraries for DOM manipulation, and I won’t be surprised if they do it this way — the pure functional way.

As for OOP concepts of polymorphism and inheritance, they are not very useful for DOM. Inheritance allows Element to inherit all child-related interface from Node, but TextNode has to inherit it too and then disable it. Polymorphism allows one to write a function that will take both an Element and an Attribute and traverse its children, but such a function is of little utility. Most applications either know exactly the structure of nodes they work on, or have to ask each Node’s nodeType and switch/case on that.

Therefore I conclude that inheritance and polymorphism are there only to facilitate implementation in an OOP setting. In a purely functional setting, there would be different implementation details — such as discriminated union types (type direct sum), pattern matching, and possibly dependent and/or existential types.
Add a comment...