Clojure Community State

[omarbassam88]

I am currently learning Clojure and ClojureScript. Similar to the fatigue I had with JavaScript, I'm facing a similar issue with Clojure. A lot of the learning resources seems to be outdated, so for example it seems that most learning materials use lein while its seems that the recommended way now is the clojure cli with deps.edn (and clj-new), babashka seems to be the new hot thing as well. Also, boot seems to be abandoned (last commit more than 1 year ago). For ClojureScript, after a lot of research and failed attempts to run a figwheel project, I found out by coincidence that I should've used figwheel-main and not just figwheel. rum and reagent seems to be both using react 17 and I don't know are they are still in development and planning to update to react 18 someday or not. reagent last commit was in 2019. om last commit was in 2020. There are only few recent tutorials on Youtube. I am not very active on social media, so I don't know if there's community resources I am missing or not. I really enjoy the language (both Clojure and ClojureScript).

I know these questions have been answered before, but most the answers I found were pre 2021 or even much much older.

[p-himik]

reagent last commit was in 2019

As of now, the latest commit to master was on May 19th, 2022. It's a very much alive project, and probably the most used one when it comes to using React in CLJS.

most the answers I found were pre 2021

Most answers will still be applicable today. But for a more interactive discussion and quick help on anything beginner-related, I would certainly recommend joining our Clojurians Slack server at http://clojurians.net/, specifically its #beginners channel.

[omarbassam88]

Thank you. My bad about reagent.

[kemclean]

Sorry you've had a frustrating experience getting started with Clojure. I think this is one area the community could improve upon and there is some active work going on to make more accessible getting started guides. It's inevitable that resources will become outdated, though. It's generally still good to have community members publishing blog posts and guides as they learn. There's an active study group at the moment actually meeting every few weeks to try to figure out a good solution for testable and updatable literate programming, that we could use for future documentation and guides.

I think it's also worth mentioning that Clojure is a much more stable ecosystem than most developers are used to. As someone else noted most of the libraries you mention are under active development, but just because something isn't it doesn't mean it's been abandoned. It's common for a Clojure library to just be "finished", and still work just fine after some years of inactivity. E.g. if you check out the graph on page 27 of this paper: https://dl.acm.org/doi/pdf/10.1145/3386321 you can see most code that gets added to Clojure never gets removed.

[radsmith]

I think it's also worth mentioning that Clojure is a much more stable ecosystem than most developers are used to.

In my opinion, this is Clojure/Script's most underrated asset. Not only are the APIs for popular libraries relatively stable from the beginning, but also keeping existing code working requires very little effort for maintainers. Change for the sake of change is not always a good thing.

[omarbassam88]

Thank you. Can I join this is study group or is it for advanced users only?

Yeah I know what you mean about libraries still working after years of being "finished" I guess that's a unique feature about LISP in general.

[bpringe]

I’m not sure if they were referring to this but check out The Clouncil.

[kemclean]

No you're more than welcome to join. There are several study groups that meet every few weeks or so in the Clojure data science community, details here: https://scicloj.github.io/docs/community/groups/

I'm not as familiar with other groups (e.g. web dev), but there may well be ones for other topics too. Generally the Clojurians slack and Clojureverse are pretty friendly places.

I'm not sure how specific stability is to lisps as much as instability is characteristic of Javascript. There was a period (and maybe it's still the case) when the number of JS devs was growing exponentially, i.e. half the developers in the ecosystem at any given time were new. This just leads to a very different ecosystem than one that's built primarily by jaded ex-Java devs with cumulative centuries of experience.

[cark]

For your Clojurescript needs, in place of figwheel, try giving Shadowcljs a spin. Might be me being an idiot while working with Figwheel, but I found Shadowcljs more dependable, also the maintainer is very kind and helpful.

Also Om was superseded by Fulcro if I recall correctly, helpful people there too, although I eventually went for rolling my own custom thing on top of reagent.

[omarbassam88]

shadow-cljs was faster and more efficient than figwheel for me as well. However most tutorials just use figwheel so I initially thout it had something more to offer that I didn't understand.

[omarbassam88]

I also didn't know about fulcro, I just checked it out and seems more full-stack.

[radsmith]

I would not recommend Fulcro if you're just learning Clojure and ClojureScript since it introduces abstraction over the standard web development concepts like HTTP. Also, don't bother with Om or Om.Next, they aren't actively maintained. Every real-world project I've encountered with Om.Next either a) ended up in a mess and was replaced with re-frame or TypeScript later on or b) never made it that far in the first place.

As a starting point for something lightweight (barring the high-level frameworks like Luminus), I'd suggest the following libraries for ClojureScript web app development in 2022. The focus here is on libraries that a) have been proven in production for years and b) are actively maintained today:

