Interesting. Despite the many approaches to writing HTML more are invented all the time. Currently I'm working on yet another way. My idea follows the Lisp t

Interesting. Despite the many approaches to writing HTML more are invented all the time. Currently I'm working on yet another way. My idea follows the Lisp tradition based on its hierarchical list structures. It's surprisingly easy to parse and generate HTML from basically simple lists. '(html (head head stuff ...) (body (h1 "My HTML") (div (@ class "main-div" ...) "main div stuff"))) Of course it gets a lot more complicated when generating complete web pages and apps, but using paste operators, procedures and variables can make it produce anything necessary. A very similar approach is possible with Tcl, which I am using now for several reasons including integration with legacy code. In Tcl the above looks like: {html {head head stuff ...} {body {h1 {! My HTML}} {div {@ class "main-div" ...} {! main div stuff}}} In Tcl variables and procedures can be interpolated into the output by wrapping the list in a "subst" command: [subst {html .... [my-proc $my_var] ....}] The hierarchical nature of Lisp-like languages naturally resembles the GUI outline form the author presents in the article. Using Tcl it's occurred to me that it should be possible to write a "front end" to the parser/generator code using Tk (via the text or canvas widgets) which could resemble the author's illustrations. Ultimately I think the difficulty lies in the need for constructing customized templates to enable modular, easy-to-use GUIs for particular tasks. Real HTML can quickly become very complex which is the reason for the thousands of frameworks, generators and templating systems in existence. While I think the author's approach or my own can potentially be helpful, neither is going to magically eliminate the burden on the programmer.