John Leider is the CEO at Vuetify LLC. He joins the show to talk about Vuetify 3. He begins by sharing the recent updates in Vuetify. He talks about Vuetify's latest version, its new & exciting features, how it differs from the past versions, and many more!

Steve (00:01.254)

Hello everybody, welcome back to another thrilling episode of Views on View. I am Steve Edwards, the host with the face for radio and the voice for being a mine, but I'm still your host. With me, I have my co-panelist, Mr. Cody Bontacue. How you doing, Cody?

 

Cody Bontecou (00:17.005)

Hey, what's up, what's up everybody? Happy to be here.

 

Steve (00:20.366)

Yeah, yeah, coming from the frigid temps of the big island of Hawaii, we always feel for him.

 

And with us today, we have a special returning guest, Mr. John Leader, he of UTIFI, JS, not GS, JS fame. How you doing, John?

 

John Leider (00:38.794)

I'm doing well. Thank you for inviting me on.

 

Steve (00:41.406)

Good, I always like to talk to you about Vutify and other things, Vutify being a very large part of the Vue ecosystem. Now, refresh my memory where you're coming from, John, where you're at located.

 

John Leider (00:55.121)

I'm in Texas.

 

Steve (00:56.71)

Texas, all right, Texas is a big state, what part?

 

John Leider (00:59.074)

Keller, Texas. So it's like, it's by Fort Worth.

 

Steve (01:01.33)

I don't know, Keller, where's Keller in Relate to a Big City?

 

Oh, DFW, Dallas-Fort Worth area.

 

John Leider (01:08.034)

Well DFW is like a very large area but yeah so Fort Worth is more of the west of Dallas and I'm right outside that city line.

 

Steve (01:11.047)

Yeah, it's huge.

 

Steve (01:17.339)

Right.

 

Yeah, I have a coworker in Fort Worth right now. So you guys keep it nice and keeping cool this summer.

 

John Leider (01:23.639)

Okay.

 

John Leider (01:27.026)

No, it's terrible over here. It's like 110, 111 every day.

 

Cody Bontecou (01:29.125)

Hehehe

 

Steve (01:29.339)

Yeah, that's pretty.

 

Yeah, up here in the northwest corner, we were getting some temps like that for a while. Last week, it was pretty crazy. I blew out another capacitor on my air conditioning unit, had to change it out. But cool. Now, one thing I've noticed, and this is of great importance for some of us more than other, and you'll notice this on the video, is compared to last time, John has significantly less hair. He's gone the smoother is better route.

 

I always say that God made so many perfect heads and the rest he covered with hair. So John has joined the ranks of perfect heads and we're very appreciative of that. Thank you.

 

Cody Bontecou (02:07.71)

Yeah.

 

John Leider (02:12.75)

Sure, sure.

 

Cody Bontecou (02:14.033)

Yeah.

 

Steve (02:19.202)

And for those of you that might have forgotten that as our studio audience, I always forget to introduce them, but they're still there. Uh, tickets are a hundred dollars a seat. Uh, email me directly. You can get me at one or nine five on Twitter and, uh, I take credit cards and cash as well. So, uh, the reason we are here as has been mentioned previously is to talk about view to five JS and, uh, the last time that John was here was November of 2022.

 

John Leider (02:34.094)

Thanks for watching!

 

Steve (02:47.546)

And at that time, Vutify 3 was in the works but was not yet completed. There were still some components that needed to be worked on data tables as one that comes to mind for me at that time. So we're gonna first of all catch up what's been going on in the Vutify JS world since then.

 

John Leider (02:58.172)

Mm-hmm.

 

John Leider (03:08.203)

Well, quite a bit actually. So November was when we released, actually released version 3, but we were still lacking quite a few components to reach feature parity. Shortly after we talked.

 

December, I think it was, or beginning of January, we released a new effort called Labs, which is a way for us to put components that are not 100% feature parity with version two and or new components that we're just wanting to get some feedback on, putting it in the ecosystem so people can utilize it, but also recognizing the fact that it's not completely done. Big reason for this was we had a few components, especially data tables.

 

that were mostly complete, but we didn't want to release it in a state where, hey, there's XYZ functionality that hasn't been ported over yet, but we're claiming this is finally released. So that was one of the big ones, and throughout the year we've introduced more components, excuse me, into the lab's effort, most of them ports from version two with a couple new additions. We've been...

 

Heavy at work planning for some, we have another release in November, which will be version three, four, and it'll be our largest release since version three. And we've just been kind of working up towards that, working on new functionality, lots of documentation improvements, try to help the user experience, help it disseminate information a lot better in Vutify. We have a lot of...

 

documentation holes that we've been trying to fill all year. And yeah, we've just been doing a lot of porting, a lot of upgrading processes over and trying to expand how we get that information out to users and also ourselves trying to come up with some new stuff to, to work on it, add to the framework. So.

 

John Leider (05:09.974)

I'd say that pretty much covers it. It's been a blur, honestly, over the past year. So it's good to finally be, we feel that this release, version 3.4, is gonna pretty much be what we wanted to have at version 3 launch, as far as all the components and availability. We won't be 100% future parity by then, but majority of the components that were used will be.

 

So there's a lot of odds and ends that won't be complete by then. But we'll eventually get there and then start bringing out some new stuff. But yeah, that's what we've been hard at work at.

 

John Leider (05:53.59)

So, but actually the release is called Blackguard. So we've been trying to do name releases for, to kind of assign a name to like this feature set that's coming and we've been working on some social media and art stuff to try to disseminate it out to people in kind of a cool way, something new.

 

since open source is typically not considered like a super cool fun job. So trying to even coding in general. So trying to add some interesting visual elements to it and kind of thematics to the different releases. And, um, so yeah, that's another thing we've also been working on.

 

Steve (06:34.79)

So I'm sitting here wondering why John didn't answer my question and realized that I had the mute button on so that might explain a slight gap there. So when you say feature parity, were you parity with version two? Okay. All right. So you're just trying to get up to where version two was. So going back, I'm remembering the data tables and the reason it was sort of.

 

John Leider (06:39.545)

Yeah

 

Cody Bontecou (06:39.825)

I'm gonna go.

 

John Leider (06:47.426)

That's correct.

 

Steve (07:01.198)

apropos for me, or relevant to me, is because I was starting up a new project of you, Laravel inertia project at the time. And so I was looking at data tables because it's very heavily, it's data management tools, whatever it really is. So now you had mentioned having the labs and so your beautified labs is where you have the stuff that wasn't finished but you still wanted people to play with sort of a beta playground or alpha playground as whatever level you want to use. Is that still there?

 

John Leider (07:10.978)

Mm-hmm.

 

John Leider (07:15.213)

Yeah.

 

John Leider (07:31.302)

Yes, so it was the first component in Labs, and since it's a new piece of functionality, we have to release it with a minor release. And our next big minor, there was a, we had a 3.3 earlier this year that came out a little sooner than expected because of Vue 3.3, had it happened, and there were some TypeScript improvements that we wanted to implement. But...

 

other than...

 

John Leider (08:03.346)

