JAjacobobryant·Aug 11, 2026Submission
Biff.datastar: lightweight web UIs with Clojure and Datastar
2 points · Open discussionjacobobryant
biff
Clojure2020–2026
jacobobryant / biff
biff
A Clojure web framework for solo developers.
3Distinct people
10Mentions
0Explicit recommenders
1.1KGitHub stars
What to know before exploring
What it is
A Clojure web framework for solo developers.
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year10 dated mentions
Observed mentions: 2020-05-23 01:30:22 UTC to 2026-08-11 15:59:53 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 4 | 2 | 2 |
What Hacker News says
10 sources> If it weren't for those, would Pathom be a drop-in replacement? Or is there different logic?
I could've written biff.graph to work with actual Pathom resolvers. In fact it wouldn't be hard to write a shim that takes Pathom resolvers and returns biff.graph resolvers. Although not all resolvers would work since biff.graph doesn't support everything in EQL (e.g. union queries, attribute parameters).
The query results aren't strictly guaranteed to be the same, so even with a shim I wouldn't recommend dropping biff.graph into a large project that's already using Pathom. And then that's not even getting into all the Pathom features that biff.graph doesn't support at all (lenient mode, plugins, async mode, the graphql adapter...).
But as for the core concepts, yeah I'd say they're pretty close.
> I'm curious in what scenario PathomViz is not g
Read the rest
iving enough info. I had a lot of trouble getting it working tbh
I had that trouble too heh heh--I tried running it I know at least once but didn't succeed. I don't remember exactly what the issue was... but I probably should figure that out.
Even if I got better at debugging Pathom though, for Biff I would still prefer to have an implementation that's easier for users to understand so that ideally they don't even need extra tools to aid with debugging.
FWIW there is an example here[1] of what the biff.graph error looks like when a nested required attribute can't be resolved. That file also has examples of some additional validation logic I've thrown in, e.g. biff.graph will complain if one resolver declares an attribute as a join and another resolver declares it as a scalar. Sometime for our codebase at work I'll probably write some assertions to do those kinds of checks on our Pathom resolvers.
[1] https://github.com/jacobobryant/biff/blob/v2.x/libs/graph/do...
Biff.graph: structure your Clojure codebase as a queryable graph
147 points · Open discussionAs the author of a different project also named Biff, I do have to warn you that half the comments on your HN posts will be people quoting back to the future--though I haven't decided yet if that's annoying or an engagement hack!
[1] https://github.com/jacobobryant/biff
In Bttf is a command line datetime Swiss army knifeI definitely believe Clojure needs a rails. Not only will it help beginners get started, if it can help people get started faster and build fast like Django and rails do, I think it'll help more with adoption.
Biff and fulcro seems like they have a shot at this
Biff- https://github.com/jacobobryant/biff
Fulcro - https://github.com/fulcrologic/fulcro
In Riff: A “mycelium-clj” for the Clojure ecosystem?Rum is used throughout, though mostly via middleware[1], so you (almost) never see any calls to `rum.core/render-static-markup`. But all of the hiccup-style data structures (`[:div "foo"]`, etc) do get rendered by Rum.
htmx doesn't render anything on the backend; rather it gives the frontend more ways to interact with the backend. e.g. say you make an inline form--htmx gives you the ability to display/submit that form without refreshing the entire page, but all the html that's sent to the frontend is still getting rendered first by Rum.
[1] See https://github.com/jacobobryant/biff/blob/6353c406adef034448... and https://github.com/jacobobryant/biff/blob/6353c406adef034448...
In Biff tutorial: build a chat app with ClojureBiff is open source but "alpha quality software"
https://github.com/jacobobryant/biff
In Ask HN: The state of Firebase alternatives in 2020?Thanks! I haven't used a plain JS backend with it myself, but I think that would work well (the majority of Biff is backend code anyway). I haven't exposed a JS api, but doing so should be pretty easy. All of Biff's frontend code is in the biff.client namespace, and the only function you need is biff.client/init-sub [1], which takes:
- an atom, the contents of which describe what data you're subscribing to
- another atom, which is populated with the results of your subscriptions
- a function for handling server-sent websocket events (if your app uses any)
and it returns a function for sending websocket events to the server (which is used for sending transactions + any custom events you define).
[1] https://github.com/jacobobryant/biff/blob/98ad188924bee9121d...
In Show HN: Biff – Self-hosted Firebase alternative for ClojureHi, OP here. I started working on recommender systems in 2016 during my
undergrad, specifically doing music recommendation. I spent about five months
in 2019 trying to make a music startup based on that. However, during that time
I realized that there would probably be more value in having a really good
general-purpose recommender system. i.e. if you're looking for something
specific, use Google, and if you're not looking for something specific, use
Findka. That's the vision anyway.
Some good articles on this topic:
"Search, discovery and marketing"[1]
> Google is very good at giving you what you're looking for, but no good at all
at telling you what you want to find, let alone things you didn't know you
wanted.
"The Big Promise of Recommender Systems"[2] (2011)
> When we evaluate the current generation of recommender systems from the poi
Read the rest
nt
of view of the “recommendee,” we find that most recommender systems serve the
goals of the business instead of their users’ interests. Thus we believe that
the big promise of recommender systems has yet to be fulfilled. We foresee a
third wave of recommender systems that act directly on behalf of their users
across a range of domains instead of acting as a sales assistant.
The algorithm currently is dead simple. Just collaborative filtering without
explicitly taking into account content type. So it's naively cross-domain.
Since the data set is still small, there's no need for matrix factorization. I
recompute the whole matrix every hour and store it in memory. See [3] for the
implementation (it only took 30 LOC). That's a little out-of-date but the
general approach hasn't changed.
For the tech stack, I'm using a Clojure web framework + deployment solution
that I made.[4] It's like a self-hosted version of Firebase (I'm running it on
DigitalOcean). See [5].
[1] https://www.ben-evans.com/benedictevans/2015/6/24/search-dis...
[2] https://www.aaai.org/ojs/index.php/aimagazine/article/view/2...
[3] https://findka.com/blog/rec-sys-in-30-lines/
[4] https://github.com/jacobobryant/biff
[5] https://findka.com/blog/migrating-to-biff/
+1, very excited about this.
They're marketing it in the OLAP space right now, but at some point I'd like to try integrating it with a web framework I've been working on.[1][2] It'd be a more powerful version of firebase's real-time queries. Firebase's queries don't let you do joins; you basically can just filter over a single table at a time. So you have to listen to multiple queries and then join the results by hand on the frontend. Doesn't work if you're aggregating over a set of entities that's too large to send to the client (or that the client isn't authorized to see).
[1] https://findka.com/blog/migrating-to-biff/
[2] https://github.com/jacobobryant/biff
In Ask HN: What startup/technology is on your 'to watch' list?