I don't understand, why would anyone want to generate javascript from S-exprs? I understand this is fashionable in the CL world, but I've never seen any good justification for this practice outside of saying, "Now everything is in lisp."
But this isn't a terribly compelling argument. Most web applications are multi-language and it doesn't seem terribly detrimental to them. Further, the state of the art in web technology moves so incredibly fast that it seems strange and almost obstructionist to insist on a secondary library that needs to be kept in synch.
Finally, it tends to lead to crap designs. Anyone who does cross-browser implementations designs will tell you that simple CSS over a generic HTML framework is almost never enough. Frequently you need to introduce new enclosing scopes or add seemingly senseless markup to help make IE play nice (a torturous exercise many web designers still need to go through). So while CL has some awesome web libraries, I'd say their extensive work into making HTML+JS+CSS generation from pure lisp seems like a foundation built on sand. Sometimes I wonder if the whole exercise was just to avoid working with HTML, which many (more prejudiced) developers find distasteful to work with.
I don't think Clojure is at a significant disadvantage to CL in this field. If anything, it's at an advantage in web applications, as it has access to a massive number of very good web-related and utility libraries. A paucity of modern, battle tested libraries that "work everywhere" has always been Common Lisp's achilles heel.
You say you "don't understand", apparently disingenuously, because you then go on to announce what the argument supposedly is, object to it, change the subject (what, exactly, does Parenscript have to do with HTML?) and end with a red herring.
As someone who works in Parenscript every day and hasn't had his coffee yet, I find that irritating.
> (what, exactly, does Parenscript have to do with HTML?)
Because we frequently see Parenscript used in isolation from sexp->html compilers? I sure don't.
I'm not ending with a red herring, I'm saying you're creating a huge integration hassle with the rest of the web application world. Heck, even pattern-substitution templating systems are falling out of style as it becomes feasible to do structure-substitution templating. Most designers and javascript experts do not know lisp, and further don't want the equivalent of a wet blanket separating them from their medium.
And I don't mean to upset you, but I also notice that you didn't exactly provide any justifications for parenscript. It's a cool project, and I've even used it for production work. However, I never felt it was anything more than a stopgap solution, and my impression from the CL community was that they didn't like HTML+JS because it wasn't lisp.
Parenscript excels at combining high-level abstraction with runtime efficiency in a web browser. It has to do with Javascript, not HTML, and if you've used it as much as you say, you know that perfectly well. Arguing that PS sucks for web apps because web designers don't know Lisp could hardly be more of a red herring.
So you can add first-order generated-code errors to your generated-code errors when your javascript generator has a problem or a new feature comes into play incorrectly.
I understand that's nice and all, but couldn't you just write javascript? While it lacks macros, it is certainly dynamically expressive enough that you can do pretty much anything you could reasonably require. A cursory examination of Mootools and JQuery could tell you that.
If you are using all the higher-order features of javascript to make it terse and expressive, you are probably "doing it wrong" in terms of producing fast code in a selection of browsers. From this perspective, javascript is the compiler output language, like machine code. Parenscript would then be like assembly - a 1:1 mapping - but embedded in a powerful enough macro system that it can be wrapped into a readable DSL.
I'm not being smug, I really want to see some benchmarks that make sense. The only thing I've seen is either "jQuery version x.y.z. is % faster than jQuery version a.b.c." or "jQuery is % faster doing something than Prototype." Yes some of these libraries may be getting less slow, and some of them are less slow at doing certain things than other slow libraries, but the only thing that would make sense is to compare them to hand-written JS and see the trade-off in performance vs code size.
Most jQuery application code I see is just adding layers over the DOM in a way that doesn't provide any extra expressive power or conciseness (frequently the opposite).
Yes, selectors are cool, but only if you need to manipulate a document that's been generated by someone else. If you have control over how you generate HTML, you can actually keep track of your DOM elements in a way that doesn't involve searching at run-time and expresses domain concepts - I mean, imagine this!, actually program normal code.
They are fast because they have been coded by experts. So maybe they look cute - would your code that looks as cute run as well? Probably not unless you can match them in knowing why.
Or by leveraging their work as their documentation suggests.
Seriously, performant javascript is not some magical thing only wizards can attain. Performant _generic_ javascript is tough stuff, but just using the libraries is hardly JIT compiling.
> I understand this is fashionable in the CL world, but I've never seen any good justification for this practice outside of saying, "Now everything is in lisp."
[...]
> I understand that's nice and all, but couldn't you just write javascript?
I agree with you on this point (JQuery is quite nice), but this is orthogonal to the CL vs. Clojure vs. $Framework debate.
I (OP) agree with a lot of what you've said. I have done a lot of work in javascript, and my reason for html/js generation wasn't because I believe that everything should be lisp. I enjoy writing html, js and css from scratch.
The reason I chose it as one of my criterion is because it allows you to get off the ground _fast_ if you're coding in a single language (so basically it helps with prototyping stuff). I really enjoy the html generation libraries- I can test stuff without doing a mental switch between languages, even build a half decent UI very quickly, and that is a huge advantage. My initial scripts will not need to be run in multiple browsers, they'll be simple scripts to get the app going. Since I intend to keep the scripts small and smiple, I can replace them later with javascript as the app grows.
Well people would do it for the same reason they use the GWT. In that case they are more familiar with Java and GWT lets them write Java and have it compiled to javascript for client side use.
"I don't understand, why would anyone want to generate javascript from S-exprs? I understand this is fashionable in the CL world, but I've never seen any good justification for this practice outside of saying, "Now everything is in lisp.""
No, that is the justification behind things like GWT which are written by people who don't know web programming for people who don't want to learn web programming.
The point of having everything in Lisp is enabling the possibility of building your application in terms of domain concepts (I want to say "DSL" here, but the problem is that the term DSL has been coopted by Java morons who think it means something like scripting language).
The difference with other single-language systems like GWT is that this is done using macros - you're translating domain concepts directly to the JS+HTML+CSS target, instead of trying to shoe-horn them into some brain-damaged OO layer that may or may not need runtime support.
It's not about "abstracting the web," (abstracting to what? "Abstracting" JavaScript to Java is going from dumb to dumber); it's about the domain.
I don't understand, why would anyone want to generate javascript from S-exprs? I understand this is fashionable in the CL world, but I've never seen any good justification for this practice outside of saying, "Now everything is in lisp."
But this isn't a terribly compelling argument. Most web applications are multi-language and it doesn't seem terribly detrimental to them. Further, the state of the art in web technology moves so incredibly fast that it seems strange and almost obstructionist to insist on a secondary library that needs to be kept in synch.
Finally, it tends to lead to crap designs. Anyone who does cross-browser implementations designs will tell you that simple CSS over a generic HTML framework is almost never enough. Frequently you need to introduce new enclosing scopes or add seemingly senseless markup to help make IE play nice (a torturous exercise many web designers still need to go through). So while CL has some awesome web libraries, I'd say their extensive work into making HTML+JS+CSS generation from pure lisp seems like a foundation built on sand. Sometimes I wonder if the whole exercise was just to avoid working with HTML, which many (more prejudiced) developers find distasteful to work with.
I don't think Clojure is at a significant disadvantage to CL in this field. If anything, it's at an advantage in web applications, as it has access to a massive number of very good web-related and utility libraries. A paucity of modern, battle tested libraries that "work everywhere" has always been Common Lisp's achilles heel.