Sorry. Other than that, we've been trying to have all of the, we have to move all the new stuff to a minor release, which in this case is version three, four. We try to do once every three months. Some components have been in there for longer. All the pages, they let you know when a component was introduced, because in labs we can introduce a component whenever, which allows us to kind of skate semantic versioning, to allow people to use stuff.

 

John Leider (08:31.451)

But yeah, there's obviously a certain level of risk associated with utilizing stuff.

 

Maybe we should end up doing something like stages, kind of like when Xmascript is approving things, there's like stage two, stage three, stage four. So it's like, if something hits stage three, you know there's not gonna be any changes because that in stage four. And that's pretty much what the data table is. It's in a great spot, but we can't release it without iterating a minor version. And we have a lot of things that we wanna bring into the next minor version. So it's one of those where we're just gonna continue to iterate on it and especially improve on the documentation, which is something that...

 

It's probably, it's better than it was before, but there's so much information with, we have three different data tables now that each have their different focuses. Main reason why is that we found out there was a lot of properties that existed on data table that were antithetical to each other. So there's no reason for you to need to do X, Y, or Z if you're receiving all of your data from a server.

 

as opposed to where you're wanting to display, you know, a large amount of items with virtual scrolling or if you just want to have, you know, a regular boilerplate data table. And they have some different, they're mostly the same. They have some special configuration options that are unique to them that is just designed to allow you to use.

 

more I guess scoped or refined component for what you're doing. So you're kind of instead of just everything goes through a data table. You have the kind of the feel like okay if I'm pulling it from the server I have these options or I could use you know the default.

 

Steve (10:17.19)

So you mentioned, so I'm looking at the docs here online. So there's three different types. How do you differentiate between the types? Is it just a prop or a whole different component that you import? Okay.

 

John Leider (10:25.474)

Sure. Oh no, there are an actual different component name. So if you make sure, I don't know how long it's been since you've been at the docs but that it's updated. But if you go to the, there's a labs section on there and there it says, data tables and you can expand it out.

 

And we actually have multiple pages associated with it because there's different concepts that we want to introduce the user to and how we explain it to them. But whenever you go onto that page, you'll see at the top, there's like a little installation thing that'll tell you how to install it. But then you'll see below that it gives you kind of an overview of the three tables and kind of how they differentiate.

 

Steve (11:08.51)

Okay, so the different types are in the labs, but in the release stuff, you still have a, is it just regular tables then? You're still working on the data tables in the labs? Okay.

 

Cody Bontecou (11:09.365)

Yeah.

 

John Leider (11:19.066)

No, I mean, data table is still being worked on, but we have a regular table that is a component that exists. Yeah. No, it's just a replacement for the native tables, but

 

Steve (11:23.822)

Right. Right, it's just not all the data table stuff. OK, gotcha.

 

Steve (11:31.586)

Right, okay, so you got virtual tables and server side tables, which is what I would use, could use. Right on. So, just as a little bit of refresher, when you did version 3, this wasn't just sort of a cosmetic change, right? Of, hey, let's slap this stuff on top of our old bass. Didn't you pretty much rewrite everything in view 3 as, yeah, that was a pretty big change underneath. So you...

 

John Leider (11:55.467)

Yeah.

 

Steve (12:00.89)

Sort of had to do that, didn't it?

 

John Leider (12:03.542)

Well, view three introduced a lot of new concepts with the composition API. And there was an opportunity to port viewify to view three in kind of a compatibility mode earlier on, but I ended up making the decision based upon the manpower and the potential risk of.

 

Introduced because we were eventually always gonna have to rewrite. So we did explore not having to do that at first But you know, I felt that it was very risky to introduce and into it would almost be like beautified 2.5 and We were kind of by releasing it. We're kind of committing to supporting it in some way shape or form and I knew that

 

There's, I mean, not to say that I would even make the call to do that if we had the manpower, but not even close enough to be able to sustain something along those lines or provide a more stepped process to upgrading to view three, unfortunately. However, and I'm sure we'll talk about this later, is there's a lot of tooling that makes the process not very daunting.

 

But as far as the framework itself, if anyone had ever seen the code base of Vue Defy 2, it was built entirely with render functions, which became a little more common as time went on, but originally was used out of necessity because the Vue compiler...

 

templates didn't support functional components at the time, whenever it was being written over. So when we moved to version three, and we were gonna be doing a lot of rewriting, even though the ecosystem moved towards a...

 

John Leider (13:56.402)

nomenclature known as composables, which is instead of what view two was utilized, which was mix-ins where you kind of take this shared functionality and you, you have a component you define and say, Hey, it uses these particular mix-ins for its functionality. That's what we did in version two. Version three was basically like mix-ins were turned into pseudo pure functions. If you know what a pure function, if any, if, if you,

 

A pure function is something that has an explicit input and it has an expected output every single time. There's no scope of variables pulled in, right? So they're not complete pure functions, but the idea and the concept is typically the same, is that we are using a composable, we are passing it information and we're getting an expected return. That information that we pass it can be dynamic, which is what...

 

disqualifies it for being an actual pure function, but the concept is still the same. So we were able to kind of port that over relatively easy. But when it came to the templates, it was something that we were progressing with as a team, but it wasn't very easy for people to contribute to. One of the things that I think Beautify struggled with was its

 

accessibility towards being able to contribute because the way that it was done in order for us to support TypeScript properly, or at least to the degree that can be supported in Vue 2, we had to implement a lot of... Oh, sorry, losing my train of thought here. But...

 

Cody Bontecou (15:49.893)

Could I, could I just?

 

John Leider (15:50.142)

So, yeah, sorry. So, you know, when we made the decision to kind of push things off with Vutify 3 and not do a version 2, it was so that we could, again, not have to devote resources to maintaining and answering issues, which is already a very difficult thing to do. But also it allowed us to focus all of our resources that we did have on.

 

progressing with version three. So that was a call that we made. And whenever we decided to move up focusing on Vutify 3, we decided that render functions were not going to be an accessible way for users to help contribute to the framework. We needed something that was a little bit more accessible, but we didn't wanna go with explicit templates.

 

just regular templates because it didn't have the type safety and also the flexibility that we needed. So what ended up happening was we experimented with TSX, JSX and Kale, one of the core developers, got it set up to where we were able to write our templates using TypeScript and TSX. And it...

 

is obviously a full rewrite, but it allowed it to do in a way where, one thing that's difficult whenever you're working inside of view components is...

 

If you don't have a template, it's hard to kind of visualize where things are. When we have a template or some type of HTML, you kind of have a hierarchy or structure that you can follow to kind of understand where things are in the hierarchy. But with render functions, those render functions can be defined anywhere, and the ordering and how they are used is really only beneficial if you understand the code and you know where things are going to go after working with it for a while. So JSX TSX was an opportunity for us to kind of merge

 

John Leider (17:54.881)

the two philosophies together where we still have access to our type script type checking

 

And we are able to, instead of happening to convert our render functions directly to templates, we're able to kind of again in the middle convert them over to TSX, which feels a lot more natural as far as having a hierarchy to look at in the template. But it also has a lot of flexibility and helps us write pretty, you know, pretty good code. But

 

this did cause us to have to rewrite a lot of stuff and beautify itself as massive. So it was a very big undertaking.

 

John Leider (18:35.23)

