4 ms·

> By the time a beginner learning Clojure has researched and put together their web stack and got it all hooked up and is ready to start, the Django developer a

> By the time a beginner learning Clojure has researched and put together their web stack and got it all hooked up and is ready to start, the Django developer already shipped their project last quarter, iterated on it a few times, and is on to the next thing. Yes, but this is intentional. Django developers are optimizing for "easy" which makes it fast to spin up project after project, Clojure developers are optimizing for "simple" which means way longer time to get the project of the ground, to nail all the design before things start to actually be put together, which makes it easier and faster to iterate on the same codebase after years of working on. Ask the Django developer how easy it is for them to add features after a project they've done that approach with for N years, then compare it to a Clojure codebase, and you'll notice the difference. Sure, I guess this is "downplaying" and "denying", personally I see people who disagree with me as people who disagree with me, that's fine, I thought that was why we were sharing our opinions in this forum in the first place. But anyways, if you're very deep into "frameworks are clearly superior in every case", that we disagree probably matters less. Best wishes regardless!

joshlemer 7mo ago
Rich's Simple Made Easy talk is really interesting and insightful and I still love it but I think now the distinction is brought out too often almost reflexively, and used as a crutch. Yes "simple" and "easy" are not the same thing, but nor are they opposites. Just because something is "not easy" doesn't mean it's "simple". 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. > if you're very deep into "frameworks are clearly superior in every case" This is a mischaracterization of what I have said, and is more like the extreme position that Clojure devs seem to take. The original commenter said that Clojure is wonderful, but it's too bad that [for the people who want it,] there isn't the option of a well maintained, all-in-one, batteries included framework. You deny that this is a problem, saying that actually a well-chosen set of libraries are superior (I guess in every case, because if not then it actually would be a problem sometimes).
- Capricorn2481 7mo ago
  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.
  - r1290 7mo ago
    Wouldn’t touch it with a 10 foot pole. What would you prefer over django of the listed above? Curious.
    - 7mo ago
KingMob 7mo ago
The fundamental mistake of Simple Made Easy was how many people interpreted them as orthogonal (or even opposing) qualities, when that's not inherently true. This led to a lot of Clojure code being simple, but avoiding the hard additional work of also making it easy, and sometimes in even making it complete. The prime example was tools.deps/deps.edn. It largely supplanted Leiningen for new code, but by being simple and minimal, it led to an explosion of ad hoc, custom tooling for 2-3 years afterwards, as everyone rewrote functionality that Lein already had, but tools.deps was missing. (And I say this as someone who once lost a whole week debugging a subtle maven/lein set ordering bug.)

joshlemer 7mo ago

Rich's Simple Made Easy talk is really interesting and insightful and I still love it but I think now the distinction is brought out too often almost reflexively, and used as a crutch. Yes "simple" and "easy" are not the same thing, but nor are they opposites. Just because something is "not easy" doesn't mean it's "simple". 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. > if you're very deep into "frameworks are clearly superior in every case" This is a mischaracterization of what I have said, and is more like the extreme position that Clojure devs seem to take. The original commenter said that Clojure is wonderful, but it's too bad that [for the people who want it,] there isn't the option of a well maintained, all-in-one, batteries included framework. You deny that this is a problem, saying that actually a well-chosen set of libraries are superior (I guess in every case, because if not then it actually would be a problem sometimes).

Capricorn2481 7mo ago
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.
- r1290 7mo ago
  Wouldn’t touch it with a 10 foot pole. What would you prefer over django of the listed above? Curious.
  - 7mo ago

KingMob 7mo ago

The fundamental mistake of Simple Made Easy was how many people interpreted them as orthogonal (or even opposing) qualities, when that's not inherently true. This led to a lot of Clojure code being simple, but avoiding the hard additional work of also making it easy, and sometimes in even making it complete. The prime example was tools.deps/deps.edn. It largely supplanted Leiningen for new code, but by being simple and minimal, it led to an explosion of ad hoc, custom tooling for 2-3 years afterwards, as everyone rewrote functionality that Lein already had, but tools.deps was missing. (And I say this as someone who once lost a whole week debugging a subtle maven/lein set ordering bug.)