4 ms·
Going with XTDB by default is an example of "what do I want for my own projects?" being the first priority as mentioned in the article--I agree that Biff would
by jacobobryant 3y ago
Going with XTDB by default is an example of "what do I want for my own projects?" being the first priority as mentioned in the article--I agree that Biff would be easier for many people to pick up if it defaulted to Postgres/SQLite. My hunch is that building something I personally love is the best long-term strategy for Biff anyway. When XTDB2 is stable I'm planning to have SQL be the default, then those who want to (like myself) can switch easily to datalog. See also https://biffweb.com/p/xtdb-compared-to-other-databases/ https://biffweb.com/p/xtdb-compared-to-other-databases/ for more of my thinking on XTDB.
The main reason I switched from Bash to Babashka for the project tasks (`bb dev`, `bb deploy` etc) is that it allows me to put the task implementations in a library and have Biff projects depend on it, as opposed to copying all the task implementations into new projects (which is what previously happened). This way people can upgrade the tasks by bumping the lib dependency. Some of the tasks also have somewhat complex logic and IMO benefit from being written in Clojure/Babashka.
The only bash script is `server-setup.sh`. I suppose I could rewrite that in Babashka for the sake of consistency, but it doesn't really seem like that big of a deal to me (?).
In response to "install a variety of tools without clear purpose" -- isn't it just one tool, Babashka? I believe that puts it on par with Luminus :).
Agreed that the docs could be better written for those new to Clojure. To really do a good job of this I'd want to do some actual user testing with people as they try out Biff for the first time. Main constraint here is just time. I'm always happy to get specific pieces of feedback and try to act on those (perhaps I could make the jacking-in section less prominent). I actually would love to make a course/series of guides for complete Clojure newbies, but until someone hires me full-time to work on Biff I think I'll have to rely on others to write the beginner resources.
In response to your three points:
1. There's a lot of stuff that goes into a web app :). It's also not clear to me that switching from Babashka to Lein templates + Bash scripts would improve this situation (if anything that sounds like it would involve more disjoint parts).
2. To act on this I'd need more specifics about how things are different in Rails / Django / Laravel.
3. Addressed above. There is a step-by-step tutorial at least (https://biffweb.com/docs/tutorial/build-a-chat-app/ https://biffweb.com/docs/tutorial/build-a-chat-app/).
- jacobobryant 3y agoOh, also re: "No Windows-specific quirks w.r.t. live reload or anything else" -- the Windows caveats mentioned at https://biffweb.com/docs/get-started/new-project/ https://biffweb.com/docs/get-started/new-project/ only apply to "developing in prod", in which Biff deploys your code whenever you save a file. Reloading code during normal local development works fine on Windows, same as in Luminus.
- koito17 3y agoI wasn't advocating for lein templates per se. It's just that Luminus happens to use a single tool (lein) for controlling everything. If anything, I would like a framework that leverages the existing functionality that exists in the Clojure CLI itself. A common pattern in tools.deps based projects, for instance, is to use Babashka as a sort of Makefile replacement and make it act as a thin wrapper around tools.build. I don't like this because it's yet another tool to understand and install on top of tools.build, whereas sticking with the Clojure CLI itself means all you need is...the Clojure binary on your PATH. I am fine with projects that use a Makefile instead of Babashka since pretty much every Mac and Linux machine has `make` installed and it is widely used outside of Clojure, too. So it is not too foreign of a concept when getting people started with Clojure. As for your response with (2), here is an example with Rails: The example app doesn't start with a chat or anything complicated really. Instead, `rails new myapp` gives you a well-organized folder structure, one command to start your web app, and a simple landing page making use of the MVC patterns. The landing page immediately directs you to official Rails documentation for learning what everything in your myapp folder is. When it comes to time to extend a Rails application (add a new model, add a new view, add a new route, etc.), there is pretty much always a "canonical" choice of action. In the case of Biff, there is technically many ways to go about doing each of these things, partly due to the plugin architecture, and partly due to the fact that Biff is built out of independent software and making them synergize for a web app. Does this help?
- jacobobryant 3y agoHmm... I like Babashka's quick startup time, but realistically it might not actually matter. I'll try out a tools.deps-based setup sometime. I would enjoy not having the extra dependency. The description of Rails is helpful--thanks.