Yeah, I'd say that the full rewrite now is definitely, I'm glad where we're at, because the framework is just solid and getting better every single day. But it definitely was a hard road, happened to be as late as we were to getting everything out. So it did come at a cost, unfortunately.

 

Cody Bontecou (19:00.241)

So I just want to mention. Go ahead.

 

Steve (19:00.306)

So now when you were working, when you were starting View 3, were you starting it when View 3 was still like in beta and hadn't been fully released, sort of shooting at a moving target type of thing where you'd write something and then View 3 would change underneath you and you'd have to adapt to that, or did you not really start working on it until View 3 was fairly solid?

 

John Leider (19:24.886)

Well, we started prototyping as soon as the Alpha was released. Correct. I might be wrong, but I think it was either, I think it was 2019 or 20, I think it was 2019, December, 2020, January that the Alpha was released. And we started experimenting almost immediately. There wasn't, I don't think too many issues with moving targets. I think that we had more that we had to work around and kind of.

 

navigate through the issues more than what Vue caused us.

 

The things that we already abuse view very much so in a lot of ways. So most of the issues we ran into had to do with us. You know, learning a process we had to, you know, kind of read develop our development paradigm in a way for how we build things because obviously we're switching over from doing render functions to doing templates ourselves. And there's a certain bit of Learning curve associated with that.

 

But it did, I believe, have the impact overall of being easier for users to contribute, and also a little bit easier for us to maintain.

 

So, but I think 2020 is when we spent most of the time toying around with it.

 

John Leider (20:52.138)

It really wasn't until TSX got in that things really took off. We were kind of, maybe it was just me. I say we're because I try to include all decrees of accomplishment and failure as a we thing, but it might have just been mostly me. But I, you know, it was very difficult to kind of.

 

recreate these concepts and approaches for how we build components. It was one of the things that I spent a lot of time in with Vutify 1 that was able to transfer to Vutify 2, where even if it all wasn't enforced by ESLint, which mostly it is now, there was this...

 

you know, kind of coding guideline outline for how everything was structured and how everything was utilized that I think allowed us, well, it's one of the reasons why beautify using as many mix-ins as it did in previous versions was able to still excel because it was so well organized and understood how the different pieces were used, um, that it just lended nicely for compositional building. Um, so, uh, the.

 

Once TSX was in, which I don't think that was until 2020, like January, 2021, it was mostly just kind of porting over our mix-ins and just testing around. We didn't have docs, which is very difficult thing early on when you don't have documentation because we had to rebuild all of our deployment processes and whatnot. So yeah, it was quite a bit. What ended up happening was because...

 

We had a decent part of the framework ported over. I made the decision for us to focus on the documentation.

 

John Leider (22:42.87)

because we didn't have enough resources, I didn't think, to adequately get version three amount of time and then also have the documentation in a way that was a little bit more expansive. One of the problems with earlier versions is, in a similar sense that the components are very difficult because they used render functions, the documentation pages were basically JSON objects, which in turn was a hurdle for people to contribute and also very annoying even as the developer.

 

you know, six months or so.

 

rebuilding the documentation, one, so that it would work when the new version was out, but so that it was easier for people to contribute to. That was another thing. The biggest concern always was trying to get more people to contribute because the framework's size was growing faster than its funding. So trying to get more people to help make it easier for people to contribute. Well, now the docs uses all markdown pages. It's real sleek and slick. It's got super easy to contribute to. I think it lended a big hand.

 

for when we actually started porting over components to not have to fight with the documentation and say we're just working with a component. So kind of all those things led up that made the process take a little longer, I think. But overall, like I was saying before, I think that it yielded much better results.

 

Steve (24:12.446)

Throwing a quick edit here. Hey Cody, I don't know if you're typing a lot, but I'm getting a lot of thuds because I think you got a microphone stand there and it's picking up all your typing or hitting or somebody's thudding something. I'm hearing quite a bit of it.

 

Cody Bontecou (24:26.376)

My mic's been muted for a while. Are you still hearing it?

 

John Leider (24:28.783)

I mean the only thing I'm picking up is my cup, but I'd move my keyboard entirely

 

Steve (24:32.43)

No, it sounded like da-da-da-da, like somebody's typing or something. It's getting a lot of background thudding. So I don't know what's been, yeah, I didn't think so.

 

John Leider (24:37.242)

Okay, I don't have my keyboard right now so.

 

Cody Bontecou (24:43.225)

Even while my mic's muted, are you hearing stuff?

 

Steve (24:45.403)

Yeah.

 

Steve (24:50.844)

uh all right so back okay now i gotta remember where the heck i was i was about to ask you something um

 

Cody Bontecou (24:57.026)

Interesting.

 

Steve (24:59.59)

Do you have any questions, Cody, before we get back to it?

 

Cody Bontecou (25:05.349)

Yeah, I'm happy to. Yeah, I definitely do. I'm curious how you're managing. Oh, yeah. Sure.

 

Steve (25:07.954)

All right, all right, so let's end the edit. Hold on, so we'll end the edit here. Now go ahead.

 

Uh oh.

 

Now he froze. The power of my voice. There, now you're back. Now you're back.

 

Cody Bontecou (25:16.889)

What's up, Steve?

 

John Leider (25:17.858)

took them out.

 

Cody Bontecou (25:21.933)

Am I frozen? Can you not hear me? Okay. Yeah, I'm just curious how you're managing your docs. You said they're all in Markdown, but you're able to render these Vutify components.

 

John Leider (25:37.438)

So the initial docs were always up until version 3 were built on SSR, actual had a node server running in the background. This used a Versals version 1.0 architecture. When they moved to version 2, and this is kind of where the industry moved, where everything was kind of a cloud function, there were less of a node server, at least for website purposes.

 

less of a notes server running in the background, and most pages, or most projects, were perfectly fine with what's called SSG, Static Site Generation.

 

which is, it's like kind of the mix of both worlds. We take the views and everything the user sees and we pump it through the SSR and get the output and then we save that into a file. So it's kind of what helps us have, it's what allows us rather to, instead of having to serve up things with a node server, we have the pages already generated.

 

John Leider (26:46.228)

It's kind of evolved over time. Like I said, in version two, we use JSON structures for most of the jock docs generation. Everything now is in markdown play, markdown. And it's a combination of markdown. And then we have, I mean, it's a, the documentation is a genuine view app, like to all degrees. Like what you see is what you get. It's not built within like view press or a bike press or whatever the case may be, it's 100% view defy.

 

Everything in the documentation is consisted of just components for the various features and then the actual markdown pages themselves. And, you know, as that was kind of the baseline that started out and then we expanded to kind of make the pages more powerful where we could, you know, designate things like front matter where instead of us having to.

 

Again, having a JSON file where we put in all the page information and data and like the system pulled from that, you can actually do it all in the actual Markdown file itself. And then it was kind of like the baseline for, you know, everything is in Markdown because people know Markdown and that's easy. And then there's a lot of cool stuff we can do with the Markdown tools to where

 

we can say, hey, if you see this element, instead put this there, which is why we're able to like put in components or put in different injected features on a page that are not marked down with a lot of our configuration stuff. So, and to expand further on that, once everything is actually gets into rendering on

 

