I'm allocating some more time to work on Biff/other experimental projects, so might have another release in the coming weeks. Some things it would probably include, in order of descending significance: • Remove CLJS from the template project and replace it with https://htmx.org/. I think htmx fits much better with Biff's niche than a full-on SPA, and anyone who wants CLJS can always add it back in. I'll put a section for that under Recipes (https://biff.findka.com/#recipes) • Also change the template project so it's set up for developing in prod by default. Over the past several months while working on my startup, I've been doing the majority of development over an nrepl connection to prod rather than starting the app on localhost. It really is quite nice. Given Biff's emphasis on solo developers/early-stage projects, I think Biff should lean into this kind of thing. IMO it'd also be a nice way to highlight Clojure's interactive development to non-Clojurists ("If you've embraced testing in prod, why not take it a step further..."). I'll add another Recipe section that covers switching to a traditional build-release-deploy process. I'll probably also leave in the command for building and releasing at least, so then we can just say "if you want to deploy in some other way, here's the uberjar + env file, do whatever you want with it". • Add a biff.xt namespace and deprecate biff.crux. I'm going to use this as an opportunity to make some technically-not-breaking changes (e.g. I'll stop wrapping the db in a delay, so you won't have to do @db anymore), so it won't be a drop-in replacement. The template project will use xt of course, and existing projects can either migrate or just stick with biff.crux. I'll include migration instructions. (probably won't be much stuff other than the @db thing and s/crux/xt/ everywhere). • Simplify Biff's use of Reitit. Right now there's a use-reitit component, but I've realized that it's pointless since we don't need any runtime config to build the routes. So the template project will have (def router ...) and (def handler ...) somewhere and then pass the handler into start-system (instead of passing the routes in and letting use-reitit build the router and handler, which is what it does now). Besides simplifying the code, that'll make it easier to redefine the routes at runtime (which will facilitate the developing-in-prod thing), and it'll make it more obvious how to change the options passed into Reitit or replace Reitit with another routing library. • I'm going to add a couple convenience macros for Reitit so you can define a route and the handler at the same place, like so:

(biff.util/defhttp "/foo/" :get
  [system params]
  {:status 200
   ...})

(def routes
  [["/bar/"
    (biff.util/http-routes)]])