A Lisp gives you all of this and more in a single, consistent, powerful programming language. I fail to see why we need three vastly different, intricate and complex technologies when we could have done with just one simple, elegant language. Languages like Scheme are mind bogglingly small, yet amazingly powerful.
I think this is more of a side-effect of familiarity rather than any inherent differences in readability between the two forms.
Lisps do tend to look foreign to most people because their first languages usually have C-like syntax, and Lisp vs C is a much more dramatic difference than say Python vs C.
Being able to write code that also happens to be valid data structures has some very tangible benefits though.
For instance, in the HTML example, you can replace the strings or keywords in it with variables and it will be evaluated and output into the final HTML. You can also take that HTML element, pass it into any number of map, filter, reduce functions and programmatically transform it in literally any way you want.
This means when you write HTML this way, you can use ClojureScript as your template language, and I think it's safe to say that ClojureScript is a much more powerful and well-designed language than any template language out there designed for HTML.
> Personally, I prefer the HTML version over the ClojureScipt version. It is shorter and to me it is much more readable.
That is only because this is Lisp that generates HTML. Also, in the example you had given, there are no closing tags. Closing tags are just superfluous visual clutter and are not actually needed. To take an example from http://c2.com/cgi/wiki?LispVsXml
This XML
<dictionary>
<email>electronic mail</email>
<html>hypertext transport language</html>
<xml>extensible markup language</xml>
</dictionary>
That is only because this is Lisp that generates HTML.
Ok, so it is not the way you initially stated '<img id=animal src="my_kitten.jpg"> becomes (html [:image {:id "animal" :src "my_kitten.jpg"}])'. You rather showed an example of how to create html elements programmatically. Then you should compare it to JS:
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.
In python, I can read code and reason about what it will do because I have a mental model of how that language works. the same used to be true of C and probably still is, but I'm out of practice.
I've been trying to build a coherent mental model of how layout in HTML+CSS works since 2008 and still haven't really been able to. If you gave me an html file and CSS file, I'm not at all confident I could draw they would interact. Conversely, if you showed me an HTML page, I don't think I could write HTML and CSS to reproduce it without continually refreshing my browser to check it. I have been trying to determine why I can't seem to learn this.
It's a visual thing. Frontend isn't very similar to programming for the backend (except for high quality javascript). Most people who can do wonders for frontend tend to be more like designers.
Ugh. Before the advent of CSS3 and canvas, I would have rated myself an 8 out of 10 in terms of "frontend knowledge/skills" compared to other frontend developers I'd met. I was never the cream of the crop (as a backend "expert"), but I could take a photoshop and replicate it, and knew most of the browser compatibility issues and how to work around them.
With all the CSS transforms, animations, canvas, 3d libraries, etc., I'm now utterly lost. I've gone from being an intermediate frontend guy to a 6/10 on the core necessities (all that earlier knowledge is still the foundation), but like a 1/10 or 2/10 with all the new stuff. I could probably get to 4/10 if I put in the effort, but I have a very strong gut feeling that I simply do not have the... faculties... required to be an intermediate frontend guy in 2015.
All that to say... codepens like these I've seen blow me away. I don't even bother trying to dig into the CSS. It's just beyond me. ;)
CSS is the one of the trickiest technologie I had to deal with. Something as easy as centering a div is a hell to do. You find many different way to achieve it on the web, but some work in few cases and don't other time. The reason why is still a mistery for me and my other skilled colleages.
CSS is one of the reason I hate web developement (javascript being so tolerant to error is another one).
You're absolutely right that it's a pretty good way to build text/image-based documents and show them on a page (well, ignoring CSS and it's many quirks).
But a lot of people wanting to do web-things don't want to just show documents. If you want to build programs, it's not as convenient any more.
The open question remains of should we be trying to improve the web ecosystem to compete with desktop applications, or should we accept that maybe web browsers are best at document reading, and we should leave both to their respective areas.
You quite obviously don't know what you're talking about.
Try and write something complicated in js and you'll hit performance problems far quicker than other languages even today in 2015.
HTML is a complete disaster.for any thing other than documents and woefully inadequate for applications. You can't even do something as basic as encapsulate a snippet as a control to reuse.
And CSS is plain stupid, the very foundation of it is quite obviously broken. The precedence of operators is a constant annoyance. And let's not even get started on how it lacks basic inheritance, making it a nightmare to maintain.
I can't understand how any programmer who had actually used the alternatives could claim such things. I suspect you have little experience in programming so aren't even aware of the alternatives.
What if I want to use html+css+js to dynamically draw a 1024x1024 picture of a cat with pixel level detail? I'm sure it can be done. But wow. That code would be ugly.
Or how about dynamically drawing a diagonal line or swirl across the page?
I apologize for the lack of an example, but I'm sure you can imagine how much harder that would be in html and css then it is with a renderer that has bezier curves and lines as primitives.
I said pixel level. That's vector level. Also by html+css+javascript I thought you meant strictly primitives within that domain like spans and divs. While svg is part of html5 people typically don't think of svg when someone says to write something in html+css+javascript.
I don't have a problem with that. Never said I did.
The OP said html+css+javascript, which I assume means html primitives like div and span with css and javascript sprinkled all over it. Canvas and svg exist a little bit outside of that ecosystem and I assumed the OP wasn't referring to that, because sure... with WebGL you can literally program anything into the browser. If someone used webGL as an example it would sort of render his question pointless.
You can make all kinds of magic happen in a simple text file. In an intuitive way. Want to tell something? Just write it:
Want to show an image? Just a few keystrokes: Want to style it? Here we go: Want to change it programmatically? Easy: Deployment? Instantly. Developer tools needed? A text editor. Compatibility? Runs everywhere. Speed? Im often shocked, how fast stuff runs these days.I think we created a paradise. And I enjoy "living" in it every day.