like CI to deploy to the server. We also have, we utilize a service called Crowdin, which is a service that is, it allows us to have users contribute open source to language and for different lookouts. And...

 

John Leider (28:52.886)

This is cool because they could just do it inside the markdown files themselves. And whenever we go to deploy, we're able to, we download all of these, uh, translations and then they get rendered in their own explicit. Locale. So the, there's an entire file structure when it's deployed, there's no like server response, so literally it will have in the project, it has, you know, forward slash EN and then all the pages and forward slash.

 

KO and then all the pages associated with it. So they all have to be rendered. So it is kind of a lengthy process. And we're always, we actually put some effort earlier in last month to decreasing the deployment time. So it takes, it takes, we usually took about 20 to 25 minutes to actually do the whole process. And you can get it down to like between 12 and 16. It's still pretty high.

 

there will be some scaling we're happy to work with. So yeah, we're spending a lot of time trying to, you know, improve that aspect, but yeah, it's a very, very large chain process for how we take everything that's basic markdown that people are used to and we're able to kind of in the background, do all of the fun FUTIFY stuff and then output it using all FUTIFY components.

 

Cody Bontecou (30:10.381)

Yeah, I'm looking at some of your source code right now. And there's like in your docs markdown, there's like an example component that I see. And then you actually have a file prop to like a view file in your like. And it's actually like pretty incredible how you did that. I like that a lot. And then you have just like this view component that's generating an example of like that's what you're rendering in your docs, which is.

 

John Leider (30:18.249)

Mm-hmm.

 

John Leider (30:26.189)

Mm-hmm.

 

Cody Bontecou (30:39.737)

very powerful and like you said, it's like very accessible to contribute to.

 

John Leider (30:44.542)

Yeah, it's also a good example for anybody that's working on a view project to see what we do in the docs, because it's an enterprise-sized application with all of the files and the functionality and everything works together. So it's being able to see how we do things can, you know, I know whenever I wrote the initial docs or beautify 2, there was a...

 

hacker news SSR example that Evan you put together. And I didn't know how to do anything with SSR, but that project worked and it served as the baseline for me to.

 

try to work through in that regards. And ever since then, there's always been a really high focus of trying to make the documentation good so you can just find stuff. It just works nicely. There's actually quite a bit we've been adding lately to make that better and some things we're going to do in the future. But yeah, that's the idea is that when you're kind of in there, the information that you're looking for, you're like, oh, wow, it's got information about that. Or hey, it supports this API because most of our components are so expansive

 

So, but yeah, hopefully that answers your question.

 

Cody Bontecou (31:57.333)

Oh yeah, definitely. It's actually a really nice code base to look through.

 

John Leider (32:04.202)

Yeah, I have really bad...

 

I don't want to say OCD because that's not the right terminology. Maybe anal retentive is the correct word, but I spend a lot and absorb it an amount of time in the docs because despite being, you know, the original creator of Udify, it's so large. We have different core members that kind of have like their own little slice of the framework that people can still contribute to the devs or the community. But it's kind of like their little domain, their little area where they can, they can feel comfortable in.

 

a little bit slice of the pie. So I'm always in the docs needing to use them for things because for the most part, we have concepts that have been the same since the early versions as far as the way properties work. Our naming conventions have always been the same. But the big thing with version 3 is since we expanded the API even further, we had to move away from something.

 

I really like Boolean props. Excuse me. I like Boolean true props. Because I don't like to have to write a bound variable. Bound variable equals false to something. Because its default state is true. I want whatever the state is to be what it is. And then the Boolean prop, which is instead of having something that says show dialogue, it's high dialogue. Because the dialogue's already shown right. So these are kind of concepts that have stuck around.

 

one shape or another moving into version three. But we had so many Boolean props that we had to actually merge them into a single prop. Good example would be you have a regular V button component from Viewtify. In version two, you could change its sizing by just giving it a prop.

 

John Leider (33:53.334)

x small or x dash small or small or x dash large and these were all Boolean props and they were you know they would apply that particular styling. Now obviously these were separate properties but they were still exclusive in that if you have one you're not going to want to have the other so if you have an extra large button you wouldn't need to have an extra small property on it. Anyways

 

So now it's all got merged into one prop. So it's now just size equals small, it's just small, large, et cetera. That was kind of a natural, it's a natural consequence of the framework's API growing. So it was kind of something we had to move towards, but.

 

And saying all that, that most of the new properties, most of them, I mean, all of the new properties as far as I'm concerned, follow that same semantic nature in version one and two. They're just different. So I still have to learn some of these new concepts for some of these things. And I am in the docs kind of all the time. So, you know, I'm always going to pages. I'm always looking at things. I'm always making sure that a process feels good.

 

And I think that is what kind of makes the documentation code as good as it is. And, um, you know, I think that's one of the reasons why people like our documentation because it is so expansive and, um, well, well put out, well thought out, should I say.

 

Steve (35:27.646)

So you had mentioned briefly a huge monumental, I think you said 3.4 release coming up and it's going to be before, what is it, ViewComp? You had mentioned...

 

John Leider (35:36.387)

Mm-hmm.

 

John Leider (35:42.366)

Yeah, so ViewConf is, I believe it's the third and the fourth of November. So, um, it'll be, we're shooting for November 1st, I think it is. So it's out for a couple of days before I get my, my talk on it. Um, so yeah.

 

Steve (35:56.102)

So what is it that makes this release so huge? You can have everything out of labs. Is there a whole bunch of new components? What is it that makes it?

 

John Leider (36:02.802)

Yeah, there's quite a few components that are coming out of labs. So we do have a roadmap that expands on this. But we have, I think it's nine components that are going to be either new or moving from labs up to a combination of both. And this is going to include not only existing components, but some new components, which is something we haven't.

 

done in a while because it's kind of hard to release new components when you haven't ported over all of the ones that exist in version 2. So...

 

Steve (36:36.594)

So are you breaking that here on Views on View, or have you already put these out somewhere else?

 

John Leider (36:42.655)

It's kind of out there a little bit, you know, but not like... So, but it's just meant to be a culmination of one year of hard work on version 3 of polishing and porting. And

 

Steve (36:44.318)

Ah, dang, okay. Semi-exclusive. Ha ha ha.

 

John Leider (37:06.946)

is going to be, I think, representative, like I said before, of what we wanted to release at version 3 launch, but weren't able to. It includes data table, which is a big one.

 

You know, data table is for all intents and purposes, it's a stage four. It's not, it doesn't have any changes that are coming to it breaking wise. It's too close to release. So the only thing that could be happening is either porting over existing or new functionality. So it's one of those things where even though it's there and it's ready, it's still in labs because we are still testing it. So a lot of people as they should, aren't using it in their production applications or upgrading because they don't have access to this component. So this is gonna be a big one. And then...

 

And also, like I said earlier, I like to have fun with it. I'm a big gamer. And I've always named releases. And I'm trying to have fun with a little storyline of the releases. So we have some banners that are going to be associated with it, and these themes of a spaceship assault, the Black Guard fleet, and the concept behind it is...

 

that we're coming back to take over the planet. Vutify has been gone for a minute, and some people have been enjoying their time bringing users in the Vutify community into their ecosystem. But with version 3.4 with Blackguard, it's gonna round out our arsenal. So the idea is that Vutify is coming, and I'm kinda working on a little bit of a, I'm gonna be spending some time on trying to promote that, and just do something cool.

 

can't always be serious work, you know? So at certain days I try to switch to the other side of my brain and do some creative stuff. But yeah, it's just, it's meant to be, you know, a really big celebration of VUdeFi and obviously we're gonna be at Vucomf Toronto almost immediately afterwards. So we'll be able to discuss that and show users about the new features and functionality, but also some of the old components that are not ported over.

 

John Leider (39:15.126)

the new features and functionalities that they have, because we have a lot of pieces of the framework that was abstracted out into, it was duplicate functionality, it was abstracted out, and more components utilize this functionality so we're able to do more safely. A good example would be, so we had, in version two, we had a calendar component, and we had a date picker component, and we had a time picker component.

 

And with the calendar, there was also some smaller subcomponents as well that utilized their own proprietary versions of date management and worked to the degrees that they worked, but were ultimately developed in silos separate of each other. So the

 

One of the things that we've introduced, it's actually in labs right now, is we have a new composable called the date composable. And now all three of those components are going to pull their information and data from a unified source that is also following, there's a popular datetime interface called ioutils. And essentially if we follow the interface that they provide for interacting with the data object

 

They have interfaces for other popular date libraries like Luxon and Moment. So we're able to provide an internal, this is the date system that we use for Vutify, but you can now swap it out.

 

just instantly with a different date library that supports that same interface. And then again, so that allows us to kind of homogenize this behavior and this functionality into a single source. And then the components that are able to utilize that now have access to features and functionality that may have not existed in the previous version. Because now instead of referencing something that's again coded proprietary and local, it's something that is now a shared feature in the framework.

 

Steve (41:19.094)

Yeah, date time has got to be, I think, one of the trickiest things to deal with just because of the huge number of variations and time zones and time formats and date formats and adjustments. And yeah, to people who do that stuff, we owe you a lot because that's one headache I don't have to deal with anymore, right? It's just, it's, you know, dealing, working in Laravel and PHP a lot.

 

John Leider (41:41.268)

Yeah.

 

John Leider (41:44.963)

Yeah.

 

Steve (41:48.27)

Carbon is the tool of choice that we deal with and makes things so much easier. I mean, you look at some of the documentation, you're like, wow, they've got a method that calculates the diff from here to here and I can type in the text that says, give me the third Friday in April and it will give me the date for that particular, stuff like that just blows my mind. So kudos to whoever does that date time stuff and just allows us to use it.

 

John Leider (41:52.608)

Mm-hmm.

 

John Leider (42:03.425)

Mm-hmm.

 

John Leider (42:13.29)

Well, yeah, that's honestly it is. It has always been, and it is a difficult thing to support. Um, we're doing it slightly different this time around. And then they also, the other cool thing is that if we do decide to change how we approach it, we have a single interface that everything's working off of. So as long as it returns the same data, it doesn't matter how it gets it right. Um, but the other thing that there are other reason why I wanted to do it. And, and this is something that's true. Other, um, global settings of unify, for example, like language and whatnot.

 

Steve (42:31.806)

Exactly.

 

John Leider (42:43.03)

where the.

 

John Leider (42:49.834)

I lose my train of thought sometimes. I guess it's a product of working so much, but forgot where I was going with that one. Sorry.

 

Steve (42:57.402)

Now what would be interesting, and I'm curious to see how much you've looked in this, is I know that JavaScript is supposedly adding the temporal API to be able to more of a native date handling API that so you don't have to use external libraries. And I haven't investigated enough to myself. I'm going to guess that out of the.

 

John Leider (43:12.663)

Mm-hmm.

 

Steve (43:17.682)

box or you know when that first comes out it's not going to have a lot of the functionality that some of these external libraries and tools have just because they've been around for so long. I don't think they would try to do everything in one fell swoop. I'm just curious to see if you've looked at that or heard of that and or if that's something that's too not well it's not well developed enough yet.

 

John Leider (43:24.479)

Mm-hmm.

 

John Leider (43:33.516)

We have.

 

John Leider (43:38.062)

Well, we did a prototype with the temporal API, but the support was definitely lackluster. The benefit of having the adapter is now we can have.

 

potentially in the future we can have a temporal adapter that implements that because, you know, all we're doing is implementing this interface for ioutils that just says, hey, this method calls getWeeks and it expects something to be returned that resembles this, which is why it's also, you know, we do utilize date for the date object for our default adapter, which does have its own limitations. And this is one of the reasons why we had

 

separate functionality with the lux in the moment or whatever so that maybe we can't solve every problem there's going to be things we can't solve and for someone like okay well then I'll just use something that's off the shelf

 

Right. So it kind of takes a little bit of pressure off us for being able to have to support every niche use case that exists within time zone and day calculation. So it's not like it's not like a scapegoat for us to say, oh, we don't have to take care of this because you know you have these other options. But what it is, is if you, you know, building an application that is affected by a bug that we're unable to resolve. You have other options. Same thing like our, our IT in our language.

 

language translator, but you can also hook up view 18 in if you want to you can hook up other ones they just Trade right in so that's kind of the The thing that I really try to do with beautify is One not require any dependencies. I think I don't know if temporal

 

John Leider (45:21.006)

would be a dependency right now because I don't know if there's like a, I don't know too, too much about it. And if like how it could be used in existing browsers, but I know that the team was experimenting with it and we decided that there was enough support for right now. But, um, you know, other than that, we, um, we're, we're trying to,

 

utilize date as best we can to have the components work as a user would expect, but also still just provide them with other options that they can go to. And that way we don't have to have framework dependency where we say, oh, you have to have Luxon or Moment to utilize Vutify because we have a zero dependency policy. But it's that, you know, you could make your own if you wanted to.

 

There's 12 methods that return information and data. So all you do is just duplicate those methods and return it. So it's just kind of one of the approaches that I think what makes Beautify so flexible is there's so many different ways that you can approach it. You can use what we have. You could use something else that's off the shelf or you can build your own.

 

Cody Bontecou (46:20.245)

And so if you were going to, say, swap out the I18N with view I18N or something else, is that as simple as a prop? What does that take?

 

John Leider (46:33.95)

I don't know, it's in the documentation is definitely a much more featured description that I'll give here. But the, it's not the same interface as like when you're working with the beautify data adapter. It's a similar process. And all it involves is there's a specific adapter.

 

that Vue ITN has.

 

And this adapter is, and again, I'm going to use the word, the term composable. And this is again, it's like pseudo pure function that usually starts with use X, Y, or Z or create X, Y, or Z. So this is the way that, uh, view ITN passes out its functionality. And, um, we have an adapter prop, um, that you pass to, um, the local where you basically create a new instance of view 18 in the only manual.

 

process is if you're doing some specific changes that modify the default language of any of the keys for the various components. So if you're not using that then yes it's just as simple as passing through the Vue ITN adapter.

 

Cody Bontecou (47:52.261)

Okay, yeah, I'm looking at that now actually. And so, Vutify is providing this Vue I18n adapter. And what is kind of in that adapter? So like if I was gonna build out my own adapter, for example.

 

