Hacker News Reader

Comment by tborg | Hacker News Reader

lein new noir myBigWebApp

I think Clojure makes a lot of sense for the web, emphasis on immutability etc. I also am a sucker for lisps, and I think the Hiccup templating system is nice. Noir seems to do middleware well. Plus, real nerds get on that ClojureScript.

Then again, I kind of also believe that the back-end really shouldn't do much more than process CRUD commands, and that most of your serious application logic should happen on the client. So it doesn't really matter. Pick something with a DB adapter you're comfortable with and get to javascripting.

View on HN

I'm inclined to agree for a few reasons other than the usual things people cite about Clojure. These are the first to come to mind:

* The property list pattern and inheritance-like behavior are very natural and convenient with maps and records. I think that sort of thing is very helpful with large applications.

* Clojure has the ability to abstract the database (I'm thinking of Korma here) in a way that preserves and works with the relational model more directly than ORM.

Clojure's ability to leverage Java libraries also means you're unlikely to ever get stuck implementing common functionality from scratch[0] when another language would have a library.

[0] I did, however once write a CSV library for Clojure because it seemed easier than using an existing Java library for the subset of functionality I needed or writing a wrapper.

I totally agree that Clojure and Noir are a great choice. In dev mode with automatic code reloading, you have a fluid setup.

I am starting to rebel a bit against really fat JavaScript/CoffeeScript/ClojureScript clients as the default implementation strategy. For many apps, using old fashioned forms, render on the server, and after you have functionality convert bits to AJAX as needed to make the web app nicer to use. It is an economic decision: is the cost of a slick fat client justified for a given project?

Reply on news.ycombinator.com