Hacker News new | past | comments | ask | show | jobs | submit login

rails is a pretty mature framework these days, and it's got tons of plugins that are actually easy to use. It's a pretty steep road to get something up to those standards. When I need something that has everything already neatly solved and ready for cranking out stuff fast -- I always chose rails.

I'm currently trying to learn clojure and enjoying it immensely. It's a lot like ruby (powerful and fun) but with easier syntax and it's way faster. Looking forward to read through the conjure source.

One thing that bugs me with most of the clojure web frameworks that I have looked at is that they a. use ant instead of maven and b. don't provide a canned method to generate a war file. I don't like the advice "just leave a screen with slime and emacs running on your server". It runs on the JVM for crying out loud -- a little more enterprise is appropriate :)




"just leave a screen with slime and emacs running on your server"

Another way to do it is just load the swank jar on your server (the server side of slime). In your server startup, include a call to (start-swank). Then you can connect via slime whenever you want using M-x slime-connect, and you don't need emacs + screen to stay running.

I've only learned the JVM as part of learning clojure. What advantages would a .war provide?


Advantages:

Easy to get a server running: just install tomcat or jetty on your production machine, sftp the war file and it automatically deploys.

Init.d scripts are tricky to write and get right, by using a tested script from a distro things tend to work out of the box.

Monitoring -- easy to hook in some monitoring script that can reboot tomcat or jetty should the server stop responding.

Techops generally know how to deploy a .war file -- I would not feel comfortable telling someone to learn lisp just to deploy a webapp.

pretty interesting with swank -- need to look into that.


The war file and swank shouldn't be mutually exclusive, I just haven't bothered with a .war because by default Compojure starts Jetty itself, and I didn't want to bother with compiling the .war and restarting the server to test changes. Once you get addicted to reloading code from your IDE, you don't want to go back. :-)


> What advantages would a .war provide?

Deployment. If you have a procedure in place that handles versions of the server side code using .war files then you can simply give the sysadmins a new war to deploy and that will be that.

It's convenient because it is just a single file, if you want to roll back just move the old war file in to place, do 10 seconds of housekeeping and you're back up. Not that anybody ever had to revert to a previous version of their production code, of course. But in that hypothetical case...

Another advantage would be if you've automated your deployment across a large number of servers using this method. Update the master, send the signal to 'fetch and deploy' to the rest of your servers and that's it.


Out of interest, what's the advantage to being "more enterprise" in this case? Having a webserver with a working REPL seems like a rather useful thing to have.


Yes, that is very useful, in a way that's not normally possible with java.

But it is very nice to just give a .war file to techops. They know what to do with it, and how to keep such an application running and reboot it should it be needed. It's nice to not have to write custom init.d scripts.


"One thing that bugs me with most of the clojure web frameworks that I have looked at is that they a. use ant instead of maven ..."

Wouldn't it be better still to use something that is, and uses, Clojure?

One thing (among many) that I like about using JRuby is that I can use Ruby for config files and admin tasks. It may be a JVM language but I shouldn't have to use Java tools for routine tasks.


Yes it would be better. The 2 key issues that maven solves for me is depencency management (specify which version of jar you need) and a consistent build enviroment across projects. Maven sucks in a lot of aspects mainly because it's rather opaque compared to ant -- hard to know what it actually does.

Providing a maven build will make it trivial for anyone with maven installed to build a project, making it easier to adopt clojure project in an organization that uses a lot of java.


"Providing a maven build will make it trivial for anyone with maven installed to build a project, making it easier to adopt clojure project in an organization that uses a lot of java."

No doubt true, but the other side is that folks like me who barely know what Maven is, and would prefer to not do a lot of Java, are put off from trying Clojure (or certain Clojure tools and libs) because it appears too married to Java tools.

Sort of like telling people that to use Rails they first need to use autoconf or something because Ruby is C under the hood.


I understand what you mean and I can respect not wanting to dig too deep into java, we are talking about two different things here I think development and deployment. autoconf is great for someone who just wants to install something from source as simple as possible, it is also consistent across projects, making it a nobrainer to install with. I would love to have a simpler environment in clojure, it not even trivial to start the repl.


This one uses the build tool called "lancet", which is created throughout Stuart Halloway's Programming Clojure.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: