Hacker News Reader

Comment by goostavos | Hacker News Reader

After having gone through this, I now disagree.

There are a vast many things in which I am not an expert. The pick and choose / compose your libraries / lego approach sounds great until your trying to weigh different options (of which none seem to have a wide enough install base to be truly battle tested).

Is buddy/buddy-auth the way to go for security? Or is it Friend? The former seems to receive more recommendations as of late, whereas the latter has more activity on github. These are not the problems I want to be solving when building something.

I love the language, but the quality of Clojure's web ecosystem is... questionable.

If I were to build another webapp in Clojure, I think I'd just use something widely installed like Jersey for actually interfacing with the outside world. It'll be crufty Java, but it has nice things like StackOverflow activity, massive docs, giant userbase, etc.. etc..

View on HN

You express exactly what has kept me from doing webdev with Clojure, despite my (now perhaps irrational) love for the language.

I will learn whichever language allows me to get my site/app done as quickly as possible at first. Later after I have refined and refactored enough to know what's up... then I may decide to change.

Nextjs (despite the javascript), Rails (Ruby is great!... not Clojure, but pretty good), Django (Python is low-pain, low-effort), etc. are all easy quick ways to actually get something done BEFORE you really know what you're doing. This is critically important for those of us who don't spend all our time doing public-facing web apps.

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.

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 ?

I generally agree with your statement, otoh I have used some libs that are not being actively maintained for years and they still work, out of the box.

Clojure strength is its weakness. But yes, there is a long way to make it more beginner friendly

Reply on news.ycombinator.com