Yes, my second example which translated XML to equivalent Lisp would be better at illustrating my point.
With a Lisp, you don't need HTML as there is no distinction between code and data. Your Lisp is rendered and displayed on screen. It doesn't emit an intermediary language. How do you programmatically manipulate this "data"? Within Lisp itself. Lisp acts as both HTML and JavaScript. Lisp programmers regularly do this with the power of Lisp macros. I suggest you read the "Lisp vs XML" page I linked to in order to understand this better. Lisp directly exposes its syntax tree to the programmer and allows them to manipulate it to their liking.
So do you propose to make the separation of content and behaviour go away? Because that is one of the key features of the HTML+CSS+JS structure.
I like the content/presentation/behavior separation from a developers point of view and from a users point of view.
As a developer, I love to know what I am currently working on. In HTML, I define the structure of the content. In CSS, I define how it looks. In JS I define the behaviour. Lovely.
As a user, much of the time I browse the web without JavaScript. Because I am only interested in the content. Not in popups that beg me to join newsletters, animated things that make the page more "fun" or ads that try to grab my attention. Also I often disable the pages stylesheet so I get a nicely readable big font with good contrast to the background.
> So do you propose to make the separation of content and behaviour go away? Because that is one of the key features of the HTML+CSS+JS structure.
No, only thing that goes away the cognitive burden of keeping in mind the original HTML, CSS and the JS representation/modifications of HTML and the interaction of all three.
As many websites are currently designed, content if often loaded and inserted into the HTML by JS. The separation of concerns enforced by this system is extremely blurry.
You could also tell the interpreter to not evaluate macros and just display the content as is.
> As a developer, I love to know what I am currently working on. In HTML, I define the structure of the content. In CSS, I define how it looks. In JS I define the behaviour. Lovely.
You can do all three in the same language and still maintain separation of concerns, like is done in most other languages and with native apps.
> As a user, much of the time I browse the web without JavaScript. Because I am only interested in the content. Not in popups that beg me to join newsletters, animated things that make the page more "fun" or ads that try to grab my attention. Also I often disable the pages stylesheet so I get a nicely readable big font with good contrast to the background.
Again, you could tell the interpreter to ignore style elements, or write a reader macro to do it yourself. That is the beauty of lisp :)
The lisp is not "rendered", it is executed. Any language that can implement a recursive-descent parser/generator could be the basis for this -- it does not require lisp or lisp macros. Think about what a render would have to do, and you realize that the model of using embedded rewrite rules (macros) might be slightly more convenient, but not a really a distinct advantage over executing code which renders or outputs instructions to render later.
The problem is most definitely not that you have to output an intermediate language, the problem is that HTML/CSS sucks. It is originally designed around presenting static text documents, and the committees involved were not smart enough to figure out a way to depart from that over a decade ago when pixels became important to the web.
With a Lisp, you don't need HTML as there is no distinction between code and data. Your Lisp is rendered and displayed on screen. It doesn't emit an intermediary language. How do you programmatically manipulate this "data"? Within Lisp itself. Lisp acts as both HTML and JavaScript. Lisp programmers regularly do this with the power of Lisp macros. I suggest you read the "Lisp vs XML" page I linked to in order to understand this better. Lisp directly exposes its syntax tree to the programmer and allows them to manipulate it to their liking.