Will respond more about that later, but just wanted to point you to Phil Wadler's 1999 paper about both XML and the S-expression approach (HTML/XML are essentially S-expressions too):
http://homepages.inf.ed.ac.uk/wadler/papers/next700/next700....
132 karma · joined November 4, 2014
http://homepages.inf.ed.ac.uk/wadler/papers/next700/next700....
https://demo.thi.ng/umbrella/hdom-canvas-shapes/#points-10k https://demo.thi.ng/umbrella/hdom-canvas-shapes/#points-50k
I think there's fine line between aiming to be lightweight and aiming for smallest whatever by sacrificing all other aspects . I'm definitely in the former camp...
That demo will need to be refactored too and the plan is to extract those SVG components into their own package sometime during the winter break...
[1] https://www.flickr.com/photos/toxi/albums/72157627351329656
[2] https://github.com/thi-ng/umbrella/blob/master/packages/rstr...
The benefits of the component as plain, non-stringified data are not the avoidance of closing tags, but what you can do with those components computationally. E.g. instrumentation, behavior/attribute injections, configuration, filtering etc. An approach based on string interpolation can only go this far, whereas having everyting as arrays, objects, iterators your possibilities of composition & transformation are almost endless...
Also, take for example the hdom-canvas support library which doesn't target the DOM itself, but defines virtual elements translated into drawing calls. Using the string interpolation approach would be complete overkill since these elements would have to be re-parsed again, in which case SVG would be faster. But I can easily manage 10k+ moving particles @ 60fps with the hdom approach:
https://twitter.com/toxi/status/1041143431786115072
https://twitter.com/toxi/status/1041144813092044800
https://www.reddit.com/r/Clojure/comments/9deyxe/thinggeom_a...
Hth!
Quote: "The syntax is inspired by Clojure's Hiccup and Reagent projects, which themselves were influenced by prior art by Phil Wadler at Edinburgh University, who pioneered this approach in Lisp back in 1999. hdom offers several additional features to these established approaches."
However, Reagent also still relies on React under the hood whereas hdom is completely standalone. Also, hdom has a lot more features in terms of what kind of values are supported within an hiccup tree and additionally, in this latest version (5.0), hdom already has been extended to support non-DOM targets to update. Currently, the only user of this feature is the hdom-canvas package (https://github.com/thi-ng/umbrella/blob/master/packages/hdom...), which allows you to define canvas scene graphs in the same way as the rest of the UI, but those virtual shape elements are translated into canvas draw calls. A WebGL version of this is in early progress. In general, by implementing a certain interface you can support any other target context/data structure.
Ps. I've never used Om so didn't list it as an active influence.
Re: the above example - you didn't really explain which aspects you find alienating, but finding this hard to read, could have to do with the fact that this demo uses a few other concepts & libs not very popular in the JS world (specifically transducers)? I totally grant that without prior knowledge of those constructs this specific code is not the easiest to comprehend (though I've tried to comment every step).
In general though, IMHO this approach is a lot more direct and lightweight than any OOP solution. Having your entire UI defined using native ES6 primitve data structures, provides huge potential and endless options to transform raw app state into UI components. If you ever worked with a Lisp, you'll also find the nested inline definitions not that hard to read. To me it's also more legible than having an (often) over-engineered, multi-layered OOP architecure, riddled with inheritance and so on... Though again, this all is highly subjective. There's certainly ample opportunity to refactor this example into smaller functions and I might as well do that when I get a chance...
https://github.com/thi-ng/fabric/blob/master/fabric-facts/sr... https://github.com/thi-ng/geom/blob/develop/src/viz/core.org
As for the docstrings included in the core, this is largely to address complains from other users, who are used to have docs available in the REPL and I often don't have the resources/time to provide both org-mode and docstrings...