Live data from Hacker News

Using Clojure for Web Apps

github.com

41–50 of 122 posts

Re: Using Clojure for Web Apps

#41
post #31
post #29

Earlier quoted context omitted.

It sort of guarantees that in a couple of years time half your stack will then be unmaintained, though (at least in my 10 years of Clojure experience).

That’s not limited to Clojure nor does it matter whether it’s a batteries included framework or not. I’m seeing this more and more, to the degree that often I’m back to rolling my own instead of relying on a library or framework that has a high likelihood to f being abandoned.

More and more I'm of the opinion that I don't want to use a library that's not included in the core product. I've had way too many dependencies become end-of-life before my application was EOL, and I ended up having to fundamentally change my application, putting in hours of work just to keep things the same, or rebuild a feature. I appreciate Rails for all the built-in stuff it provides but anything outside of that, as time goes on you're getting more and more likely to end support. Paperclip hit me hard, and my Rails apps are stuck on an unsupported library because it's not worth the time or effort to migrate to ActiveStorage. God help me if Devise is deprecated.

That's the reason I've tried to stay away from the current Javascript madness. All of modern Javascript is built on hundreds of NPM packages that will disappear in two or three years.

I certainly will never use any language or framework in production if the main feature is "nothing is included, bring your own core features" like Flask or Express unless I'm committed to building those not-included core features myself (which I probably won't). Because if I'm bringing in someone else's package, even something that's well supported by a great and developer-friendly company like Thoughtbot, that package will likely EOL before my app does. Yes I'm still absolutely bitter about Paperclip being deprecated.

Re: Using Clojure for Web Apps

#42
post #25
post #23

Earlier quoted context omitted.

> I know some folks sneer a little at Lisp I wonder why. Some developers I know and hold in high regard have almost venerated Lisp, so I've always thought there must be something to it. I just thought it wasn't something you could actually use IRL, but I was wrong. I found this out when I was recently motivated to learn Clojure, and now I am starting to grok their admiration.

It will depend on whom you talk to - perhaps how old they are, and certainly where they come from (experience wise, education wise, etc.) The usual easy excuse is about parens, but that complaint has been put to rest so many times that it's not worth replying to anymore. (And people said the same thing about Python whitespace, but now Python is at or near the top of the pile.)

Python has too few parentheses, Clojure has to many. There’s just no winning.

Ultimately, these complaints are superficial and serve only to justify one’s laziness.

Re: Using Clojure for Web Apps

#43
post #14

Earlier quoted context omitted.

What a surprise that the stateful edges of the application are the most complex! I didn't mind component in the past but we just started a project with mount and I really dislike working with that. Seems like there are a lot of ways to shoot your own foot with any of these libraries because there is no "one true way" to integrate them into an application. I haven't tried integrant yet but everyone and their dog seeme…

Out of curiosity - what are the pain points related to Mount?

Its composability is a bit of a double edged sword. While it leads to a more declarative style of state management, I've found our implementation of it to lead to confusion about when /where/which states are swapped in or out. But honestly I think anyone can have a great or cruddy experience with any state management library depending on how it's weaved into the code, and I don't blame the library so much as I blame our implementation thus far.

Re: Using Clojure for Web Apps

#44
post #28

Earlier quoted context omitted.

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), Djang…

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.

Re: Using Clojure for Web Apps

#45

Some of my favorite Clojure libraries in this space: - instaparse: takes EBNF (and other formats) as a string and gives you a parser instantly (!!!) https://github.com/Engelberg/instaparse - re-frame: React-Redux alternative that IMO is much easier to work with https://github.com/day8/re-frame - reagent: React wrapper https://reagent-project.github.io/ - ring https://github.com/ring-clojure/ring - fulcro https://gith…

I have to echo that Re-frame is superb!!

Re: Using Clojure for Web Apps

#47
post #25

Earlier quoted context omitted.

It will depend on whom you talk to - perhaps how old they are, and certainly where they come from (experience wise, education wise, etc.) The usual easy excuse is about parens, but that complaint has been put to rest so many times that it's not worth replying to anymore. (And people said the same thing about Python whitespace, but now Python is at or near the top of the pile.)

Python has too few parentheses, Clojure has to many. There’s just no winning. Ultimately, these complaints are superficial and serve only to justify one’s laziness.

Clojure has the same number of parens as Javascript, C/C++, Java, and similar languages have parens+squiggle-brackets.

(print "foo") vs print("foo"). same same.

There's so much more to it than this. I can say without reservation that people who do not take a couple/few weeks to learn a Lisp just do not know what they are missing, and their arguments against it are viewed as children who lack enough experience to know what they are rejecting.

Re: Using Clojure for Web Apps

#48
post #18

We use pedestal+fulcro3+pathom om.next was before that, but it seems to be almost abandoned, also fulcro author have solved a lot of depressing pain points of om.next. Those three work like a perfect Lego.

We used om before om.next was a thing (back in 2014). Seeing the abandoned state of om and om.next and how it even had trouble keeping up with the latest React releases, and after maintaining a fork for a few months we switched to TypeScript. Burned once; not again.

Re: Using Clojure for Web Apps

#49
post #29
post #17

Earlier quoted context omitted.

IMO languages like Clojure (or Go) don’t need a fully powered batteries included web framework like Rails or Django. The approach to pick together what you actually need (router, db bits and pieces, etc) with composable libraries works really great

It sort of guarantees that in a couple of years time half your stack will then be unmaintained, though (at least in my 10 years of Clojure experience).

I get it, you want to be up to date all the time, but often the case is that lib is just done, it does what it says it does, so that is why lib was last updated x years ago.

Re: Using Clojure for Web Apps

#50

Some of my favorite Clojure libraries in this space: - instaparse: takes EBNF (and other formats) as a string and gives you a parser instantly (!!!) https://github.com/Engelberg/instaparse - re-frame: React-Redux alternative that IMO is much easier to work with https://github.com/day8/re-frame - reagent: React wrapper https://reagent-project.github.io/ - ring https://github.com/ring-clojure/ring - fulcro https://gith…

> desirable in most CS curricula.

most of the alogrithms and datastructures that you learn in CS were developed using mutability.

I am not sure that we can even develop immutable equivalents for most of them with similar time/space complexities.

Post reply on HN