John Leider (48:08.58)

Well, the I18n adapter is actually, that one in particular is from Vue 18n. You can create a custom translator.

 

Essentially all that the default one does is well the locales Excuse me the different language items are part of a JSON object. I don't know if you guys are noticing a trend here with JSON But they're part of a JSON object and they're just keyed out and then our Default translator, you know, it receives a key checks if that key exists in the set and then it just returns the information so

 

could I'm sure they have there's something specifically on that doc page but if you're just looking like if you're because you said you were kind of browsing at the code the easiest way would be to look and see what we're doing with our translator which I think again it's just a simple key lookup and then you can just pass in your own

 

Cody Bontecou (49:07.877)

For sure. And that's specific to IA-89 and translations, but this adapter API as a whole, does it kind of adapt throughout the Vutify framework for other areas of customization?

 

John Leider (49:11.145)

Yeah.

 

John Leider (49:20.266)

I understand what you're saying. So for the locale thing specifically, the adapter is a little bit different than the way that the date one works. So it's less, it's only one argument translator. So it's like, whatever you get back for the translator, you just provide it with a key argument.

 

And that's it. So whenever an adapter is created, all it is a function that accepts a key. And then you take that key and reference, you know, whatever object or whatever area that you're pulling in information for the language at. So it's just really a basic function. So just accepts a key argument. That's it. So there's no like methods on it, like, you know, get.

 

key or set key or anything like that. It's just a simple function.

 

Cody Bontecou (50:25.777)

Cool. I think I'm curious if, I'm curious how it has the like styling of Vutify components shifted much from version two to version three. I remember that originally I would run into issues like kind of like the base Vutify components are incredible. But if you ever needed to kind of customize that further.

 

it was challenging, at least at the time. I'm curious if that has changed or if there's any new functionality there.

 

John Leider (51:05.346)

Sure, so yeah, there's a couple of new pieces of functionality that was implemented to make that process a little easier. The first one is our global defaults configuration. So the user can now, at the Vutify config, define the default property values for any component in the framework.

 

You can define default classes and styles. You can define nested defaults. So you could say a V button inside of a V card gets the styling all at the root.

 

And with the additional API options that exist in version 3, this is the most expansive and typical way that you're going to modify or utilize the application. We did add quite a bit more coloring into the default generated theme. So there are more colors to pull from or configure in your application. And then, you know, ecosystem has moved to VEET for

 

all of this development and VEAT is fast. And we have a VEAT plugin that you can hook up and modify our SAS styles, which is the second way that is prominently modifying the application is done through. And this is for more CSS-centric customizers and changes. For example, you want the.

 

Default border radius of a button to be 7 you can set that you can also set that in the Defaults configuration for the component

 

John Leider (52:49.262)

And then the thing that adds those and tops those together is we have this new concept called of, well it's aliasing but they're virtual components. So you can import one of our components and you could create an alias. So for example, let's say that your framework has H component. So it's an H dash button. So you could say that the H dash button component is an alias of V button.

 

John Leider (53:19.476)

access to have default set globally for any name and then it also still works with nesting.

 

So what this allows you to do is, you know, say you have three or four buttons in your application, instead of creating three or four different button, you know, component files or a single one that has some property set up to where you define, you know, oh, this is going to be primary, secondary, et cetera. You could just create a virtual component, you know, V button one, two, three and four with different settings that'll just work in the application. And for the situations where you need a component that is maybe wrapping multiple view to five components. So you're like, okay, that's great.

 

a card and I need to do some additional modification.

 

Well, we recently introduced the ability to utilize the defaults engine locally in your components. So you can register your props for the component. You pass those to our defaults composable with a registered value. And then it looks through all the settings and says, OK, H button has all of these or H card has all of these so that you can actually utilize those props and that functionality in your own custom components. So these are the three big things that really improve the customization.

 

options for version 3. Those are all brought together with a concept called blueprints. So blueprint it's very similar to what presets were in version 2 but the idea is they're meant to be encompassing of everything in the application. So we have you mentioning the styling of Utify over the years. Well

 

John Leider (54:59.154)

It's kind of difficult because we, you know, the view, excuse me, the material ecosystem moved to material three or U or whatever it's called rather quickly, but they didn't have very any components. So it kind of put us in this awkward intermediary between half the components, you know, had visual representations in version three and maybe half didn't. So what ended up being the case in a lot of situations was.

 

we'd take a default if it didn't take away from the collective styling of all of the components for that to be added. And then to replace that, we have Blueprints. So we have a MD1, MB2, MB3 Blueprint. Now these are gonna be expanded. They're one of the weaker fleshed out features in version three, but powerful in the sense that in a later version of Unify, all of our

 

built-in defaults that we supply components are going to exist in a blueprint itself. So there will be a Vutify blueprint that sets all of the defaults of what Vutify looks like now. And then there will be material one, material two, material three blueprints. And then that makes it easy for the users to then create their own blueprints with that particular functionality. So all of these combined has just made...

 

Customization options pretty much endless. I mean, I know everyone would say, yeah, the options are endless, but really you can come to the same conclusion in so many different ways. And the way that we've structured the API in content components for version three. So like a content component would be like a card or some expansion panel. All components have been restructured.

 

to accommodate three different ways of interacting with it. So you've got props, so you interact directly with props. So you've got a card, you can just do title equals this, text equals that, subtitle equals this. It just works. Then the second way is slots. So say that you don't wanna have to configure where the element is located.

 

John Leider (57:18.51)

where the car title item is located with the car text, you just wanna use a slot, so use the title slot, because maybe you wanna change the default color to a different one. So you don't wanna actually mess with the element, you just want to be able to customize whatever's gonna be inside of that title or text, or whatever the case may be. And then the third way is the completely verbose one, which you use each individual component. So all of the components that we use to build,

 

everything in Vutify 3 with the exception of 2 for inputs is public. So if you want to use a vCard title, a vCard text, you can explicitly use those components. If you want to just access, if you just want to give some information and have it work, you have that availability. If you want to make small customizations, you can. And you can also utilize a combination of three, all three. You know, you can have, if you want to set for your card a title and a subtitle, and then for the title,

 

some slot because you want to make it a darker font. And then you manually use vCard text because you want to do some things with that. And you have a combination of using API and slots and Rigo components. And it all just works. So this is the big focus of, I mean, Viewtify has always kind of exposed everything, but really putting it out there like, hey, here's everything we use to build these. So you have all these ways to interact with our components. We have all of these different

 

customization options, it's easy to set up and then at the end of the day if you're like I don't really like how you know this carousel is built. Well you have all of the parts to build the carousel and you can just build your own. And we often show some of these in examples like if we have a underlying component for carousel is V window. So V window is just the core functionality of a window sliding into frame and then that is what's used. But even but on the V

 

we have an example that is like a pseudo carousel that's showing, hey, if you wanted to just make your own carousel using this as the root component for it, here's how you would do it. And yeah, I just believe all of that just makes the customization argument for Vutify completely mute because there's just so many ways to tackle it now without complicating your application.

 

Steve (59:42.874)

