Getting started with Luminus was fine, but it was often very confusing and I didn't understand a lot, whereas when I added things as I needed them and checked out a couple libraries, I had a lot easier time debugging what was wrong.
What's going to make Coast different?
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..
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.
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.
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]."
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 ?
Clojure strength is its weakness. But yes, there is a long way to make it more beginner friendly
What language can't compose libs?
The main problem is whether developers can.
To me this often is "mental dark mode". You think you're more efficient, but usually aren't.
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.
This is soooo true! I actually really like Javascript but NPM is in such a bad place and it's having effects outside of just it's ecosystem. We just built an app using Nativescript which by itself is actually pretty decent but we chose to use a plugin for a specific feature we needed. But then we kept running into problems with it and, after serious back-and-forth with the plugin maintainer, it turns out his plugin depends on another plugin that has had a known, very serious bug. And that project's maintainer has known about it for at least nine months but he has said he doesn't have time to fix it. I take that to mean he's lost interest and the project is effectively dead unless someone else comes along to take the reins in maintaining it. Which we assume means the original plugin that we chose to use is also effectively dead because it so heavily relies on the other plugin.
In the end, we just removed all of the plugins as we determined they were hostile to our productivity and routed around them by rolling our own solutions.
This might have been true back in the day before security issues were a thing, but it no longer holds true.
Particularly the case in public web apps.
If someone isn’t maintaining it, don’t use it.
(Obviously it depends; for a test framework, clearly not true, but for example for the “LEGO block” you pick for auth, or say, XML parsing... yes, it matters; the point here is specifically that the “take what you want” approach to a web framework results in scattered maintenance models for different components, and that is categorically bad for long term maintenance of a web app)
If there is no activity on the repo it doesn't mean that someone is not maintaining it.
Oh, like framework developers always know which LEGO block to include in their framework. Like Rails had no vulnerabilities in the past.
> If someone isn’t maintaining it, don’t use it.
Well, good luck with not using 3/4 (or even more) of software in existence. I bet the kernel that is running on your laptop depends on the software that hasn't been updated for 30 years.
Here's why I think "just use composable libraries" is a bad idea:
First it isn't very friendly to new developers. You tell them to go out there and find their libraries and they have zero clue where to start.
The second problem is its not very friendly to developers with a couple years experience either. Frameworks take care of so much stuff that most people don't know they need to take care of. Not just obvious things like connecting to an RDBMS but also very basic stuff that every website will need like CSRF protection, session management, etc.
And finally, when you rely on a wide variety of micro libraries you're actually relying a wide variety of other developers. What is going to have more support and development in the future: 10 libraries split across 10 developers with varying levels of commitment, or 1 framework with a group of developers working together on it?
You don't need to build your framework like Rails or Django. You could make it easier to plug in other libraries. But it should have a sane default for everything it needs for the benefit of both new and intermediate developers. Spring kinda works like this. It's easy to use Spring libraries for different parts but you can also just use your own.
Even when they could have worked without it, and they over Shadow competitors in the space, why use that shiny new router library when my framework already has an one that's "easy" to reach
And then of course the worst thing to happen to a code base, the framework it's built on falls out of favour and you can't hire devs or get security patches for it anymore
"don't put your eggs in one basket", and "developers know the benefit of everything and the cost of nothing" applies here
I think if a framework is to be successful in Clojure it needs to not be intertwined with itself in the "simple made easy" sense
Additionally if the "interface" is data like you might get lucky enough that you get multiple implementations, like many cljs libraries support the react interface
With declarative programming we could certainly keep the intention of code the same whilst changing out the implementation but it would require careful coordination between library creators and a open data interface so that new requirements can be satisfied later down the line and even then multiple variants to serve completely different approaches
all that to say, if there is in the Clojure ecosystem analogous, I'd like to hear about it.