Derived Views of Pure Data

HTML is the only way to make a browser show us what we want to build and Karsten Schmidt still have no quarrel with that after 23 years working with it. post

However, being a markup language, it doesn’t really play that nice (nor was it ever meant to) with the other standard ingredient used to build modern UI’s — JavaScript.

So the (obvious) solution the big players all have decided on, was to conjure up new file formats, allowing frontend developers to sprinkle snippets of HTML-ish looking markup all over their source files and then in turn require an impressive array of tooling, engineering, documentation, education, project specific component libraries, editor support projects, parsers, compilers, source map generators, scaffolding helpers, each with endless dependencies and totaling millions of man-years of effort. And that all to magically transform this frankensteinish marriage of reactified, angularized, vue-ed, marked-up JavaScript back into… JavaScript. And all that because we seemingly cannot give up on using HTML to define our UIs.

And all that because our framework uses a slightly different approach than the “other” and hence requires a similar duplication of effort. And all that because even though JavaScript is the most popular and widely used programming language of the past 10 years, we still can’t bring ourselves to give up on the overall still same old idea of PHP-era templating engines and fail to see our UIs for what they really are:

In CS speak: Derived views of pure data

[…]

His two main learnings from the 7 years spent with Clojure / ClojureScript thus far have been:

The conscious recognition that in software circles “simplicity” is widely just interpreted and actively celebrated as primarily serving convenience and existing habits. It’s systemic, but not pervasive. E.g. Rich Hickey’s calm clarity of thought and ability to take a step back to reconsider prevailing design choices has led many others in and outside the Clojure community to question the status quo of the more mainstream language camps and we have seen several key innovations from the Clojure community quickly spill over and becoming transplanted in other languages.

Clojure being a dialect of Lisp, a language with often no clearcut separation between data & code, a language where even source code is literally encoded and processed as recursive data structures itself, I’ve learned to value S-expressions (in all their forms) as both the ultimate and most simple approach to encode tree based data, e.g. not just UI descriptions.

Some argue JavaScript & HTML too belong to the Lisp family tree (albeit more like far removed cousins), but it’s undeniable that both conceptually borrow in part from Lisp’s S-expressions. Since in JS we can only create arrays or objects in this literal way, let’s restrict ourselves to only using these two syntactic forms and play the game of “S-expressions” to build an UI:

According to a tweet by my friend Jack Rusher (thanks for the correction!), it was Phil Wadler at Edinburgh University who pioneered this approach in Lisp back in 1999, but my first encounter was James Reeves’ Hiccup (2009) Clojure library, which later also influenced the way how React components can be defined in Reagent (and others). I’m deeply, deeply grateful to both projects, since they have helped me to completely change my view on how to build UIs.

[…]

[…]

To get started, there’re several small, digestible, commented examples in the parent Umbrella mono-repo github , some of which combine hdom with other related libraries of the thi.ng collection, addressing:

[…]

How to UI in 2018. medium – A purely functional approach to UI composition with ES6/TypeScript