How much of an advantage is language homogeneity in web apps?

Question

Hey all, this is more of a philosophy question than anything. I have written my first web app, a Boston event calendar at http://bloozit.com I wrote it in Python, and I'm pretty happy with the simplicity of it, however, my Python contains blobs of HTML, CSS, and Javascript, like a stew with fish heads and eyeballs floating in it.

Then I saw this tutorial on web apps using Lisp: http://www.adampetersen.se/articles/lispweb.htm I've read On Lisp and written some software in Lisp, so I'm no Paul Graham, but I am familiar with it. One thing that appealed to me tremendously was how the author generated both the HTML and the Javascript from Lisp, makingn the whole thing nice and homogeneous.

The question is, how valuable is that homogeneity in the real world? Whenever anything goes wrong, you have to load the page up in Firebug, and then you'll be looking at the generated HTML, CSS, and Javascript, not the Lisp source, so you have to hold the mapping in your head. Does the homogeneity provided by Lisp really solve anything, or just wallpaper over the problem, which eventually pops up again downstream?

If there's anyone out there who's actually tried both approaches, I'd REALLY like to hear from you!

Answer 1

Well, I spent a year coding with parenscript and ht-ajax and eventually gave up and just generated the javascript by hand (still using hunchentoot on the server). I found that the result was much more predictable and, as you imply in your question, this made it a lot easier to figure out what was going on when using firebug. (I also switched to using jquery, which was much better than ht-ajax, but that's not really what you're asking).

That said, I massively recommend cl-who (http://weitz.de/cl-who/), which makes the dynamic generation of HTML much neater.

Answer 2

The question is, how valuable is that homogeneity in the real world?

Probably fairly significant: look at all the people doing server-side Javascript these days. Javascript isn't superlative at anything, and its library support for server-side code isn't that great at all, but there's big gains to be had by using it.

Whenever anything goes wrong, you have to load the page up in Firebug,

Depends on what the "anything" is. I can't actually remember the last time I had to open up Firebug to see what's going wrong -- I've certainly been through phases where it was, but there's also plenty of times when it's not.

For example, if you generate your CSS from s-exps, then trouble with your CSS might only make you need to look at the "compiled" CSS for weird syntax issues (like IE6 tricks). If you just look at the page and decide you need an extra border, then you can add (:border 1) and be done with it. (Of course, if you process that to generate a whole set of CSS rules to serve to the client, then it's an even bigger win.)

Another way to think about it: on very rare occasions I've needed to pull out a packet sniffer and a disassembler when working on a modern web app. Yeah, it sucks, but with good libraries, it's also very uncommon. I wouldn't rather write low-level code all day just to avoid the impedance mismatch of switching to a packet sniffer on the rare occasion when I do need that level of information.

This assumes that you want to and can get to a level where you're writing (V)HLL code. Common Lisp can't beat C at being C, and if you're just trying to spit out a simple blog in HTML then you're not in the sweet spot there, either: Rails is really good at that kind of thing already. But there's plenty of experimental programming where being able to change one flag and run code on the client rather than the server is useful.

and then you'll be looking at the generated HTML, CSS, and Javascript, not the Lisp source, so you have to hold the mapping in your head. Does the homogeneity provided by Lisp really solve anything, or just wallpaper over the problem, which eventually pops up again downstream?

I've written all-Lisp and all-Javascript web apps, and I think the best answer I can give right now is: it could. I've used Parenscript, and the major problem is that Parenscript is a Lisp-y language but it's not Common Lisp, nor is it any other complete language you can use on the server side. (If there was a Common Lisp to Javascript compiler, like GWT is for Java, then it'd be great. I don't see anyone seriously trying to make one, though.) So you've still got, as you observe, two languages.

Javascript is a bit better today, in this regard, because you can run exactly the same code in both places. It's not quite ideal because your server-side Javascript probably has features that you can't guarantee will exist on the client-side (unless you limit your users to, say, recent versions of Firefox). If you're like me, you don't want to limit your server code to JS that happens to run in every browser, so your server-side JS and client-side JS will be subtlety different. It's not a dealbreaker -- it's still pretty nice -- but it's still 2 slightly different languages.

I think it would be pretty cool if there was a program that could take code written in the latest Javascript (1.8.5), and generated old-school Javascript that ran in any browser. I don't think that such a program exists, but I don't know how difficult it'd be.

There are Scheme implementations for Javascript, and so maybe the situation with Scheme is better. I should probably look into that one of these days.

I'm often frustrated when having to use a server-side language that's completely different from my client-side language (Javascript). But then I'm also frustrated when I have to use a language that is lower-level than Lisp (which is most of them). Is it a bigger win to be more Lisp-like, or more Javascript-like? I don't know. I wish I didn't have to choose.

Answer 3

This isn't so much an answer as a strong opinion, but the fundamental problem is that HTML and CSS are just terrible(1). Neither does well what it is supposedly intended to do. Javascript is better, and is often pressed into service to make up for the shortcomings of those two(2), but it isn't an ideal solution(3). And as result server side languages are needed to generate HTML and CSS which just further complicates the mess. It is laughable that the simplest web application requires programming in no less than four different languages.

So, yes, your desire to have one good reliable language which which you can interface instead of those others is understandable, but so long as you are writing code that generates HTML/CSS such that you have to be concerned with the details of HTML and CSS, then you are just wearing mittens that might (read "probably") interfere when you go to play the piano. If your Lisp code is looking like this: (:body (:div (:@ (:style (:border "1"))) (:p "hello"))), then you aren't really free from the concerns that plague you.

Personally, I think we need something else to take the place of the soup we've got now and it should compile to HTML/CSS/JS but keep the user free from their concerns. C compiles to assembly but the C programmer never sees the STA, MOV, LDX opcodes that it compiles to in their own written code. And, were it to be popular, then the browsers could support it directly. Anyway, it's just an idea. A glimmer.

Good Luck,

Chris Perkins
medialab.com

(1) HTML documents are compound documents with images, scripts, stylesheets, etc all being stored in other files. But the one thing that an HTML document cannot do is fluidly embed another HTML document - the one thing it most needs. iframes/object tags are fixed size and both adversely impact SEO. This one trivial task is often the sole reason a server side language like PHP is used on many websites.
You don't need me to tell you how bad CSS is.

(2) Examples abound: LESS (lesscss.org), document.write, AJAX, and more.

(3) The impedence mismatch between the Javascript DOM and CSS rules is nearly unbelievable. How many heights does a div have in the DOM (scrollHeight, offsetHeight, clientHeight, and more)? 4 or more, maybe? How many of those are addressable via CSS? 0 or 1. Also, while Javascript can plug a lot of holes, it often does so at the expense of SEO