All right, so let's, before we wrap up, I wanted to move off of the code specific discussion and ask you some organizational stuff. Now, forgive me, I don't remember when this happened now. Is it correct that you were, and this is just so people understand how things, maybe the sausage is made behind the scenes. You were full-time on Vutify and then you had to leave, or what is your status with that right now?

 

John Leider (01:00:10.469)

I took six months.

 

not working full time on beautify, doing some contract work and basically set myself up to go back to working full time on beautify which I am now and why there's been such a massive you know because I've been back full time on beautify just a massive push.

 

of improving not only the quality of things around the ecosystem, but the availability in the ecosystem on top of the framework itself. So spending a lot of time trying to kind of bring in a lot of the different properties and features and functionality of Unified to be a little bit more of a unified experience.

 

have things like right now we're testing out where users you can log into the documentation using GitHub and you can choose to sync your settings so that you can get another computer you log in with your GitHub you get to have all of your documentation settings the same on all logins and we're adding a bunch of new things right so you know this is meant to improve the documentation experience and then we're adding you know we have issue generators

 

John Leider (01:01:25.808)

We're just trying to bring all these different pieces so that when users come later this year, because with the release, it's going to be, with big releases, you get a large influx of users that tapers off. So the idea is to have as much in place as possible before that occurs. And just trying to represent a complete experience of working with Unify still for free. So that's kind of the goal.

 

Steve (01:01:55.058)

Now you do have some paid options as well with UTIFI, don't you, in terms of templates or other things that people can purchase?

 

John Leider (01:02:02.378)

Yeah, we have a store where we have vendors that make beautify themes that we sell. I'm not too gung-ho or spend time in that because it's, my wife handles most of that area. But in terms of support, one of the things that I've been pushing for this year is because sponsorship is too volatile. I mean, literally a month and a half, two months ago, we lost two big sponsors.

 

and that's $3,000 a month. So it's like, it's too volatile and it doesn't offer any sort of.

 

John Leider (01:02:41.054)

It offers sustainable revenue, but it's at a cost. So I've spent a lot of effort trying to provide support options for Budify. I have no interest in making anything hidden behind a pay wall, component-wise.

 

So the thing that we started focusing on right now is we have some support options and then also our discord, which is where we are. Our community is at for users that want to come and ask questions, get help with beautify the discord earlier this year, introduce subscriptions. So we've been trying to utilize that to provide users with just some smaller avenues of getting support through text. And that's, that's kind of the start.

 

is coming before Blackguard will be, you know, we have some, we're going to offer a dollar a month paid subscription for Viewtify so if you're one of our github dollar subscribers you'll get some extra features in the documentation some things like being able to turn off ads and maybe bookmark pages and stuff like that. We're also working on

 

expanding out some of the learning tools of UTIFY. So with some videos and some informational content, that's really what the, you know, the big focus is going to be is just when users come in just have this complete experience. Like they have information they can get help that is free or paid and there's so many different areas to be able to get help. And there's so many different areas to, you know,

 

One of the big things I hear from people a lot that they enjoy is, they're like, hey, I think it's cool that I can work on this and I can book time with the author to get help. And I think that if the focus is good enough on that, we're going to keep, I mean, I guess, I don't want to say keep throwing stuff at the wall until it sticks, but open source is hard. At least it is for me. I haven't cracked it yet. So I'm just kind of trying a bunch of different things. That's why I'm trying to create some...

 

John Leider (01:04:46.374)

fanfare around the releases to try to spark some interest and motivation and kind of just create this cool area where people can you know yeah you have a product that you're using that's a professional thing but there's also kind of a non-robotic element to it that gives me at least an opportunity to not burn out doing the same thing you know because i've been at this for almost eight years straight

 

My longest job I've ever had, so.

 

Steve (01:05:15.87)

the

 

Awesome. All right, so with that, unless there's something else you wanna cover, John, that we missed.

 

John Leider (01:05:26.754)

Nothing specifically. I don't know if there's going to be some time at the end to rep out some properties, but I do have a couple things to send people to if they're listening to this for the first time and hearing about Vutify for the first time is tryvutify.com. Just one word, no dash, no nothing, tryvutify.com, and you can get started with the Vutify 3 application in less than a minute.

 

Steve (01:05:35.431)

Yes.

 

John Leider (01:05:55.69)

have a project up and running in development and looking in the documentation, learning about it in less than five. So for anyone listening, they wanna give it a shot. It's the easiest way to do it. And then we have again, all of these different.

 

avenues to get help. You know, you want to just come into the community and ask the community people and the community people, you know, you can get help from them. We've got github discussions. We have, you know, paid support stuff. So it's like no matter where you go, you have an option that's available including a free one. And so anyway, so that's something I'd like to put out there is trybutify.com

 

Steve (01:06:32.614)

All right, that's what's known as a shameless plug. So yes, that's perfect. Alrighty, well thank you for coming John and catching us all up on Vutify. We look forward to the 3.4 release. In particular, sounds like it's gonna pack quite a punch.

 

John Leider (01:06:34.882)

No.

 

John Leider (01:06:48.642)

Hoping so.

 

Steve (01:06:50.022)

So with that we'll move to PICS. PICS are part of the show where we get to talk about anything we want within reason of course. You know, it doesn't have to be tech related, books, movies, games, food, places, et cetera. So we'll start out with Cody. What do you got for us, Cody?

 

Cody Bontecou (01:07:06.105)

All right. Not sure how many of you follow the Twitter hype. Every day it's changing, but currently they're talking about an IDE called Cursor. And it's this AI slash chat GPT enabled IDE. It's basically VS code integrated with the smart chat GPT kind of window. And it's it.

 

I kind of scuffed at it at first, and then I finally got around to trying it yesterday as I was running into some TypeScript issues, and there's literally this little hover button that comes up that says, I think it's like AI fix or something, and you click it, and it can browse through your entire code base and basically solve all of your problems. I was amazed, honestly.

 

Steve (01:07:58.598)

So how is that different than say, like using VS code with Co-Pilot?

 

Cody Bontecou (01:08:03.289)

Um, so I'm not sure what like the latest co-pilot integrations are. I haven't used co-pilot since the, the beta, but, um,

 

Uh, yeah, like I basically can just, it somehow understands your entire code base and all of your TypeScript, um, uh, TypeScript, you know, like inheritance, like the entire just architecture of your project. And so for example, I wanted, I used ChatGBT to like mock some data for me, but the data was incorrect. And then I was able to reuse this thing and like click in like, Oh, it turns out this is actually.

 

an enum, and you can only use like three different types of strings, for example. And I've only used it basically for that one TypeScript problem, but it worked so well that I'm going to continue using it. Over the last week or so, I've been using ChatGPT in my free time for projects, just learning a new language, and it surprised me.

 

And so I'm using it more and more for code. And this IDE does a really good job of just integrating it right into your project. So instead of asking the question and then copying the code in, plugging it in, running into new errors, this back and forth between browser and IDE, it's just all there. And so I'm actually really impressed. I thought it was lame and just kind of like a money grab, but the more I use it, the more I'm amazed, scared, who knows, right? But...

 

That's, yeah, cursor. Big recommendation.

 

Steve (01:09:40.122)

You can find it at cursor.so. I don't know if.so is the replacement for io.

 

Cody Bontecou (01:09:48.485)

So all the cool kids are using these days.

 

