The ongoing discussion for Biff [1] prompted me to re-share my post because I'd like more people to understand this "other way". Outside Clojureville, it is not obvious most of these Clojure "frameworks" are not monoliths.
The consummate Clojurist's default (and very normal-feeling way) to build a web application (or any application for that matter) is to roll their own web stack from production-grade libraries.
Of course, this state of affairs is a double-edged sword, just like is true for traditional web frameworks. In my post, I try to go into the whys and the wherefores, building upward from first principles.
I'd say the nice thing with the Clojure way of building your own stack is it becomes quite easy to swap parts out. On a previous project we swapped out our web server three different times with minimal changes (jetty -> aleph -> httpkit) as for the most part they all shared the same interface.
After a while you get good at seeing where you want things to be configurable and where you don't. It also gives you the confidence to roll your own micro stack/framework which means you are not dependent on third party aggregates to adopt new features.
It is a neat example of how an org can structure and manage multiple projects and services in a single git repository. They've use Leiningen to achieve their objective.
> The Common Metadata Repository (CMR) is an earth science metadata repository for NASA EOSDIS data. The CMR Search API provides access to this metadata.
> Building and Running the CMR
> The CMR is a system consisting of many services. The services can run individually or in a single process. Running in a single process makes local development easier because it avoids having to start many different processes. The sections below contain instructions for running the CMR as a single process or as many processes.
The problem with this approach is that (esp. for hobby projects) updating stuff is a bit tedious. Let's say you have a relatively bare bones project in Rails or a PHP framework you have a couple of dependencies that people usually use together, so upgrading can be quick and painless.
I've now had it several times in the years-long lifespan of small clojure web projects that people have moved on and the thing (framework-ish) basically doesn't exist anymore and going by the issues it only had like 10 users in the first place.
It's not the end of the world, and fortunately there's not a lot of needless churn, but I guess I would prefer to have this "I am trusting project x and I only have to care about their releases (pre-testing all the moving parts) and then my 5 dependencies" and instead I have 20 dependencies/moving parts for my web app.
Yes, I'm lazy and I don't think it's a problem in an env where you have a proper dev workflow anyway.
How often do you have to do that though? I was under the impression that Clojure was a bit like CL in that old code will keep working basically forever. Unless there are new features you need, you just leave most libs alone to do their job.
This can be a culture shock for people coming from places like ruby, python, javascript... But a lot of clojure libraries are actually just "finished", they're not abandoned.
If you need the next level of UX dynamism and or realtime updates and or multiplayer. I've handled a billion checkboxes[1] with clojure, sqlite and datastar (realtime hypermedia) just fine.
Following writing advice or post structuring guidelines is not in my job description at evalapply.org Luckily, Michael Hamburger offered a legitimate excuse in his classic (so I'm told) essay, "An Essay About Essays": https://substack.com/@bombaylitmag/p-162583447
Hot take: People on the internet make wild claims without any sources or data to back up what they're saying, and they think that's OK because they preface it with "hot take:" so whatever you reply, doesn't matter, because it was supposed to be a "hot take" that the author cannot really defend when needed.
[+] [-] adityaathalye|9 months ago|reply
The consummate Clojurist's default (and very normal-feeling way) to build a web application (or any application for that matter) is to roll their own web stack from production-grade libraries.
Of course, this state of affairs is a double-edged sword, just like is true for traditional web frameworks. In my post, I try to go into the whys and the wherefores, building upward from first principles.
[1] Biff – a batteries-included web framework for Clojure https://news.ycombinator.com/item?id=44037426
[+] [-] andersmurphy|9 months ago|reply
I'd say the nice thing with the Clojure way of building your own stack is it becomes quite easy to swap parts out. On a previous project we swapped out our web server three different times with minimal changes (jetty -> aleph -> httpkit) as for the most part they all shared the same interface.
After a while you get good at seeing where you want things to be configurable and where you don't. It also gives you the confidence to roll your own micro stack/framework which means you are not dependent on third party aggregates to adopt new features.
[+] [-] elchief|9 months ago|reply
https://github.com/metabase/metabase
[+] [-] adityaathalye|9 months ago|reply
NASA's Common Metadata Repository is worth exploring too https://github.com/nasa/Common-Metadata-Repository
It is a neat example of how an org can structure and manage multiple projects and services in a single git repository. They've use Leiningen to achieve their objective.
> The Common Metadata Repository (CMR) is an earth science metadata repository for NASA EOSDIS data. The CMR Search API provides access to this metadata.
> Building and Running the CMR
> The CMR is a system consisting of many services. The services can run individually or in a single process. Running in a single process makes local development easier because it avoids having to start many different processes. The sections below contain instructions for running the CMR as a single process or as many processes.
(edit: add relevant context for quick reference)
[+] [-] ramirond|9 months ago|reply
We are also hiring Clojure devs: https://www.metabase.com/jobs
[+] [-] lelag|9 months ago|reply
The web frontend is written in TypeScript/React.
[+] [-] wink|9 months ago|reply
I've now had it several times in the years-long lifespan of small clojure web projects that people have moved on and the thing (framework-ish) basically doesn't exist anymore and going by the issues it only had like 10 users in the first place.
It's not the end of the world, and fortunately there's not a lot of needless churn, but I guess I would prefer to have this "I am trusting project x and I only have to care about their releases (pre-testing all the moving parts) and then my 5 dependencies" and instead I have 20 dependencies/moving parts for my web app.
Yes, I'm lazy and I don't think it's a problem in an env where you have a proper dev workflow anyway.
[+] [-] wild_egg|9 months ago|reply
How often do you have to do that though? I was under the impression that Clojure was a bit like CL in that old code will keep working basically forever. Unless there are new features you need, you just leave most libs alone to do their job.
[+] [-] epgui|9 months ago|reply
[+] [-] librasteve|9 months ago|reply
that’s HTMX, Air, Red & Cro btw
that said … I am a true believer in HTMX for the right amount of UX dynamism and I don’t initially get solves that piece
[+] [-] andersmurphy|9 months ago|reply
[1] https://checkboxes.andersmurphy.com
[+] [-] adityaathalye|9 months ago|reply
Following writing advice or post structuring guidelines is not in my job description at evalapply.org Luckily, Michael Hamburger offered a legitimate excuse in his classic (so I'm told) essay, "An Essay About Essays": https://substack.com/@bombaylitmag/p-162583447
[+] [-] unknown|9 months ago|reply
[deleted]
[+] [-] oldpersonintx2|9 months ago|reply
[deleted]
[+] [-] ertucetin|9 months ago|reply
[+] [-] diggan|9 months ago|reply
[+] [-] dbbljack|9 months ago|reply