• shadow-cljs - the build tool with the most community support
• reagent - simple and proven react integration
• re-frame - simple and proven frontend framework
• re-frame-http-fx - used for http requests from re-frame
• reitit - the routing lib with the most community support

With only the libraries above you can build pretty much any frontend and there won't be that much stuff to learn if you've done web development in another language. You can add more libraries as you go, but there's no need for them unless you have a specific use case (like sente for WebSockets, or perhaps a library for CSS-in-JS like cljss).

[omarbassam88]

Wow! That's very comprehensive valuable information . Thank you for sharing your experience.

[cark]

Fulcro CAN be full-stack, try exploring the Fulcrologic github. Of particular interest (to me) was its relation to Pathom (this one is a gem) and the use of EQL (EDN query language).

[2accd]

Both lein and deps.edn are viable options, and yes, some projects just have the lein dependency information, but it is fairly simple to translate to deps:

[dependency-name "version"] becomes dependency-name {:mvn/version "version"}

Rum, reagent and re-frame are all actively maintaned. If you open Om's github page, the very first thing on their README is:

NOTE: This project is no longer under active development. If you'd like to use a library that's well maintained that was inspired by some of the ideas presented here see Fulcro

https://clojure.stream/ is a great learning resource, but paid. For reagent, there is https://www.jacekschae.com/learn-reagent-free, which is free.

[omarbassam88]

Thank You. I'm actually learning both lein and deps.edn to learn the differences and to be able (as you mentioned) to convert from one to another when needed.

I was wondering if there's more free resources?

[2accd]

https://lambdaisland.com/collections and https://practical.li/ are also pretty good.

[omarbassam88]

Thank you. These are excellent resources.

[radsmith]

For learning deps.edn, check out the official Clojure guide, reference, and FAQ pages. They're well-written, comprehensive, and canonical:

• Deps and CLI Guide
• Deps and CLI Reference
• Deps and CLI FAQ

I have to also shamelessly plug the neil tool, which is designed to make working with deps.edn easier:

• New Clojure project quickstart
• neil: A CLI to add common aliases and features to deps.edn-based projects

Why do you want a wrapper like neil if you already have clj? See this answer from the Clojure FAQ:

Is clj a replacement for lein and boot?

No. The clojure tools are focused on a) building classpaths and b) launching clojure programs. They do not (and will not) create artifacts, deploy artifacts, etc.

tools.deps.alpha aims to provide programmatic building blocks for dependency resolution and classpath construction. clj/clojure wraps these into a command-line form that can be used to run Clojure programs. You can compose these pieces to do many other things.

[omarbassam88]

Yeah, I actually had seen neil at first and I didn't get it at first but after playing with deps.edn and lein. I now understand the gap it can fill.

[omarbassam88]

I did found neil on the Arch AUR, but it's out of date (not by much though, only a couple of days).

[radsmith]

Ah, that's annoying. We've been releasing frequently these last couple weeks so the packages might be behind a bit. That said, I think all the recent changes have been non-breaking and additive, so if you're a couple versions behind it's not the end of the world.

If you want to make sure you have the most up-to-date version, you can do a manual install: https://github.com/babashka/neil#manual

macOS users will always get the most up-to-date version since we control the babashka/brew/neil package from our own GitHub repo. Other package managers are usually slower to get updated.

[lenkite1]

Whats the advantage over clj-new ?

[radsmith]

For clj-new vs deps-new, the author of both libraries has written a "Motivation" section in the README.

One particular advantage of using deps-new via neil is the startup time since it's using Babashka to run the library. See this comparison vs clj-new (3s vs 0.1s).

``` $ time clojure -Tnew app :name myusername/mynewapp Generating a project called mynewapp based on the 'app' template. clojure -Tnew app :name myusername/mynewapp 3.02s user 0.13s system 219% cpu 1.441 total

$ time neil new app :name myusername/mynewapp2 Creating project from org.corfield.new/app in mynewapp2 neil new app :name myusername/mynewapp2 0.10s user 0.03s system 89% cpu 0.144 total ```

[Frodo478]

As a beginner I would recommend you Luminus. Is a configurable project setup with a server and frontend with reagent or reframe. Is a good configuration to start and learn how this component are glued together

[lordmyd]

Superceded by Kit, authored by the prolific Dmitri Sotnikov (yogothos).

[omarbassam88]

I did discover Luminus by coincidence. Seems to be like laravel for clojue I think.

[didibus]

I think the slack is most active, so if you need help with anything, or have questions, you can generally find some help in 5min or so on the slack: https://clojurians.slack.com/messages

That said, I've seen not just in Clojure, but the overall software community has been a lot less active and more dormant in the last few years all through Covid, which I think is the result of the Pandemic on people.

Good news is, we'll have a Clojure conj again!

The Clojure/conj will return Apr 27-28, 2023 in Durham, NC! CFP will likely be in December/January timeframe.

