Hacker News Reader

Comment by Scarbutt | Hacker News Reader

As someone who tries to use Clojure everywhere I can, its very hard to beat Rails for pushing out a webapp (many long Clojure timers share this opinion). Clojure shines for web services that require lots of data processing in the server and for integrating with parts of the Java ecosystem.

View on HN

I have not investigated Coast yet. I know it aims to be a Rails for Clojure... maybe it is, and maybe it would meet my needs.

But given the incredible power and expressiveness of Clojure, I find no reason to believe that the best rapid web development framework could be developed in Clojure if the right motivated people attempted to do so.

I don't know how many people (Plataformatec?) were behind Phoenix, but even in its early versions it was comparable to Rails. In some ways, it was even better.

There seem to be two obstacles to doing this in Clojure. The first is that people who actually know enough about Clojure to do this are actually very busy (happily) doing Clojure for work. They don't have the personal need to build a Rails for Clojure. The second is that those who would be capable already know how to pick and choose the libraries and build their own (even better, more suited for the purpose) ad-hoc frameworks for their projects.

I suppose it could be a curse of the power of Clojure that the lack of language pain points lessened the need/motivation for experts to build their own RAD framework.

I'm not denying that something better than Rails can be built with Clojure, just implying that it doesn't exist, so for quickly pushing out a CRUD webapp multiple times without repeating yourself again and again(avoiding all the trivial/tedious stuff), there is Rails.

Yup, and that's why Rails is what I still use :). Phoenix was pretty great too, but its real benefit came from doing bigger back-end stuff on BEAM.

Yes, and this trend in the Clojure ecosystem unfortunately works against widespread adoption. Works-for-me, everything-is-a-snowflake reinforces the image of Lisps being creative tools for individual artisans rather than rapid development tools for teams.

Fulcro RAD is looking for contributions

Every Django/Rails app with any significant business complexity I've worked on has been quick to start but becomes more and more difficult to change over time. The reason Rich Hickey's "Simple Made Easy" talk hit so hard for me was precisely the pain from working with Django apps (and Rails to a lesser extent).

It's nice to get started on a project quickly, but often that quick start is purchased at the cost of a system that is tied together in such a way that it's very difficult to change. Human beings naturally prioritize short term benefits over long term benefits. But developers have a responsibility to their employers / clients not to pick something that makes the dev's life easier in the short term by significantly raising the cost of adapting to changing requirements in the long run.

My life has been a lot simpler since I've moved away from Django to Clojure. It's less evident in weekend projects or in the first few months of a project. But I never find myself saying to a client request "unfortunately, the way Django works, it's hard to [retroactively produce reports/get the state of the application at previous point in time/fix application logic then correct a corrupted table/upgrade just by bumping version numbers/use multiple databases/not systematically overwrite data/etc]."

Yep, that's true, should have clarify that I was talking more about fire and forget CRUD apps (small business stuff).

OTOH, there a huge companies with successful rails(github,airbnb)/django(instagram) apps, but maybe they get away with it because the have big teams to re-architect anything.

What is your preference to interact with databases in Clojure? hugsql, honeysql, clojure.java.jdbc ?

Reply on news.ycombinator.com