Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
# 90 Jacob O'Bryant
56 Plays1 year ago
Jacob joins us to talk about his Clojure journey and the evolution of Biff web framework. Checkout his work on https://github.com/jacobobryant and https://biffweb.com
Recommended
Transcript
Introduction and Show Pacing
00:00:15
Speaker
Yeah, welcome to Japan. 90? Yeah. Yeah. Welcome to Japan 90. Hello. Each episode kicks pace with my age these days. We're pretty slow to point them out. So, you know, it's kind of like...
00:00:37
Speaker
We're finally catching up to Ray's age. I mean, we're not there yet, but we will eventually. For three years.
Guest Introduction: Jacob and Transition of Topics
00:00:45
Speaker
Anyway, let's, let's, let's hear from our guests. Hey, Jacob, welcome to DefN.
00:00:54
Speaker
Good. So I think we've been talking about gardening and games and shit and all that interesting stuff. Now we can get into boring things, you know, for people who want to be bored while doing gardening, our game. Some useless crap into their ears. Anyway, that's most of the stuff that Ray and I do, but not from the guests anyway.
Exploring Biff Framework
00:01:17
Speaker
One of the things I was going to say was I already kind of biffed it once in the show, so kind of like leading into the subject here. Yes, that's been a great sort of sort of acronym for this. I was thinking if I ever write a book, I could call it Biff Your Next Web App. Yes.
00:01:44
Speaker
I think it can be it can be the official book of Biff, right? Yeah. Oh, yeah. Yeah. Yeah. Yeah. Exactly. Yeah. Maybe maybe we should tell people what Biff is. I'm pretty sure in everybody in the closure community heard about it. But it's a good idea to give a bit of an introduction. The FBI listen to this, they need to know the context. Yeah. Yeah.
00:02:10
Speaker
Yes, absolutely. OK, yeah, yeah. So let me give the 30 or maybe 48 second instruction. So BIF is a closure web framework. And it's fairly lightweight. It's like, I think, I mean, last time I checked, it was around like 2,000 lines of code, maybe. It's not like a huge Vulkan thing. But it grew out of my own projects.
00:02:36
Speaker
For the past four and a half years, I've been a solo bootstrap founder, or at least solo for most of that time. Anyway, and so I've been working on all this random stuff. And especially at the start of that, I sort of bounced around between a lot of different deployment things and basically was trying to figure out, how do I want to make my own Clojure web apps? And just trying to learn how to do that. And so eventually, after a year and a half, I kind of settled on it, figured out a stack that I really liked.
00:03:06
Speaker
Um, and so that turned into Biff, so I basically just packaged it up and wrote some docs and basically anyone else wanted to use it. Um, talk about like, so, so I like released it. It wasn't like, I do like a release every like six months or something and be like, Hey, there's new Biff version, but I don't think anyone other than me was really using it much. Um, until like after like another year or like a year and a half of like myself dog fooding it and then like experimenting with different things, it got to a much more.
00:03:36
Speaker
sort of stable mature phase. And so that was about like, let's see, a little over a year ago is when I did another big like release.
Programming Journey to Clojure and Language Comparisons
00:03:47
Speaker
It's kind of a rewrite. And so ever since then Biff has been in a much better state and actually a good state for like people other than me to use and people have been using it and it's been slowly getting more adoption, which is exciting.
00:04:02
Speaker
So what was the sort of, what was the problem when you came to closure and you're looking for web, you know, doing your own thing? What was the problem with what existed? It was wrong. It was just terrible. I wouldn't necessarily say like, like there wasn't like a big problem per se. It just kind of, you know, I mean, it just takes a while to kind of get familiar with the ecosystem, right?
00:04:30
Speaker
And so I was trying out all these different things. And also, I'm like lots of hackers. I just like to try out random stuff. And so I was doing Datomic. And I had this app on Datomic Cloud Ions, which was cool. I'm absolutely overkill for what I was doing. But so that's cool. And I got into some of my, at one point, I had a co-founder. And he introduced me to,
00:05:00
Speaker
the essay from Tonski, which is the web after tomorrow, if you're familiar with that one. So that was very interesting. And we were interested in that whole idea of like, oh, how can you make this cool web stack where it's like, it doesn't feel like you have two separate places, right? Like the back end and the front end, it's just like one place. So I was very interested in that.
00:05:19
Speaker
It's interesting that it's tomorrow, because that's where we started. We're circling back to tomorrow being yesterday. The web before yesterday. Yeah, exactly. The web after yesterday. The web after yesterday, yeah. The web before the day after tomorrow. Yeah. So anyway, so yeah.
00:05:48
Speaker
So yeah, so I just kind of had this tendency of, one, I'm trying to build apps, but two, I'm also just trying to experiment with cool ways of building apps. And so kind of two counterproductive forces there, perhaps. So yeah, so I was doing stuff on the atomic cloud ions for a while. And it was just sort of overkill for what I needed.
00:06:16
Speaker
And especially if there's like a lot of AWS complexity and the benefits, like there are benefits to that, but not for me
Experiences with Firebase and System Architecture Challenges
00:06:24
Speaker
as a solo person, you know, just doing little side projects. So I did, I ended up doing Firebase actually for a few months with Closure Scripts and actually really liked that. Firebase is very interesting. And, and they, I mean, they have like, like their database, they have like the,
00:06:42
Speaker
the real time subscription stuff, you know, around the front, you can say, you know, I want this and get it. And, and that's kind of related to the whole web after tomorrow thing. Where the sort of the data syncing part is just sort of taking care of from the back end is just sort of this, this appliance that you don't necessarily have to do a whole lot with. So I was like, messing around with that. And I wrote a bunch of
00:07:06
Speaker
like additional cool closure stuff on top of the Firebase database. And so that was fun. But even that, after a few months, I decided it would be kind of nice to just have a normal JVM
00:07:22
Speaker
back end on a persistent process instead of putting everything into these serverless functions on Firebase. I think I recently saw some, I think, meme or a joke. Like, hey, there is a graph, like a number of clients, which is basically zero. Our serverless app is now clientless.
00:07:48
Speaker
Well, it's all lesbian. It's also clientless, so I don't know. It's pay as you go, so there is no expense. Nothing ever happened. It's the ultimate in the cost of famously. Sorry. Yeah. Okay. But this Firebase thing, this was after Google bought it, I guess. So it's the Google version. Yeah. Yeah. So it's been Google for a while. Yeah. Yeah. Okay. Yeah. Sorry. Yeah. It's been a while. Yeah.
00:08:18
Speaker
I think Firebase wasn't the idea was that if I'm wrong with Firebase it was kind of like this whole like system in a box thing so you could just like save your data and then it would get it back it would all just be like
00:08:31
Speaker
It's very ergonomic. Oh, yeah. And that's a large part of what appealed to me. It's got all this stuff. So it's got the database, but it's also got hosting for your static frontend. And it's got authentication. That was huge. And that's actually
00:08:50
Speaker
If I remember correctly, I think that's how I started using Firebase is started like just using the authentication with my atomic cloud ions. And I decided, you know, this is
00:09:06
Speaker
I'm not sure if you're old enough to remember this shit, but this seems like enterprise fizz buzz, you know? Just make it as complicated as possible to do like tiny thing. He's putting up his IBM mainframe to his arm dial mainframe. Yeah, exactly. Because there's one assembly instruction in the arm dial, but he really needs it. And then it is multi-cloud, multi-region, all that other crap.
00:09:40
Speaker
just in case our one client moves from one region to another region. Meanwhile, we're using it to fill in our weekly timesheet. Sorry, I mean, I don't want to, you know, say you made up wrong architectural choices, but you know, it's fun. I'm sure it was fun. I learned a lot. Yeah.
00:09:59
Speaker
Yeah, exactly. We have more regions than clans.
00:10:07
Speaker
Yeah. And honestly, that's kind of been the progression over the past four years that I've been doing stuff is started out with doing all this cool, interesting architectural stuff and then gradually realized, oh, you know, I don't really need this.
00:10:22
Speaker
I also don't really need this, I also don't really need this. And so now like, like, you know, cutting to the end of the story, Biff has, so Biff even, Biff started kind of like halfway through that, you know, and so like we've had all this like interesting stuff going on. We're not on a big hurry, you know, it's like, yeah, exactly. We went one and no one liked the picture. We'll get to this like one function ring handler a bit later.
00:10:46
Speaker
In fact, in fact, last week I ended up, I just deleted all the biff code. It's just a single page. It says start with the close client role and here's how you write another world function.
00:11:03
Speaker
So it was beefy and then nowadays beef. So slowly it was way more heavier enterprise framework. How did you get to there, by the way?
00:11:19
Speaker
come to closure because, you know, building all this stuff, this, this datomic and, you know, so was there, was there, was there period before closure that you were in darkness and then, you know, how was it? And how did you see the light? Yeah. So I've, um, basically program, I read a lot of program essays, um, which now that was on the survey. So apparently like 16% of people who fill out the survey, I got into closure thanks to programs. So I'm proud of that.
00:11:49
Speaker
demographic. So yeah, like Redways many program essays in high school, which also is why I got into startups, which is a little bit of a mixed bag. Closure has has been a much better investment, I think. But anyway, so I've been interested in lists for a while. And, and I wrote like,
00:12:13
Speaker
30 lines maybe of Common Lisp in a high school just like playing around. But like mostly I was doing Python and honestly a lot of Bash. I wrote a lot of stuff in Bash that should have been written in Python probably. But I was messing around with Linux in high school and stuff. Cool stuff, cool stuff. But anyway, anyway, so like fast forward. So I got into college
00:12:38
Speaker
I'm still doing my Python for side projects. And of course, I did some Java. And in high school, I had done a bit
Introducing HTMX and Interactive Web App Development
00:12:45
Speaker
of Java learning, like Android apps and stuff, which I've since worn off. But yeah, so in college, then I started getting into some undergrad research projects. So I finally had an opportunity to start spending more time on my own projects again, instead of just doing assignments and stuff.
00:13:04
Speaker
And so I was finally, OK, this is my chance. This would be a great time to learn Lisp. Only question is, should I use Common Lisp or Scheme? Yeah. So I started doing some Googling. And then I don't remember where I first found out about it, but learned about, oh, there's this closure thing. That sounds kind of interesting. This was in mid, this was probably around 2015, by the way, 2016.
00:13:30
Speaker
And anyway, so I did some more Googling. I was like, okay, should I do a closure? Like, I don't know. And someone asked, or no, someone posted a tweet and they said they asked Paul Graham over an email, you know, what should, which list should I use? And he responded and said, start with closure. I was like, all right. PG has spoken. That's closure.
00:13:50
Speaker
the startup guard off the U.S. So yeah, so I started doing like part-time closure stuff for my own projects during college and graduated, worked for a year at a scholar shop. And so did that for a bit. And then after a year, decided to quit and live the dream as a full-time startup founder. And so then since then I started doing full-time closure.
00:14:17
Speaker
Nice. How did you find the difference between scholar and closure though? Because I did scholar as well and so did Vijay, I think. Yeah. I mean, this is like five years ago, so I've already purchased it from my memory. It was garbage collected already. Yeah, let's see. I do remember
00:14:59
Speaker
Yeah, I think it depends on the type, well, not the type, but the type of the Scala code that you're exposed to. And because, you know, you could write Java directly in Scala and you could write Haskell way of more functional thing. You can mix both of them. And now you can write something that looks like Python.
00:15:14
Speaker
I vaguely remember the type system being somewhat restrictive.
00:15:19
Speaker
you know, the full circle with Scala 3. Anyway, yeah, yeah, yeah. It's really amazing. It's one of those literally following the Gartner hype cycle curve, like it went shot up like Scala is everywhere. And then now there is less, less noise around it in the community has been a bit, um,
00:15:42
Speaker
Yeah. Popcorn, worthy of fun. Yeah. I don't know what is the right word. Dramatic, I think. Anyway. Overall, I did like Scala, though. It was pretty nice. I liked it more than TypeScript. For some reason with JavaScript, every time I'd write a piece of code, I'd have to just
00:16:07
Speaker
do way too many like array dot from something something so I can just put it in a map and filter a scholar is a bit more functional out of the box, which is nice. Yeah, that's true. Like, not bad. But yeah, yeah, not enough parentheses. Yeah, exactly. I think the thing I the thing I found, like, from scholar to closure, which is the biggest thing, I think, and it's still a favorite thing of mine closure is just reaching into a map.
00:16:36
Speaker
to get to another map, to get to another map, to get to a property, to get to a data item is like one line is so trivial. But you have to do that in a class system. It's just basic help, you know? And then you got options. Yeah, yeah. All this stuff. Yeah, exactly. Yeah, it's just like, I just want to get the data. You know, it's like, why do I have to fight? You know, so yeah, that's the thing that really
00:17:04
Speaker
I think then you end up with, maybe I'm completely wrong here, maybe, I think then you end up with something called lenses in Haskell, like there is a bit of weird shit in there. But anyway, let's not make it a type system podcast because, you know. Exactly. Yeah. You don't want to get that much engagement. Exactly. Yes.
00:17:29
Speaker
We don't want to appeal to that bigger audience. No, there is no way. The five people who are listening is enough for us. But how did you, because as Ray was mentioning, we have this luminous and we have these different templates and we have different ways of building things.
00:17:49
Speaker
And also pretty much every Closure project seems to have one or the other flavor of React thing. So how did you end up choosing? Because, correct me if I'm wrong, because for me it felt like this is one of the very opinionated, like, you know, you pick your components and this is how you're gonna build it.
00:18:12
Speaker
So how did you reach to that opinion? This is how I want to build a thing with. Yeah, sure. So it's a little bit path dependent. So I guess absolutely one important factor is
00:18:27
Speaker
it's kind of what I was mentioning earlier is that it started out sort of me experimenting with like these very different ways of doing things. So like with the original version of both, like there was nothing else like like I was doing something that was very new, which is like I was basically I was
00:18:48
Speaker
rebuilding something like the Firebase database functionality on top of XTDB. And that was really the impetus, is that I sort of had this epiphany and I realized, oh, it actually wouldn't be that hard to do just a custom homegrown thing where you can have clients say, OK, I want to subscribe to this database from XTDB and have it work similarly to Firebase.
Practical Experiences and Backend Focus with Biff
00:19:14
Speaker
So that was the original impetus.
00:19:17
Speaker
was building that and trying to explore that sort of way to build stuff. But then, as I mentioned too, then over time, after, I don't know, maybe eight months or so of doing that, I realized that being said, the stuff I'm building is like crud apps.
00:19:34
Speaker
They're not even multiplayer apps or anything. The stuff I build, most of the interesting things happen on the back end. They're mostly recommender systems, so there's a little bit of very basic machine learning stuff going on. But the front end is not complex.
00:19:54
Speaker
And so all this fancy stuff of like, oh, subscribeable queries and blah, blah, blah. You know, at the end of the day, I realized like, I don't actually need this. So I switched to just doing, um, just multi page apps, like server rendered apps stopped using react stop using closure script. Um, and then Biff kind of bifurcated because I,
00:20:15
Speaker
At that point, I changed this, so it would ask you when you made a new project, like, OK, do you want a React app with a Closure Script or just one multi-page? Because I myself was using this multi-page thing, but I didn't necessarily feel like that was the best approach for every project. So I wanted people to have the Closure Script stuff and all the fancy stuff I had built. But I wasn't actually using that myself, so I wasn't really getting any better. So it was kind of in this weird in-between moment.
00:20:46
Speaker
And then let's see. I'm just kind of remembering the timeline.
00:20:52
Speaker
Yeah, but but yeah, and so then eventually like I I actually htmx. Um, so I started hearing about htmx a bit um, and that was pretty interesting and and And that kind of made like that felt like a way to go back to having like just one Default stack that would give people right? Yeah, but have it still cover enough cases that it wouldn't be like You know half the people who use bif like get into it and then immediately like okay now I have to add in closures because something
00:21:24
Speaker
So to answer your question, as far as all these other things in the ecosystem, like line templates, and luminous, and fulcrum things, I'd use them a little bit.
00:21:41
Speaker
I probably should have started with Luminous. I don't know. Like maybe if I had started with Luminous, like Biff wouldn't exist. I don't know. Like at this point, like looking at Biff and looking at Luminous and Kit and Fokker and all these other things, like there's absolutely like differentiators in there. So it's totally like they're doing different things. And so it's good. I'm glad it exists.
00:22:04
Speaker
But yeah, I would do not use a principled approach to get to that point. Hey, you can always, you can always, you know, now you can rebuild the history, you know. Exactly. That's how software works, right?
00:22:25
Speaker
is planet. And then the requirements are there. And after 70 years, we have amazing software. That's how all the stuff works. Listen, Jacob, I mean, you know, I'm ashamed to say that I don't know what HTML is. I've heard of it. I mean, you know, it's kind of like it's
00:22:45
Speaker
I watch conference talks, but HTML feels like that side of like, like, like, front end porn or whatever that I just never felt that I never looked at. Maybe I should stop that analogy, actually. No, no, that's a good point. And I have to say, every time I try to research like, like something in the JavaScript ecosystem, it just feels like this fractal.
00:23:15
Speaker
And then like, you hear about one library, I'm like, Oh, that's interesting. Like, like, how does that work? And then when you're reading the read me for that, you find out about like seven other things. And this is just like, Oh my goodness. Like, and, and so like closure on the other hand, it is so nice because, because you can actually know like, Oh yeah, I feel like I have an idea of, of sort of everything that's in the community. And then, you know, there comes out every once in a while. Oh yeah. It's at a pace that I can actually integrate into my brain and
00:23:44
Speaker
and not just feel completely overhearted. Anyway, yeah, I totally forgot your question. What was it? HTML? Can you humor me with an explanation of HTML? Because maybe it's not the only sort of old backend dude who doesn't know this shit. Well, you know, HTML is made for people like you, actually. I feel pandered now. It's not just humbling, but pandering next level.
00:24:14
Speaker
Can you pander to me by explaining? It's very exactly for people like you. I mean, you're quite a salesman, I've got to say, you know. I mean, it actually says on the website, like HTML and then Ray, this is for Ray on the website, so, you know.
00:24:30
Speaker
Okay, I'm open to it. I'm open to this. So do tell me more. So the way I think of HTML X is it's basically like, so again, say you got these two polar opposite approaches. On one end, you got the traditional server rendered multi page stuff, not really using much JavaScript, right? On the other polar extreme, you've got
00:24:55
Speaker
you know, these SPAs and React and maybe ClosureScript and all this complex logic on the front end, right? And so, HTMLX is basically like, like, how can, like, if we just stick with that sort of a server-side render or server-side rendered model of programming and just try to extend that a little bit, like, how far can we get? And so, like, so in a nutshell, like, basically the idea of HTMLX is that,
00:25:23
Speaker
Instead of like, so, so with normal server side rendered stuff, you can do like a form post, right? If you want to change some data, or you can click on a link and then it takes you to a new page. And either way, like the entire page is going to be reloaded. And so the whole point of HTML is just, what if you could just have a form where you post the form and then just a section of that page is updated. So for example, say if you're doing something like Twitter.
00:25:52
Speaker
or any social media app, you got a post, and you have a little Like button. And you want to click on the Like button and have it changed to a colored thumbs up or whatever. So you've liked the post, and it's a toggle button. So with the traditional approach, you click on the button. It does a form post. The entire page reloads. So if they're a state, if you were scrolled somewhere, that might be lost.
00:26:17
Speaker
If you were typing a comment into somewhere, that might be gone. Whereas with HTMLX, it's more like, you got the Like button, you click the Like button, and then just that little section of the HTML gets replaced. So it's like Ajax, not a page level in the text, but a kind of component level Ajax. Yeah. Yeah. And in fact, like, HTMLX, it's basically a declarative DSL for Ajax. Oh, OK. OK.
00:26:49
Speaker
But it's, I think it's really taking us back. That's what I'm saying. The tagline is basically for Ray. But it's, it's, it's interesting because, you know, this is something that there, I mean, I'm trying to build some front-end stuff and I got like getting annoyed with all this complexity of
00:27:14
Speaker
the whole front end, basically you need to build two applications now to build one application. That's what I noticed. And then now you have this fucking distributed system problem and all that crap. And now I have like a million problems now. And I wanted to go back because, you know,
00:27:29
Speaker
I started with Perl templates a long time ago. And the CGI and all that crap went in as Ray knows as well. And so then the small dynamic DHTML stuff showed up. Like you could use that small JavaScript request and XML HTTP request that the whole Ajax thing started. It used to be just XML going around thanks to Microsoft.
00:27:56
Speaker
And that was like you were able to manipulate smaller parts by just replacing inner HTML, basically, for any of the divs or any of the tags. And then, yeah, this cottage industry that became like a fucking multinational thing of JavaScript frameworks and all that thing showed up. And I had the same issue as you were saying.
00:28:20
Speaker
I mean, I do like that in the closure script world with reframe and reagent and all the ecosystem, it's trying to give us a better design, better patterns and better libraries for the JavaScript ecosystem. But every time you want to wear a little bit off of that one, it's fucking pain in the ass to build these kind of systems. And as you say, most of the things are like, I just need some level of interactivity in the page. It doesn't need to be the whole thing needs to look like a desktop application.
00:28:49
Speaker
No, I don't need that. It doesn't make any sense. So HTML has been like a really nice, nice, nice replacement. I think for me, it felt like I don't need to write JavaScript because someone else did already and then made it work. So there was the best. Yeah.
00:29:08
Speaker
Yeah, and I feel like that's kind of the sweet spot of HTML. Because I absolutely like HTML is not a replacement for SPS, right? Like, like, there's plenty of apps where like, that is what you want, right? But yeah, I think, like the sweet spot of HTML is like, where you're building something that's, that really isn't necessarily that complex.
00:29:33
Speaker
And if you just could add a little bit of interactivity, you'd be totally fine. And so HTMLX, it just increases the threshold for where it makes sense to switch to an SPA.
Biff's Simplified Components and Database Choices
00:29:47
Speaker
That's the way I see it. But in the case of BIFF, for example, is it HTMLX is just used as is? You can also use Hyperscript, what is it called, Hyperscript? Yeah, Hyperscript, yeah. Can you use that one as well? Or is it something that you want
00:30:03
Speaker
have only HDMI kind of interactions? No, no, you can use Hyperscript. And in fact, that's sort of recommended. I mean, it's not like extremely recommended, but I use it myself. Yeah, yeah, yeah. They're complementary. Yeah. But yeah, HDMI is it's just it's used as and it's not like
00:30:23
Speaker
It's not baked into BIFF very deeply. I guess just to give a little bit of background. So BIFF has sort of two parts. There's a bunch of library code, and then there is a bunch of template code. And so the difference being like when you make a new BIFF project, one, you like it
00:30:44
Speaker
copies a bunch of source files into your new project, which is similar to what Luminous does. But then it also adds a dependency to the BIF library code, which has some additional stuff. So anyway, with HTMLX, there's nothing in the BIF library code that does anything with HTMLX.
00:31:10
Speaker
Like all Biff does is it just adds the HTML dependency to your HTML template. And then there's like some, like there's like an example starter app that has a few CRUD forms and it shows you how you can update a form with HTML. But like if you didn't want to use it, then like you just take it out and it's never done. So just so I understand then, because it's like I said, it's new to me. So if you, if you're used to using like hiccup and stuff like that, how does HTML compare?
00:31:40
Speaker
Oh, it's very complimentary with Hiccup. And actually, I think Closure is, for that reason, probably one of the better languages to use with HMX. Anyway, anyway, so to answer your question, so Hiccup handles the rendering. And this is actually kind of a misconception that I think some people
00:32:02
Speaker
have when they're first looking at HTMX is they're thinking HTMX does the rendering, like something like React might, but it doesn't, like all HTMX does is the Ajax. So like all of the rendering happens on the backend. And so you'll use Hiccup and you'll have, and so the way it works with HTMX is like, I mean, you'll have like your regular
00:32:27
Speaker
endpoints that are rendering an entire full page. But then you'll also have a handful of smaller endpoints that are just rendering snippets of HTML with Hiccup. And so that works really well with Closure, because if you want to make a reusable bit of HTML, it's just a plain function with Hiccup, which is super nice. You don't have to make a separate template or anything.
00:32:54
Speaker
So you'll have these little endpoints, and then HTML will just be calling these different endpoints that are returning hiccup. Does that make sense? Yeah, yeah. So the HTML is just a little thing you plop in to say this bit of hiccup should essentially have a little gap filled in by the HTML code.
00:33:18
Speaker
Um, so yeah, so like You use htmx by putting these like special attributes on your hx dash something. Yeah, yeah, hx, x dash like post or whatever So like so going back to the like button example Um, so if you have this like button And and say it's a regular Form so you make a form in hiccup. Yeah. Yeah. Yeah, so you make form in hiccup
00:33:43
Speaker
And so normally you'd have like, you know, action is, you know, the end point of the post end point thing and method is post, right? With HTMX, you will instead use like a special HX dash post attribute, and then you say like the URL of the endpoint that you want to hit. And so then what that does is when you submit the form,
00:34:07
Speaker
it will hit that endpoint and do the post request. And then it'll get the response of that endpoint. But then instead of using that response for the entire page, it'll just replace the like button with that post request. OK. That's pretty magical. Yeah, nice. Yeah. I think I was very impressed. I mean, I wasn't using with Closure yet, because there's something that I want to try with Biff. But I'm still not.
00:34:36
Speaker
uh using xtdb anywhere so that's what that is stopping me from using using bib right now because i'm i'm using uh rust with hdms which is you know super nice to deal with and with the mini ginger templating and all that stuff so that's uh that's an interesting experience compared to closure when i need to compile the sheet and then see the see the output all the time i guess it's fast enough but it's okay but but that that brings me the next question like the the um so
00:35:06
Speaker
component-wise, so there is HTMX, which is used as the thing, and I know you use the Tailwind as the default CSS thingy. What else does, in terms of the web framework, framework key thing, what else does it provide? Like is there a router, is there a security thingy, or is it, you know, all those components, and how do you build that one, or how do you use it before? Yeah, yeah, so there's a bunch of random crap in there.
00:35:36
Speaker
So, so yeah, there's a router. So you mean there is a multi multi CD and distributed region, built in clientless serverless is already been baked in and carefully principled selected curation of components from which that's actually exactly. And I'm happy to provide enterprise part contracts.
00:36:04
Speaker
Okay, so there's the router it's using, and I don't know how to write it, I believe. Write it. Yes, sorry. Write it from Matos. So it's using that. Great library. Let's see, authentication.
00:36:23
Speaker
It's most authentication, but it's using passwordless, like email assignment links and signing codes. So you have two options. You can have it send you a link in the email or have it send you a six-digit code, which both have some pros and cons. Both of those are the result of me spending 20 hours poring over OWASP documentation and feeling like, OK, what are the actual risks there? Anyway, so that's authentication, routing,
00:36:51
Speaker
Yeah, we talked about the renderings. What do you do for the authentication? Do you have some links to a store somewhere or do you run a store or do you link to Auth0? No, so it's not using any
00:37:09
Speaker
like third party dependencies or like SAS dependencies or anything. So even the normal flow is like just like a magic link that Slack does, then even the login. OK. Yes, it's the same as that. Interesting. And the way it does it is just with JWTs. Yeah. So like when you create the project, it'll generate a signing key and put it in your config file. And so then Biff will use that to sign the JWTs.
00:37:36
Speaker
Okay, so so the user store is local then as well. Yeah, I mean, it's, it's stateless. There is no user store. Because it's just, you're just you're just signing jwts. Well, what are you authenticating? Well, you're you're, the way you're authenticating is you're assigning a token. So like, so you put in your email address, say like, by gmo.com.
00:38:03
Speaker
And so Biff will then create a token and sign up. No, we just do this docs today. I did get that one, yeah. Sorry, I'm going to write it at the exam point.
00:38:21
Speaker
Now he's going to get all this. Well, this is also for you. Scholar three, come back. The new streamer 9000 for you. Sorry. Okay. Yeah. Yeah. So, so token, the token contains the email address ray at example.com.
00:38:46
Speaker
And it is signed so that, you know, the secret signing key that Biff has on the back end is used to sign that key or that token. So then we take the token and we email it to you and say, check your email. So if you then click on the link and then that link includes the token. And so Biff knows, okay, you have this token that we signed. The only way you could have this token is if you have access to this email address. Yeah, fair enough. Yeah.
00:39:17
Speaker
But is it possible to plug in like a two-factor thing into this one? I mean, it's possible in the sense that Closure is Turing complete. Yeah. I have not built in anything as far as multi-factor authentication. And if you did need that, I would like
00:39:39
Speaker
if someone came to me today and said, oh, I need multi-factor authentication, I would say just use Auth0. Or maybe Firebase Auth. I don't know if they do multi-factor. Yeah. Yeah. Yeah. Fair enough. Yeah. I was kind of thinking like, oh, should I build up more authentication things? But I feel like for BIF, like the authentication stuff it has now, like it's simple enough, like it's good enough for
00:40:03
Speaker
sort of, you know, the solo developer use case that I'm primarily targeting. And if you really need something more complex, then I think it makes sense. Just use. Yeah, I think Auth0 is a fair way to use that one. Because these days, I think authentication is painful enough that with the SSOs and all that stuff. And it's better to just plug in Auth0 or Auth0 is one of these things than the one external. It's just a bit of a weird thing that you're, you know, kind of,
00:40:34
Speaker
giving away the most critical component of your system. And then it brings back the weird memories of the IDPs that all the systems used to build, like Oracle had used to have their own IDP and all that nonsense. So anyway, it's a different problem. I mean, surely what you should do is just have a first book sign in. That's the best way. I am joking, everybody. OK.
00:41:01
Speaker
Well, you know, you know, have raise email address, so please complain.
00:41:05
Speaker
Ray at example.com. I didn't get that one. Yeah. So, so you've got, you've got HTML, you've got authentication, but some, some, some value of that, uh, you know, uh, which I think, like you say, it's a, it's a definitely a nice start, you know? Also the database X2DB, which is another one of the main components.
00:41:32
Speaker
Yeah, so why why xtb why not, you know, MongoDB Why don't you want to shoot yourself in the cock? It's funny that it's fine. Yeah, I think it's I think that the jokes are now gonna live forever on MongoDB, although they changed Entire design and everything but now I mean why not click house? Why not, you know something else?
00:42:02
Speaker
Is there any reason? And how legable is this thing?
00:42:06
Speaker
Plugable? Oh, like, could you use a different database? Yeah. Yeah. Yeah. OK. So now that now that what you might call it, now that the atomic is free. The atomic. Yeah. Yeah. Yeah. What do you call it? This is a closure podcast. Like, what was it? There's something. There's something. Some database thing. They crawl.
00:42:32
Speaker
Okay, so kind of to that question, yeah, it's pluggable, like you can replace it. Because again, it's like BIFF provides some convenience layers on top of X2DB. But like, as far as
00:42:50
Speaker
Like other than that, the integration is just mainly in the template app again. So it's like when you make a new project and it's got some example code, like here's how you query something from the database, here's how you save something from the database. So like if you wanted to use Postgres or Clickhouse or whatever, or MongoDB, you can just go through the template app and just take all the calls to XCDB and just replace them.
00:43:13
Speaker
The thing I like about XTDB, which is a bit MongoDB-like, is that you can just take some either and just store it. Whereas with MongoDB, if you can do the same, but with the atomic, oh no, you've got to set your schema up front. You got the schema. I'll get into the first question now, which is why I like XTDB. Just so we're clear, XTDB is the world's best database.
00:43:41
Speaker
Okay. And, and that has nothing to do with the fact that juxtaposing totally unrelated. Just on the merits, X2DB is the best database in the world. I'm also working with jokes at the moment. And I think they're a great company. And that database is awesome. So yeah, that's jokes, jokes, jokes, jokes, jokes, jokes, jokes.
00:44:10
Speaker
I think, I think we should have like subliminal messaging, right? Every 10 seconds, someone says Jack's like irrelevant, like that is our X2DB or something. Just keep saying that one, you know? I feel that that closure function, Jox, it's disgrace. You can have sponsorship details or deals where it's like, you know, how many mentions of your brand. Yeah, exactly. Yeah. But is that, is that the reason like it is named like four character?
00:44:35
Speaker
you know, word because when we had like folks from Jackson, they're like, we wanted to pick something that is a four character thing. Pretty much all the projects that we do are four character stuff. Also, they're just recycling the last half of jokes.
00:44:49
Speaker
Oh, yeah, that's true. Yeah. Yeah, yeah, yeah. I mean, it's very sustainable. They're already using it. They've already got two lads. They've already got two lads now. Exactly. The CTO of Malcolm, he's made this website called Site. We should change it to XT, whatever. Yeah, XT something. Yeah, yeah. XT website. XTWS. Yeah. Come on, Mark. That's for free, OK?
00:45:19
Speaker
Yes. Okay. Okay. Okay. So original question, why is XGB? Other than the bags of money, why XGB? Other than the bags of money. Okay. So anyway, anyway, I started with Datomic, which is great. I used Datomic for like a year and a half, I think.
00:45:44
Speaker
and did it with like the peer client, whatever that's called for a while, and then did cloud ions, as I mentioned earlier. I eventually kind of came to the conclusion, like it felt like the atomic was more targeted towards
00:46:02
Speaker
I don't know if that's like enterprise use case, but certainly people who are larger than you. People with more money. Yeah, people who have money and more than one developer perhaps. And so just an example. Like big Brazilian banks or something like that. Yeah, I don't know. So just an example. So with the peer client, if you want to set it up,
00:46:30
Speaker
And hopefully, that's the same way I don't want to be spouting misinformation about Didhamic, because I haven't actually been on that scene in a while. But at least at the time, you got the transactor, and you have the peer process. So if you want to, say, load up a digital ocean thing and start deploying an app with a Didhamic peer thing, that's two separate JVM processes you need.
00:46:55
Speaker
And then there's a question of storage backend, which I don't remember. Yeah, you need to switch between. I mean, you need to pick Postgres or DynamoDB. Yeah, something like that. So again, so for the solo developer use case, like my use case, I could possibly just put them on the same machine. But I mean, you got two JVMs on one machine, which could be hairy with memory usage and things. Or you got to just have two different
00:47:25
Speaker
you know, dropout. Like, yeah, they might grow into they have a REST API client now. So you don't have that pure client anymore. But yeah, yeah. So, so yeah, so there might be better ways to do it. Anyway, that's it. And then also, there's the fact that it's like, there is the license fee, which is not effective anymore. But at the time, it's like, yeah, do I even like
00:47:51
Speaker
what I want to use a database. And then after a year, I can't use any updates and stuff. And so it just, it didn't feel like it was really,
00:47:59
Speaker
the best fit for my use case, if you know what I mean?
Scaling Biff and Future Roadmap
00:48:02
Speaker
Whereas XTDB, one of the really nice things about XTDB is that it all just fits in a single JVM process, right? So like if you want to, I mean, you need to choose the storage backend, right? But like, so say in development, you can use the like file system for the storage backend, and then you just got like, you got your app process, and you got the XTDB thing, that's just part of that process, you just start it up in the same thing. So a single JVM,
00:48:30
Speaker
And if you want to deploy it, one option is you can just keep using the file system backend and just do disk backups or whatever. Or you can use Postgres as a storage backend, which is great.
00:48:45
Speaker
Because again, you still got the one droplet with all of your Closure process stuff in it, and then just use one. And then one database. Yeah. And just, yeah, Postgres. Because everyone has a Postgres, like a managed Postgres thing you can plug into. So just from the deployment ops side, I found XTDB felt pretty nice to me. It fit pretty well with the whole solo developer thing. So that was big. Comparing it to, like,
00:49:13
Speaker
Postgres, I am a big fan of the data log queries. The implicit joins are super nice. Whereas SQL, anytime you want to do something somewhat interesting, all of a sudden you've got select from this inner join on this. And the queries just tend to get out of hand a little bit. Whereas with the data log stuff, it stays flatter, I find.
00:49:42
Speaker
So it's all like that. And then I'd say the third thing that I also liked a lot is what you mentioned, Ray, is the schema-lessness. So where it's like Postgres and atomic, they've got the schema based into the database. xt lets you just kind of do that on your own, which by the way, is like what part of what this adds to it.
00:50:05
Speaker
So BIFF lets you define schema with Mallee, or Mallee, that's how you say it. But with whatever that library is called, you can define your schema. And then BIFF will, when you're submitting documents to it, it'll check it against that schema. So I've appreciated that flexibility.
00:50:24
Speaker
Um, and, and then it's also nice because like, if you, like, you don't have to do migrations every time you want to like add a new attribute or something, it's just, you know, update your model schema and stuff. So, so it's, it's been overall, like, it's been ergonomic. It's easy to deploy. Um, it's free, which, you know, the atomic class is free of course now. Um, so I've been really happy with it. Yeah. This might be like a, you know, um,
00:50:53
Speaker
maybe an answerable question or maybe too fluffy, but is there any performance-related things that does better compared to piecing all these things together, or is it entirely dependent on the underlying components? Because web framework performance is always a weird thing to say. People say, oh, we can serve 200,000 Hello World requests in a nanosecond, as if we care. No one gives a shit.
00:51:22
Speaker
With that caveat in picture, is there something that you want to talk about performance about in the context of BIFF? Yeah. So as far as performance, I'd say certainly the largest factor is just the underlying components. And again, most of BIFF is just tying together other components that are already mature. So like XTDB or Jetty for the web server or rate it for the router.
00:51:49
Speaker
So those things are taken care of. Biff does add its own middleware stack, which may or may not be performant. But overall, especially for the solo developer,
00:52:05
Speaker
use case, it's totally fine. I would say to anyone in that use case, the performance of this is totally fine. But for the scalability part of it, I don't think there is any limitation. Given that it's primarily stateless, so it's much easier to just start multiple instances or something and then just slap, there was proxy in front of it.
00:52:28
Speaker
Yeah. And I'd say the main thing there would be just the characteristics of XTDB. So it's a single writer, but then you've got the immutable reads. So reading is very easy to scale because it's just horizontally scalable. OK. Yeah, I think for the case, if you go to that level,
00:52:52
Speaker
So if you if you start as a solo developer and then start using BIF and then you're wildly successful with your enterprise tooling, you know, selling to all these people. But is there like a transition path that you think you would recommend as the author of BIF or is there something? Well, you know, maybe some consulting fee. I'll scale it up for you. Yeah. So I mean, I
00:53:24
Speaker
So I've designed BIFF so that you can take it apart. That is one of the explicit design goals, is that it's not meant to be just super glued together and you don't change anything. The design is so that any part of BIFF, you can swap it out. So again, like I mentioned, all of the components BIFF is built on are quite mature.
00:53:50
Speaker
There aren't any parts of Biff that I feel like, oh, this is something you're definitely going to watch out for or need to watch out for. Well, I guess one thing I might say is if you're scaling up
00:54:04
Speaker
Like you'll get to a point where, I mean, of course you'll, the first thing might be adding multiple web servers, right? So instead of like a single node, you're going to want to have multiple in life for all that answer in front of them. And after that, probably the next thing where you would transition is adding some sort of job queue. So instead of just like doing everything on the same machine, right?
00:54:28
Speaker
Like you want to be able to, you know, have a separate worker node and have your web service put stuff onto it. And that is something like if I was doing that today, I would probably just add in Redis maybe and use whatever library people are using for Redis because XTDB is, um,
00:54:48
Speaker
Like, you could build some job queue stuff on top of it, but it's not really ideal for that. Yeah. But I think XGB, you know, to use our sponsors' time here, you know, I think it is quite scalable. They're not sponsors, but yeah.
00:55:10
Speaker
I was going to say what you might call it, it's quite a scalable solution because you can have Kafka in front of it and all this kind of stuff. I think there are architectures where it does grow. Yeah, I think that the database side, I think, because the scalability is multi-pronged. You want to scale the website of it. And luckily, you don't need to worry about there is no separate front end that you need to scale anything.
00:55:38
Speaker
because you're using, you know, hdmx plus bif, and once you start scaling the web nodes, you're essentially scaling the entire web app by itself. I think, to be honest though, Vijay, I mean, I think what Bif is in for is like relatively small scale web apps. And if you're going to design like a massively super scaled application, you've probably got other problems, you know? Yeah, you're already into like a team and you've got
00:56:05
Speaker
Maybe you're going for event-driven models and shit like this. No, I mean, given that, I think, you know, the success rate of startups and when you start a small beef app and then you want to scale up and you're one of those unicorns now and then. So the way I think about it is that, like, so one biff is meant to be ideal for, you know, hobbyists, right?
00:56:32
Speaker
it is also meant to be good for, you know, quote unquote serious apps like startups, which is, I mean, which is my use case. Like I've been a full time startup founder for the past four and a half years. So, so like that is, in fact, I mean, that's the first case. Cause like the primary target user of Biff is myself. And so I'll just find the decisions are, you know, what do I want? And then as a secondary thing, you know, what would maybe a hobbyist spot or something. So anyway, so like the idea I have with Biff is,
00:57:00
Speaker
I want it to be good enough for that use case, like say you're a solo founder and you're working out full time. I want Biff to be enough that you can just focus on iterating towards product market fit.
00:57:13
Speaker
And once you hit the product market fit, then, you know, do whatever you need to do. Maybe like rip it out, use full-crow or whatever you need to do, right? But until you get to that point, Biff, should ideally be enough that you don't need to worry about too much of the like.
00:57:30
Speaker
So it gives the initial velocity you need to deliver something that you can test the idea and then make sure that your product is actually doing something. There's a minimum viable product type stack. Yeah, that's how I would say it.
00:57:46
Speaker
My intent is that Biff can also still grow with your app. It's not like you hit product market fit, and now Biff just falls apart. I mean, hopefully this is not like that, right? Let's switch to Ruby on Rails now. Yeah, yeah, yeah. But the idea is once you get to there, though,
00:58:08
Speaker
Biff's not doing anything for you necessarily. It's just hopefully not getting in your way. So I can help you get to there, and then it gets out of the way.
00:58:17
Speaker
But probably on a single node with X2DB in the back, you can probably support hundreds of concurrent users. So you'd have to be quite successful to get more than a few hundred concurrent users. It's like this joke about web scale and shit. Yeah, exactly.
00:58:42
Speaker
And that's absolutely what I did like just scale vertically first and then yeah, I think that's that's way way cheaper and faster to scale vertically than horizontally anyway bigger problems once you start adding more nodes. I also like the fact that I'm looking at the web page here and you've got like ways to deploy
00:59:01
Speaker
Because this is the thing that, you know, I like the fact that you're pushing out to a Ubuntu VPS. You know, it's not, oh, it's just some terraform to deploy to Amazon. Fuck those guys. Yeah, yeah, yeah. Deploying to a nice, like, you know, line order something, you know, you know, this started with terraform, actually, I used to answer. It's one of the parts that I took out and realized, Oh, yeah, actually, bash script is good.
00:59:29
Speaker
Yeah, I mean, presumably you're putting it to a basket right now, but you know, not actually.
00:59:38
Speaker
I use Babashka in different parts of Bif, though. It does use Babashka, just not for this or provisioning. But the whole development experience or the project creation and everything is using Babashka, right? Yes. So you're keeping everyone happy, you know? Yeah.
00:59:59
Speaker
All you need to do is just add them, you know, CDN stuff and multi-region thing and it is web scale. Exactly. So just to wrap up the discussion and what is the next thing that you have? What is the, do you have any kind of a roadmap or is it like that Buster Keaton thing? Like you're just putting rails as the chain goes. Yeah. So I, yeah, I do have a bit of a roadmap.
01:00:27
Speaker
As far as the code, it's actually in a pretty mature state. I wouldn't say that BIF will never change, but I don't have any huge code changes on my mind, which I consider to be a great thing, actually. It's been fairly stable for a while. I guess one thing on the horizon would be XTDB2.
01:00:55
Speaker
Um, so I'm hoping that I haven't actually had a chance to play with that yet, but I'm, I'm planning to start experimenting with X2 DB two and a little bit. And so then all that would, that'll involve some, some like additional things with it. Like the current system, like I mentioned with this schema enforcement, that'll look a little bit different. Cause now X2 DB two has this concept of.
01:01:21
Speaker
of specific tables or document collections and things, which is nice. And that'll actually be pretty helpful for both. So anyway, there'll be some stuff to look out for that. Other than that, I'm interested in staying up to date on what's out there, what other frameworks are doing and things. So I can keep an eye out in case there is something that, oh, this could be interesting to put into both. But yeah.
01:01:49
Speaker
As far as stuff I am planning to do, basically, there are like two things that are on my mind. One is more documentation. And all of the core documentation is complete, which is also, by the way, one of the big advantages of BIFF. I think it's got reference docs. It's all the doc strings you get. And it's got tutorial. As you mentioned, Closure is together, by the way, which has given me a grant a couple of times.
01:02:19
Speaker
including for the tutorial that was funded by them. So donate to Closures Together. So that's all in place. I would like to write more documentation that helps people learn about how Biff works under the hood. So an idea of how to write a series of posts that
01:02:47
Speaker
There's two ways I could do it. So one way is the posts, they have you build a web app from scratch without using Biff, and they just show you how to do it with the underlying libraries, but doing it in the same approach and architecture as Biff does it. So by the time you get to the end of the set of tutorials, it's like, oh, you've actually kind of rewritten Biff yourself. Congratulations, you've wasted your time.
Biff's Workflow and Episode Conclusion
01:03:10
Speaker
Now go back and use Biff. Exactly, exactly.
01:03:14
Speaker
So then at least then you know how it works under the head and you know if you need to change something like you know exactly how to do it. So that would be one thing. Another approach could be instead of doing bottom up, I just do top down and just say like, okay, so authentication is something that fights and just write some posts that talk in detail, like how does authentication work? And if you wanted to change something, like how would you do it? So something like that's on the radar. The other thing is I'm interested in
01:03:45
Speaker
more like real world example apps for Biff. So like one, I've had an app released for about a year plus called PlataPub, which is a publishing platform, kind of like WordPress. It lets you publish a static site and then you can have a newsletter as part of it. It's very half baked. It's been half baked ever since I released it. I use it for my, like the Biff website, by the way, is published with PlataPub.
01:04:16
Speaker
And so anyway, and that's open source written in Biff. I'd like to fully bake that and turn that into a project that people can get into and learn from and be like, oh, here's like a real world Biff app I can study and contribute. Like if people want to contribute to an open source project, have issues and stuff like that and have it be a community driven thing.
01:04:41
Speaker
Yeah, nice. One thing I noticed, actually, and it's sort of something that I'm like, big proponent of is you say development prod. Yes. Deploy in seconds by hot swapping new code automatically. And if you save a file, I'm not the power of lisp. So tell us about that, because you know, I love the idea. So what's what's your, it's like the PHP story, you know, so like,
01:05:06
Speaker
This is where we've got to get back to. You just YOLO it and then move on. Yeah, so that is one of my favorite parts of BIFF. And actually, a lot of the way I've structured BIFF has been in the service of that goal. There's lots of late binding stuff just to make sure, as much as possible, you don't have to restart the whole app to update your code.
01:05:36
Speaker
But anyway, so that came about because let's see, it was like a year and a half, almost two years ago. I was wanting a lighter weight approach to just kind of developing my own.
01:05:52
Speaker
like hobby projects and stuff, because I'm working full time on my startup stuff, right? But I still have this never-ending idea of like, oh, it'd be nice if I just had this tiny little app to save my bookmarks or stuff, whatever. So I wanted something that would make it easier for me to just spend maybe an hour a week and just be able to drop into a project and add some code and do stuff and get out of it.
01:06:22
Speaker
and be able to be productive and not have a lot of context switching or overhead time. And so I started having this idea of, OK, what if I did all my development on the REPL? Because I had started doing a lot of my development on the startup with just connecting to the REPL and evaluating it in the editor, and then after the fact pushing a commit to get in case the app had started or something. And so I had this idea of, what if the entire development workflow was
01:06:52
Speaker
Like, what if that was a first-class citizen, in a sense, right? And so then I started having this idea. I was like, OK, I could make it so, like, say whenever you save a file, and this is what Biff does. So whenever you save a file, when you have the development prod thing running, it will rsync all of your files onto the VPS. And then it will evaluate them.
01:07:20
Speaker
And like I mentioned, all of the components in BIF are structured with late binding in a way so that for the vast majority of the code, a normal, simple evaluation is enough to update it. You don't have to take down the system and then evaluate and then bring it back up or restart the entire process. It's just... It has a watcher. It has some sort of watcher that's running all the time.
01:07:47
Speaker
Kind of, yeah, like mainly in dev, it's got the file system watcher. So like with the development prod thing, the file system watcher is watching for file system changes. And so that'll run Rsync. But then once Rsync finishes, the local process on your machine will then issue a command over SSH to the production process, which will then have it evaluate the files on the server.
01:08:13
Speaker
Right. Okay. And does it use any of these like component systems or is it just, is it written so that it will just like be, let's say amenable to just evaluation on the fly? Yeah. I mean, I mean, it's, um, so the component system, it's using kind of a homegrown thing. Um, so not like component or integrant or map. Um, it's a very lightweight, like conceptually it's structured.
01:08:42
Speaker
kind of like component where you've got a system map and that map gets passed between these different components. I guess one thing, though, is they're kind of, at least like I've seen with integrant, there are a couple of different approaches that people sometimes use. One is there's one approach where you have lots and lots of little components, like granular components, you might say. And so then each little component can say, I just need these two config
01:09:12
Speaker
items and just say exactly what you need. And BIF doesn't quite take that approach. BIF's components, it's got a handful, maybe eight or nine, but they're only used for the major actual stateful things for the most part, like the web server or the database, things like that. As far as the more granular stuff, BIF has a concept of plugins. And plugins are not stateful or anything.
01:09:42
Speaker
So, and plugins are what contain your application code. So I can biff, like your application code is in plugins and your, you know, quote unquote framework code is inside of these components. And so like if you were to update some of the framework code, then you would have to restart the system and you'd have some downtime at least a few seconds, not necessarily a lot. But as far as like all of your application code,
01:10:08
Speaker
that's in the plugins, like all of that can be updated just over the repo without, you know, just a normal evaluation. That's interesting. So how is the upgrade story then, if I want to move from one version of Biff to the next one, is it just replacing the framework files and then the interface between this plugin system and framework is stable enough?
01:10:36
Speaker
Yeah, so whenever I do a release for BIF, so going back, I mentioned, again, two parts of BIF. There's the library code and then the template bits that actually get copy pasted into your project. So as far as the library code is concerned, when that's updated, all you do is you just bump your BIF version in depth.edm.
01:10:59
Speaker
So that's normal. For the template stuff, like if I change something that's in the template files that normally is copied and pasted into new projects, then in the release announcement, I write up steps and say, okay, like if you want to upgrade, then you need to do this and this and this. And a lot of times it's optional. It's like, like, you don't, like if you want, you can, you don't have to update the template stuff, but if you want, you know, you can do this.
01:11:27
Speaker
So I'm very meticulous about the documentation for the releases. So you know what bits need to change and how the play process is more there. OK. Yeah. Nice. But that re-evaluation thing sounds really interesting, Jacob. Yeah. I'm eager to look into it because I think this idea of everything being constantly being re-evaluated is super interesting.
01:11:56
Speaker
You just need to change the website to bif for Ray, and then he's sold. And that's it. I've sold all this stuff so far. It's really good. Yeah. So I think he's already a customer. And I think I have one question to decide whether it's still something that I want to try or not. So what editor do you use? Is it Emacs or some other shit? So that is going to be the make or break thing for me. That's true.
01:12:21
Speaker
The best one. Fair enough. Close enough. With Biff's REPL thing, or the evaluation stuff, one of the cool things about it is you don't actually even strictly have to have an N REPL plugin for your editor.
01:12:46
Speaker
Um, because it's, it's doing the file watching. So like, yeah, like if you just save all the files and everything will be up to date, you don't have to worry about like, or I have to evaluate this file on my buffer. Um, so I absolutely like, like I, it's still nice to have the, the NREPO things. I just write little bits of code and stuff, but you can, especially if you are like.
01:13:09
Speaker
still get it like learning closure and then setting up a development thing like like it's you could get started with Biff and be very productive with it and never know how to evaluate something from your editor.
01:13:22
Speaker
Oh, nice. I think that's that's something really like, you know, more and more. I think before when we started recording, we were talking about the beginner experience. And this is something that providing like opinionated, quote unquote, framework or something that people can get to the place where
01:13:40
Speaker
Look, I want to make a whatever the fucking to do list or something instead of fighting through. Oh, let me set up the editor. Let me do something else. Let me figure out the build file. Let me figure out what is this thing. And I think that that that initial dopamine hit is so important to, you know,
01:13:57
Speaker
like hooking people up to closure and I think Biff does really really good job and I really love you know your focus on documentation and your focus on you know making it smooth experience to build something and also you're very clear on what is the target audience and most of the people who are coming to build these kind of things are individual developers right they're not like
01:14:20
Speaker
Oh, we are like a 200,000 people company. We need to decide a new framework. So I think it's an excellent project and I've been very impressed so far with the way that you're releasing it and then maintaining it and your focus on that one. And my love towards like HTML stuff as well and that aligns with it. And yeah, I'll forgive that one.
01:14:48
Speaker
What do you want to podcast about three or four years ago talking about it when it was a Firebase thing with Biff? If it wasn't for Firebase, this all sounds really cool. So it's kind of like, I think your pivot to the Firebase has really sold me on it for sure. Now, just to be clear, and this might have been unclear before,
01:15:13
Speaker
BIFF was never built on top of fibers, per se, but it was a replacement for fibers. Ah, OK. I thought you used it for the authentication or something. Oh, I don't remember. I might have, actually. I forgot about that. Yeah, yeah. But that's in the history, so. Yeah, I was more than six months ago. I've totally forgotten about it. Yeah, fine. Yeah.
01:15:41
Speaker
No, but it sounds really great. Like Vijay says, this idea of getting an application built in 15 minutes, the sort of Ruby on Rails type thing for closure, we've been missing it. So it's great to get some full stack thing out there pretty quick. And like you say, you've still got the potential to change a lot of things as you go along. So it's quite idiomatic in that sense.
01:16:11
Speaker
OK, so I think that's it from us for this episode. And thanks, Jacob, for taking the time and explaining everything. And hopefully there'll be more beefy stuff in the future for you. And we'll put all the links for the things in the show notes anyway. And for people. And the Platypup thing, is it also open source? Yeah. Yeah, I can. OK. Yeah.
01:16:39
Speaker
No, no, it's okay. I mean, we'll find it on them. Yeah. And then I'll publish that one as well. Cool. And yeah, that's it from us. And hopefully everyone is doing fine. And we'll be back with another episode soon. Thanks a lot.
01:17:01
Speaker
Thank you for listening to this episode of DeafN and the awesome vegetarian music on the track is Melon Hamburger by Pizzeri and the show's audio is mixed by Wouter Dullert. I'm pretty sure I butchered his name. Maybe you should insert your own name here, Dullert.
01:17:20
Speaker
If you'd like to support us, please do check out our Patreon page and you can show your appreciation to all the hard work or the lack of hard work that we're doing. And you can also catch up with either Ray with me for some unexplainable reason you want to interact with us, then do check us out on Slack, Closureion Slack or Closureverse or on Zulep or just at us at Deafened Podcast on Twitter.
01:17:48
Speaker
Enjoy your day and see you in the next episode.
01:18:15
Speaker
you