Steve (01:09:50.49)

Right, yeah, IOS so 2010s, I guess. All right, was that it?

 

Cody Bontecou (01:09:58.285)

Yeah, yeah, that's all I got for today.

 

Steve (01:10:00.758)

Okay, my turn. So, my wife is a very large Star Trek fan. Next generation.

 

Voyager, Deep Space Nine, she knows them all, loves them all. And I am not, which is fine. But I've seen enough Voyager shows here and there, I remember when it first started, that I knew some of the actors. And there's a number of different podcasts that are out there related to Star Trek. There's one called Shuttle Pod, which has a couple of different actors that were actually on the show for a while.

 

And the other day I was walking by and she was watching an episode on TV. They have it, you know, they have video versions of the podcast. Well, they were interviewing an actor named Robert Picardo, who is the actor that played the hologram doctor on Star Trek Voyager. And what attracted me to this, I happened to walk by at the right time and I was cracking up going, I've got to watch this whole episode because...

 

I suffer from a, I don't know if you would call it a medical condition known as RBF, otherwise known as resting bitch face. And what that means is people will look at me and think that I'm mad at them, you know, I look like I'm angry or something and I'm not. And it stresses me out uncontrollably. You know, my kids have to tell their friends, no, my dad's not mad, really, he just has RBF. You know, that's what I tell them to tell their friends. And so anyway.

 

In this episode, Robert Picardo is saying, he's telling the story about how he got the role of the doctor and how he went in and he just told like a simple one-liner. It's in the preview right at the beginning of the episode on YouTube, it's episode 2.23. And he says years later, his dad's told him, "'Dad, you got that job because of your resting bitch face.'"

 

Steve (01:11:58.262)

And so I'm, and he's describing about how, you know, when he's at rest, his face, you know, his eyes look like this and he looks like he's angry. And I saw that I'm going, Oh, thank you. It's not just me. You know, uh, I appreciated an actor telling that story as to why he got apart because of his RBF. So, uh, I haven't watched the whole thing, but that portion of it is really funny and really interesting to watch, especially somebody afflicted with my. My, uh, condition of RBF. So.

 

With that, you can sort of understand why I like dad jokes so much, deadpan jokes. You know, Steven Wright's my favorite comedian because you tell them with a very straight face. You're not like totally animated, so that's why they fit perfectly into my... how I look. Not only how I sound, but how I look. So anyway, on to the dad jokes of the week. So... Oh, I've got to get my drums out here. Okay. So, did you know that Apple...

 

You know, they're always diversifying. They've started a clothing line for pirates and their best seller so far is the eye patch.

 

Steve (01:13:10.539)

When I was a boy, when I was younger, I had this really rare disease that required to, required me to eat dirt three times a day in order just to survive. I was so glad my older brother told me all about it.

 

Steve (01:13:26.382)

And then John, this one's sort of appropriate for John and I. Do you know why the bald guy got tattoos of rabbits on his head? Because from a distance they look like hairs.

 

Steve (01:13:43.89)

Very good. So with that, best for last, our guest, John, what do you have for us for picks?

 

Cody Bontecou (01:13:45.619)

Great stuff.

 

John Leider (01:13:51.576)

Um

 

Well, actually, something small that I threw together last week that I've been using a lot. I often have a lot of times I'll copy code and need to send it to someone, share with them, and if you're posting on like Discord or Slack or something like that, it's always going to take up a lot of the screen. So one of the things we often tell people in Discord is, hey, post us like a paste ban or a link or something. And I just didn't really like the bins that I had been using. And the one, one of the ones that I'd use mostly got bought out

 

user-friendly anymore, so I just threw one together that I used just specifically. For me, that's kind of cool. It's called vbin.io. It's funny you guys are mentioning I-O really, but v-b-i-n.io. It's just a little basic Monaco browser for pasting code, and it actually takes all the code and it basically zips it up into the URL, so there's nothing that's saved on a server or anything like that, and it's just super quick. I go to it, copy, paste something, and then I'm able to send links.

 

to people, to code.

 

Steve (01:14:56.774)

Yeah, I saw that reference somewhere. I don't remember why I saw it, but I did see that you had spun that up when I was looking for one. I think I was looking for a paceman or something and came across it.

 

John Leider (01:15:05.61)

I just wanted something that didn't have ads and wasn't full of... This should be like the least amount of things you have to do to get it. It's like paste and click copy at the most. It should be all you have to do, not accept all this agreement stuff and whatever. So anyways, that's kind of what I... That's my pick.

 

Steve (01:15:22.898)

Or either that where you can just put a code snippet without having to build a whole on application, you know, a structure like a code pin or a code sandbox or something like that for sure. But yeah, those are great.

 

John Leider (01:15:34.646)

We also have a Budify Playground where you can do that. So we used to use CodePen, now you actually can go to play.budifyjs.com and we have an interactive Playground where you can literally work with Budify live, you can change the versions of Budify for testing things, you can create new components, it's pretty cool. It's another one of the ecosystem things that we're trying to, you know.

 

really push for and make high quality so people they kind of have this little group of services and functionality that kind of fleshes out what we offer and that's another one of them.

 

Steve (01:16:12.806)

Yeah, those are cool. Tailwind has one, and so does Vue itself. And I've used that quite a bit just to play around with some concepts in Vue 3 to get my head around them. Like component Vbind is one I played with quite a bit. So yeah, that's awesome to have a playground like that. Just whip something up. And I think you can share the URLs, right? Say, hey, this is what I've got. Here's the URL. Go take a look at it.

 

John Leider (01:16:36.85)

Yeah, it's the same concept as the VBin where it takes all of the code and it converts it into something that can go into the URL. We're going to have something in the future where you can save it to your GitHub account as reference, but that's one of the big things is we didn't want to have to store anything locally. So you just, your URL is longer, but it's, it contains everything within it. So yeah, it's.

 

Steve (01:17:00.529)

Right.

 

Cody Bontecou (01:17:02.861)

Yeah, keeps it static, keeps it cheap. And just on that playground and bin idea, there's an article I read recently. The title is Concise Explanations Accelerate Progress. And I think that hits the nail on the head here, creating this super fast code sharing playground environment helps you and the community debug and communicate with one another, accelerating the understanding of the framework.

 

is very valuable.

 

Steve (01:17:35.314)

All right, with that we will wrap it up. John, before we leave, I know you've mentioned the Discord, but if people want to get hold of you or yell at you or give you money or all of the above, where are the best places to do that?

 

John Leider (01:17:48.698)

Best place is you can reach out on Twitter. We have at VutifyJS

 

You can also reach out to me. My Twitter is at zero skills. So Z-E-R-O-S-K-I-L-L-Z. And then the community for Discord is community.vutifyjs.com. It'll send you a Discord invite and you can come in there and ask questions. And yeah, that should be anything else you can see on that Tri-Vutify website. It has a lot of different information about our social media platforms and documentation and et cetera.

 

Steve (01:18:23.686)

Right on. All right, so with that, we will wrap it up. I'd also like to say thank you to our studio audience for joining us.

 

Steve (01:18:34.366)

All right, always good to have you. And with that, we will wrap this up. Goodbye for now and we'll talk to you next time on Views on View.