In my experience, Clojure was a huge pain in the ass to get into, and there's a non-zero amount of community members that talk about it in nothing about aphorisms. I really wanted practical advice, but getting people to talk normally about it was an uphill battle. This made me almost quit several times. But it is a very pragmatic language underneath (which you've already mentioned).
But I'm not sure a framework is really going to change that onboarding process, or help with network effects that much. Elixir has a de facto framework, but it's barely more popular than Clojure. I mean, we had Leiningen starter kits and we have Kit. But what's confusing to me wasn't setting up a project, it was learning how it was wired together. Wiring small libraries together and just passing data can feel surprisingly leaky, and I don't really have to peak into the internals of Laravel the way I do Clojure projects.
I think Biff is a promising step in the right direction. I think the way it has wired things up is easier to follow. But for whatever reason, they made the choice to use XTDB as a default, which is a huge cognitive burden for newcomers. They have an article on how to use something else instead, but this is already getting out of the "it just works" territory if you haven't even learned Clojure yet. But the author is a really nice and talented person, and I am looking forward to seeing where it goes.
> I think there are lots of well maintained Django projects. In fact, if I do a search on AI and on google for what one web stack probably has the lowest overall total cost of ownership including maintenance years down the line, Django usually is what comes up, without even specifically searching for/mentioning it.
Having used Clojure, Laravel, Spring, and Django, I wouldn't touch Django again with a 10 foot pole. I don't know what you're referring to by "doing a search of lowest cost of ownership" but it sounds pretty unscientific. Anecdotally, I do legacy apps, and I have picked up people's Django apps, and I've never loved what I saw. It's a classic fast to start, slow to maintain framework. Huge businesses have been built on it, but huge businesses have been built on everything.
> I'm not sure a framework is really going to change that onboarding process, or help with network effects that much
having one commonly accepted and recommended way does improve onboarding, because it collapses the decision space beginners face. right now they are supposed to make decisions (not even directly, but just through selecting one of the many frameworks) about things like:
1. which project templating tool to use? (lein, clj-new, neil)
2. which dependencies management tooling to use? (lein, deps)
3. which build tooling to use? (lein, tools build, boot)
4. which web server? (jetty, httpkit, undertow)
5. which routing library? (pedestal, reitit)
6. which templating engine? (hiccup, rum, selmer)
7. how to deal with javascript and it's build tooling? (clojurescript with a host of it's own decisions, bolt ts/js and wire it yourself, dodge that completely with htmx)
whats worse - most of the alternatives overlap in various ways, so making the "best choice" in order to reduce future headache induces quite a bit of anxiety.
yes, multiple frameworks exist that make those choices for you, but then you inevitably hit the problem that some of the components haven't been updated in a while, so documentation is out of date and when you try updating it just for your project you need to fix the framework plumbing and due to number of frameworks, the corpus of useful information on the internet is quite fragmented and the community help is limited, and on and on.
none of this is good beginner experience.
and don't get me wrong, choice by itself isn't bad, focus on composability of smaller libraries is important, dominant framework is not going to improve anything when it locks people into bad decisions.
what we lack is convergence behind a single "reference stack" of libraries that ought to be good enough for the general case and a minimal framework of plumbing that doesn't require dozens of files just to get started.
there doesn't need to be a single way of doing it, but there needs to be a single recommended way of doing it.
I don't disagree with what you're saying. But by "onboarding process" I mean the effort of getting more people into Clojure, not the experience for a single person.
What I'm suggesting is Elixir has everything you're talking about in Phoenix, yet it's still an extremely niche language most people haven't even heard of. Because come on, it's a totally different paradigm than what people are trained to program in. I understand the mental math of "easier means more people," but I don't think that's really going to cut it for Clojure. I had full projects spun up the minute I started learning, but that wasn't where the difficulty was.
So yes, I think having a solid framework is good for Clojure, but the original person suggested it's not popular because it doesn't have one, and I just don't think that's true.
> the original person suggested it's not popular because it doesn't have one, and I just don't think that's true
i agree that it's not a sufficient condition, but it's an important factor and it would significantly improve the onboarding process by collapsing the decision space beginners have to navigate
even going by your definition of onboarding (the effort of getting more people) - dispersing that effort across multitude of dimensions and directions is certainly less effective than coordinating and converging
not intending to have an argument about popularity, but since you keep bringing up elixir - there's a lot that can be said about elixir/phoenix as to why they aren't more popular than they are, but they are more popular than clojure in every recent ranking i've checked ¯\_(ツ)_/¯
if anything, elixir/phoenix is a good example for how strong default improves onboarding and ecosystem cohesion, even if it doesn't make the language broadly popular
i don't look at it from perspective of "what should clojure do to be more popular than php" - there are fundamental reasons why that just can't happen in this timeline
i look at it from perspective of "what does this ecosystem lack that makes it hard for beginners to get going and stick"
and lack of "single recommended way of doing it" is at the top of my list
But I'm not sure a framework is really going to change that onboarding process, or help with network effects that much. Elixir has a de facto framework, but it's barely more popular than Clojure. I mean, we had Leiningen starter kits and we have Kit. But what's confusing to me wasn't setting up a project, it was learning how it was wired together. Wiring small libraries together and just passing data can feel surprisingly leaky, and I don't really have to peak into the internals of Laravel the way I do Clojure projects.
I think Biff is a promising step in the right direction. I think the way it has wired things up is easier to follow. But for whatever reason, they made the choice to use XTDB as a default, which is a huge cognitive burden for newcomers. They have an article on how to use something else instead, but this is already getting out of the "it just works" territory if you haven't even learned Clojure yet. But the author is a really nice and talented person, and I am looking forward to seeing where it goes.
> I think there are lots of well maintained Django projects. In fact, if I do a search on AI and on google for what one web stack probably has the lowest overall total cost of ownership including maintenance years down the line, Django usually is what comes up, without even specifically searching for/mentioning it.
Having used Clojure, Laravel, Spring, and Django, I wouldn't touch Django again with a 10 foot pole. I don't know what you're referring to by "doing a search of lowest cost of ownership" but it sounds pretty unscientific. Anecdotally, I do legacy apps, and I have picked up people's Django apps, and I've never loved what I saw. It's a classic fast to start, slow to maintain framework. Huge businesses have been built on it, but huge businesses have been built on everything.