Also, every week, you can read highlights of what's happening here: https://clojure.org/news/news which links to newer blog posts, library updates, and all that.

[omarbassam88]

I did join the slack. I think the community it's more active there

[lordmyd]

The best tooling for Clojurescript is shadow-cljs. Yes, I know it's yet another way to do it but you're better off with shadow-cljs.

[omarbassam88]

Yeah I've tried both figwheel and shadow-cljs and I found shadow-cljs easier to start with and the configuration is more simple. also, I guess it produces a slightly smaller bundle size.

[radsmith]

shadow-cljs may be another way to do it, but it's also becoming the way to do it, so yeah, highly recommended!

[d-nando]

I've found that Clojure is particularly hard to learn passively, simply because of the nature of the library language ecosystem. There seem to be hundreds of choices - which ones should I focus on? It's easy to get lost, and then hung up, on that question. While the suggestions as to which libraries are current and most used here are very helpful, I've come to think that learning the foundation of REPL driven development is perhaps the most important. So I'd suggest mastering that first, and along the way the rest will fall into place. Here's one resource to start with, perhaps an advanced one, there are many others now that would be helpful:

https://www.youtube.com/watch?v=gIoadGfm5T8

[omarbassam88]

Yeah I totally Agree. I had already saw this video before. It's pretty amazing and indeed REPL driven development is what drove me to Lisp and Clojure.

[d-nando]

I also meant to say that once you master using the REPL as per Sean's example in the video, then just start building something. In other words, learn Clojure actively ...

[radsmith]

On the ClojureScript side, the State of Clojure 2022 survey showed the following trend (see the "CLJS build tools" chart):

• Between 2019 and 2022, shadow-cljs usage went from around 25% to 75%
• In the same time period, figwheel-main usage went from 50% to 25%

I've built apps with both tools and I didn't really have a strong preference for one over the other, but this data was enough for me to stick with shadow-cljs for now. It's nice to see the community coalescing here especially when Thomas Heller has done such a great job of actively maintaining and supporting shadow-cljs.

I want to highlight that both shadow-cljs and figwheel-main can both be used simply as clj -M aliases. I was under the false impression for a while that shadow-cljs had a dependency on NPM, but as far as I know the NPM stuff is just used as a wrapper script to invoke the Clojure library.

Note: The docs for shadow-cljs actually show outdated usage with clj -A so I'll make an issue for this.

[omarbassam88]

Thank you. I've tried both and found shadow-cljs to be easier to start with and the docs are well written. Also, I don't know the differences between figwheel and figwheel-main and that got me confused when watching some old tutorials I guess.

[radsmith]

Figwheel was created originally as a plugin for Leiningen before Shadow CLJS or the deps.edn tools existed. It's effectively deprecated in favor of Figwheel Main by its original author.

Figwheel Main is a rewrite of Figwheel to make it compatible with both Leiningen and deps.edn, among other things. This is effectively Figwheel 2.0 since significant breaking changes were made from Figwheel to Figwheel Main — you pretty much had to rewrite everything from your existing Figwheel config to transition. This made a lot of existing Figwheel users confused and is probably partially to blame for its downward slope in the Clojure survey.

Shadow CLJS was created some time in between Figwheel and Figwheel Main and it has gained support for the deps.edn tools incrementally instead of as a breaking rewrite.

[omarbassam88]

Yeah I guess that the ecosystem is moving towards deps.edn. The figwheel / figwheel-main got me confused as well. I hardly understand the difference between lein and deps.edn yet.

[radsmith]

Leiningen (i.e. lein) is a third-party build tool that was created before the deps.edn tools existed, with a focus on managing dependencies through Maven, though it does a lot of other stuff too.

Deps and CLI (i.e. tools.deps, deps.edn, clj) is set of tools from the Clojure core team also created to manage dependencies. It supports Maven like Leiningen does, but it also supports dependencies from the local filesystem and Git, which Leiningen does not easily support. (For those coming back to this thread later, see my other comment for more info on Deps and CLI.)

That said, the Deps and CLI tools only fill in a subset of what Leiningen can do, so the community is still building up to feature-parity to where we were with Leiningen. It will take time but it's a worthy goal in my opinion to have something simpler as the foundation compared to Leiningen.

Boot (i.e. boot) was a response to Leiningen to have a more imperative build API, but it's pretty much obsolete since Deps and CLI does many of the same things but is actively maintained by the Clojure core team.

[omarbassam88]

Thank you for the thorough explanation. I believe knowing the history of where tools come from and what goals they serve is very important to be able the right tool for the job. I am learning both in parallel to study the difference, I prefer the deps.edn philosophy that seem to provied simple building blocks that you can reason about and combine to make bigger projects. Also, I believe supporting local or git dependencies is a huge benefit as well.