Lisp for the Web, Part II(msnyder.info)
msnyder.info
Lisp for the Web, Part II
http://msnyder.info/posts/2011/07/lisp-for-the-web-ii/
6 comments
I've been hacking together a site using Hunchentoot, Postmodern + PostgreSQL, CL-WHO for HTML generation, and CL-JSON + Backbone.js for client interaction. I'm probably duplicating a lot of functionality that would already be done with Rails or Django but I'm having a lot of fun doing it this way :)
Allow me to flog WuWei, http://wuwei.name, a toolkit for doing Ajax web UIs in Common Lisp, now in production use on http://biocyc.org .
Very nice. It would have been a little easier to setup if mtlist and wuwei where Quicklisp installable. Thanks!
According to README, quicklisp installation is available for wuwei.
https://github.com/mtravers/wuwei/blob/master/README.md
https://github.com/mtravers/wuwei/blob/master/README.md
How does it compare to Weblocks?
Think of it as a toolkit rather than a complete platform. Nothing against Weblocks, but when I evaluated it (some time ago) it seemed to want to take over the application architecture. WuWei is more lightweight, providing tools for doing things like managing session state and dynamically updated HTML that you can use at will as part of a normal web application.
Just use RESTAS, closure-template & Postmodern.
What makes this stack superior to the other suggested libraries?
RESTAS is written by someone who knows both Lisp and the web really well. It's a good sign when a developer resists the urge to invent a new templating syntax (specially a lisper, come'on) and chooses to use a boring semi-standard, like Google's Closure Template.
RESTAS is MVC, in the loosest sense of the word. The author, archimag, went way out of his way to make the "C" part, the controller, as flexible as possible.
RESTAS created its own module system on top of the Lisp package system. Importing a Lisp package from within an application also mounts that package's controller URLs underneath your app's.
He wrote one of the most authentic clones for Closure Template language. In fact, it generates HTML and JavaScript.
I could go on and on, but to put in a nutshell: the author actually looks at other web frameworks for inspiration, and is not someone trying to bolt an idealized "Lisp way" on top of the web. No continuations, no pretending that the web is a GUI, none of that crap. You want web, you get web: clean, modular, RESTful web.
RESTAS is MVC, in the loosest sense of the word. The author, archimag, went way out of his way to make the "C" part, the controller, as flexible as possible.
RESTAS created its own module system on top of the Lisp package system. Importing a Lisp package from within an application also mounts that package's controller URLs underneath your app's.
He wrote one of the most authentic clones for Closure Template language. In fact, it generates HTML and JavaScript.
I could go on and on, but to put in a nutshell: the author actually looks at other web frameworks for inspiration, and is not someone trying to bolt an idealized "Lisp way" on top of the web. No continuations, no pretending that the web is a GUI, none of that crap. You want web, you get web: clean, modular, RESTful web.
[deleted]
Great article! The only thing I'd do differently is just serve up the js as a static file instead of using code transformation. That seems likely to break for non-trivial amounts of js.
I beg to differ. I've used ClojureJS (a Clojure to JavaScript translator) for building a non-trivial web app front end, and the result has not only been robust but also a pleasure to build (from a Lisp programmer's point of view).
[Disclosure: I'm the author of the ClojureJS library]
[Disclosure: I'm the author of the ClojureJS library]
Interesting. What's the site, and is the original Clojure source before -> js transformation published somewhere?
We're not launched yet (but, close). I'll definitely post about it when we're live. I'm not sure how much of the Clojure (subset) code we'll publish, but I'll write more about our process and experience once we're launched.
Yeah, Generate the data (JSON) that the javascript will work with, don't generate the javascript. That way we can have easy to serve, easy to cache static javascript.
Generated JavaScript can be served and cached just like static .js files. It doesn't have to be embedded in the HTML.
And almost all of these (and many more I haven't listed) are easily downloaded and installed with Quicklisp.