Steve and special returning guest host Erik Hanchett sit down with John Leider of VuetifyJS to talk about the recent 3.0 release of Vuetify.  They discuss the conversion from Vue 2 to Vue 3, the people behind Vuetify, and some of the ways Vue 3 makes things easier in Vuetify. 

Hello everybody and welcome to yet another thrilling and exciting episode of Views On View. I am Steve Edwards, the host with the face for radio and the voice for being in mine, but I'm still your host. Today with me on the panel, we have a very special returning guest host. Say hello to Eric Handchett. How you doing,

 

Hey,

 

Eric?

 

hey, everybody. What's up?

 

All right, so for those of you going back in the Views On View history, Eric was one of the first panelists, were you original panelists?

 

I certainly was. Yep.

 

Yes, he was. And now, back then he was doing Angular full-time, if I remember correctly, and doing a Vue podcast and Vue videos. But now he gets to do Vue full-time at AWS, right?

 

Yeah, yeah, do tons of view, react, angular, get to kind of touch them all on the AWS Amplify team. So

 

Right, and we've had

 

it's really

 

Eric

 

fun.

 

on to talk specifically that way he does at AWS. I'll drop a link in the show notes to the past episode. So yeah, it's always good to have Eric back. And as a very special guest today, we have from the Vutify world, John Leader, the God of Vutify. How you doing, John?

 

Good, how you doing? Thank you for having me on.

 

Good, it's our privilege. We are here to talk about Vutify 3.0. Before we get started, John, why don't you just give us a little background as to who you are, why you're famous. Actually, we know why you're famous.

 

Hehehe

 

And so on, just a little background before we dive into Vutify.

 

Uh, sure. I don't know about the famous part though. Um, I started at development, uh, or started, uh, learning developing in 2000 and 13, uh, 2016 came up with, uh, view defy. It happened to get very popular. Uh, and 20, 2017, I quit my job to work full time and view defy. And here we are in 2022 and I'm. Still not homeless, so I'd say not too bad.

 

Yes, that's always a good indicator of how what you're doing that you still have a home.

 

Yeah.

 

And just as a little background, we have a couple of other episodes with John in the past where he's gone into great detail on beautify and how it got started and what it's based on. So we will drop links to the show notes if you want to listen to those for some some more background. So let's talk beautify 3.0 now. Obviously, how long's view. 3.0 been out about a year now. I'm trying to remember when it first came out.

 

I mean, it's been a minute, at

 

Yeah,

 

least

 

it's been

 

a year

 

a while.

 

or more.

 

Yeah,

 

All right,

 

feels like a couple years.

 

how's it? And with any framework, with any tool, whether you wanna talk Drupal, WordPress, you know, anytime you have a main core upgrade, one of the hardest things to catch up on is all the, what's the term I'm looking for? The environment, the, oh good Lord, everything around it, all the stuff, all the other things that depend on Vue

 

ecosystem.

 

Core.

 

ecosystem.

 

Ecosystem, thank you very much. I knew it started with an E, I think. The ecosystem, waiting for the ecosystem to catch up. So in this case, you've got ViewCore. Now you've got other tools like frameworks that are dependent upon it, such as Viewtify.

 

Mm-hmm.

 

And so it's taken a while, and with the change from View2 to View3 being such a large update, it takes a while for things to catch up. That's just the nature of the game. And so... If you followed Vutify 3.0, you know there's always been the demand, where is it, where is it? Come on, come on, faster, faster, where is it? I'm sure you see that quite

 

Mm-hmm.

 

a bit. So we're here to talk about that and both what was involved in the process and maybe any new things, improvements, enhancements, new stuff in the 3.0 version of Vutify. So to start out, I'd be curious to hear about what was the process like? Once... When did you start on the 3.0? Was it like when everything was still bleeding edge in the repo and they were still working on it? Did you wait till it was all done? How did that work?

 

Well, we started prototyping at the end of 2020, not 2020, 2019, because I believe at the end of 2019 is when the view alpha came out. And, um, but that's also a few months before COVID went off. And, uh, so we had maybe three to four months of kind of prototyping, um, in for that version. And, It wasn't until probably about the middle of... Man, I try to get my year straight here because it's been a minute. So 2020, about mid 2020, we got to a point to where we had a few options to either. kind of create a stop gap release of like an amalgamation of Vutify 2.6 and version three and the potential foot guns of releasing software that we're gonna have to potentially maintain that is not gonna be a complete upgrade or to push back and continue converting everything. Cause the entire framework had to be converted basically to render, not render functions, but composition functions. So. that was probably one of the biggest things that increased the amount of time that we had to put in because Vutify is just big. There's just a lot of code. And yeah, so I think it wasn't until... Maybe about a year ago, whenever we were able to introduce JSX into our process, or TSX, that we were able to really start kind of plunging forward, which is what helped us move as fast as we did, even though we were late on the release. Comparatively speaking, with the amount of work that was done, it was relatively quick. But um... Yeah, I don't know if that answers your question.

 

No, no, no, yeah, that answers the question. So you said 2.6. And now 2.7 has come out with has a lot, and this is maybe sort of a rabbit trail, but 2.7 basically had a lot of the 3.0 stuff backboarded into 2.6. Did that impact you guys at all? Did you make any changes based on that?

 

I think once that occurred, we had already been past that point. And I think that Kale may have spent a little bit of time looking into how we could potentially use that. It's been a while. But we just didn't have the manpower. It would have essentially split him off into doing that while we had about two other people total. That's with me working on the main 3-0. So we just really couldn't. We couldn't afford the bandwidth over there.

 

Let

 

Right.

 

me ask you this. Let me interject, Steve, for a second.

 

Yeah, go ahead.

 

You mentioned, so I'm a part of the Amplify team. We have an open source product, and I was working on some open source view. And it was interesting going back to the history of Vutify and how you guys, getting into a little bit how the sausage is made here a little bit. But you said you were using render functions for Vutify, too.

 

Mm-hmm.

 

And so. What made you change that path for Vutify 3 and go with JSX or TSX instead? Just looking at how difficult render functions are for the average person, I'm like, wow, I would have gone with, I guess, back when you write Vutify 2, like JSX wasn't as popular as it is today. But what was that kind of thought process there?

 

Well, in version two, the TypeScript support, especially TSX, was very green, wasn't in great condition. So we never ended up utilizing it specifically because, like I said, we were in render functions. And the reason why we were in render functions is because when we were developing those parts of the framework in early version two, the ability to define a template as a... functional component was not possible. Later on this was added and the support was there, but there was no point in converting over. So when we went to version three, so one of the things that did make the process somewhat uniform to convert over was that we used mixins in version two, which is what version three was meant, you know, trying to get away from even in the Vue ecosystems. And so those mixins themselves were, in essence, little composables. They were just done differently. Well, when we were working in version three, everything initially was using render functions, which can be difficult mentally, because you don't have something, I think we're all kind of used to looking at templates. It's almost like a visual reference for our brains to be able to reason about the code. and everything, essentially every element is a function. And then you're working to try to figure out how to composite those functions in a way that works. That's version two, that's what we were starting with version three, it was very difficult. And one of the things that kind of plagued us in version two was the complexity of how we implemented the framework afforded us a lot of benefits, but it also made it difficult to get contributions. So, and that was something that we were really looking in towards for version 2, is we need to have something that is more accessible for people to contribute so that we can, you know, get more help. And what that eventually led to is when Kale was, this is all Kale's genius right here, but he figured out a way to, you know, some of our baseline types and then connect the different systems of TypeScript and React, JSX. I'm not extremely keen on it, so I probably sound like an idiot. But

 

I'm going to go ahead and turn it off.

 

what it did though, what it enables us to do is to take our kind of core baseline of the framework that was for all intents and purposes kind of in these composition functions, but then add a visual aspect to it so that it was... visually mentally was able was easier to implement things especially even for the team being able to work in that because You know we understand how these internal parts played but being able to Now have a visual reference for it. We could get help. It was actually easier for us believe it or not to work in it and it's kind of One of the things that super kickstarted us being able to move forward is we got you and we get this Awesome, you know piece of dev tech and installed And now things that we couldn't really conceptualize, how are we going to implement this, became more visual. And I think once we saw how efficient the team was working with it, we decided this is definitely the way to continue going.

 

Now yeah, that makes complete sense. And also notice that you moved to Cypress and just writing JSX in your tests too.

 

Yeah, that's some next level stuff. That's Albert and Kale have got those specific aspects. And Cypress definitely is new for the framework, which is what we're trying to hope with version three to cut down on regressions. But being able to have it implemented in the same way that we implement our templates has definitely enabled us to kind of streamline our development process because it's looking at things only one way. So it's definitely been very helpful.

 

So you don't have any... are these Cypress tests all end-to-end tests? Are they unit tests as well in there?

 

So probably 80% plus of our unit tests are Cypress that have to do with components. We do have regular Jest specification tests and these are correlated to the composables, right? So if you go, if you look at our, we have, I don't know, let's just say 30 different composables that do things ranging from elevation to variant and each of those composables. especially if they have auxiliary functions that they use, will then have its own corresponding test file that only corresponds to the functionality in that composable. So that if that works good, then if there's an issue in another component with a visual regression, then it's probably how that component implemented it, especially if that thing changed in the composable.

 

I had just maybe one more question on this, just kind of looking at the source code. Just selfishly, I'm going to ask, is there any learnings that you had that you can think of off the top of your head maintaining an open source view 3 project that would be helpful for other people who may want to create open source projects in the future?

 

I mean nothing at this level. So it's too big and it's hard to convey. Most open source developers that will get into a project, the majority of them that are going to get into open source community are smaller projects. So even if they're the same amount of, let's say, popularity, downloads and whatnot, it's a completely different world of conveyance from people. I would say just if there was anything that would just span across all. Aspects of it is be patient and surround yourself by smart people and listen to them.

 

No, that's good.

 

So speaking of your team, you've mentioned, I think, Kale, you said, was one developer. Just so everybody knows the resources that you have for working on this, how many people do you have, I guess, working for you full time? And then, at least in the Vutify 3.0 release, how much did you take from open source contributors, people that were just contributing to help out?

 

So, Vutify itself, we don't have any hired devs. Everyone that contributes is doing so with open source in mind. With that being said, one of our funding paths, which is Open Collective, is used specifically to pay our devs that we have that, so should they want to be compensated, which is pretty much just kale. who does this full time. But as far as everyone else besides Kale, they do it specifically on, you know, whenever they want to and there's no like payment involved. So it's an interesting loose relationship where I have people that I kind of guide and direct, but I'm not anyone's boss. So that's where the whole humbling thing comes in there because you can't yell at someone or demand someone do something. It's open source related, especially when they're not getting paid for it and they have no stake in it. So, you know, it's an interesting dynamic, but if I were to say in total, the type of manpower that we have is maybe three devs total across the entire ecosystem. And when I say total, I mean, we have like six or seven, but the ability to contribute kind of wax and wanes over the years. So sometimes people contribute more and sometimes others can't. So on average, it's about three developers. And your last part you mentioned about what we took from the open source community as far as contributions, definitely towards the latter part of beta, taking a lot more contributions. Earlier on is difficult because in a lot of cases, we hadn't even determined the process that we wanted to do for something. You know, like we create, like whenever you're creating variables and everyone says it's like the hardest thing to do is name them, right? So we kind of have to do this on a, you know, with functions and properties and concepts and stuff. We kind of have to sit down and come up with them ourselves. So a lot of times we can't accept help on something that we're not even sure what the final... product is gonna be. And there are ways to make that easier, right? You know, with RFCs and whatnot, but we don't have the resources to be able to, if we did stuff like that right, you know, we would have never been done with version three because of how massive it is. It's like 150,000 lines of code, all brand new. So, yeah. Now that we've released, you know, we're definitely taking a lot, we have lots of pull requests and we're taking a lot more people in, but. up until the past, let's say, month or so that was pretty sparse.

 

Right, yeah, it's hard to contribute when you don't know what you're contributing or how you're

 

Yeah.

 

gonna contribute or have a

 

Mm-hmm.

 

roadmap

 

Mm-hmm.

 

or something for sure, for sure. Yeah, you mentioned the part about naming variables and the old adage I fall back to is the two hardest things in computer science are cache invalidation, naming things and off by one errors.

 

Mm-hmm. Hehehe.

 

So yeah, that's for sure. So what you're saying is basically once you had definition and once you knew where you were going, then that's when people started to jump in and contribute more.

 

Yeah, most of the time especially during the version 3 most the people that were consistent contributors we had kind of established that from our community first. You know, we were working with these people directly. It wasn't a whole lot of people that just kind of saw the framework, wanted to contribute, and then just started writing some code. We've done a pretty good job of directing people on how to be part of that. And most of the time when people did contribute, it's because we were kind of working with them one-on-one. And then after we kind of established that, okay, this is what variance is going to be, and these are the names that we're going to use, and this is the process. And even though we haven't written a contribution guide, we can still teach people about that that are wanting to help. And then kind of as that baseline of knowledge has been disseminated to people in the server, other people see that and they kind of start working on it. We're in the process of putting together an actual guide that shows people the best ways to contribute for version 3. But yeah, most of it has started specifically like in the community.

 

I think the correct term for that is hurting cats, unless I'm mistaken. Right. So... From a technical standpoint, there was the questions that Eric had asked you. I'm curious to see about the testing. You talked about how you implemented Cypress. So Cypress is similar to Dusk, which is what I use on a day-to-day basis, sort of your end-to-end browser type testing. Did you not have that type of testing in place previously to 3.0 or you did, but it was just different or what testing did you have in place?

 

So we always had spec testing, which covered about 90% of the framework. For a period of time, experimented with Storybook. And I can't remember if that was going to be the basis for E2E testing in version 2. But when that came to be, it was around the time of starting to move resources over to version 3. But we had always intended and wanted to do Cypress. It became easier with version three, I believe with the correlation of view and how we implement it. But most of that was kind of spearheaded by Albert. He, I think he was working with a lot of unit tests at his work and he's been kind of. the head guy in that area and then Kale from a technical standpoint setting up all of the ins and outs. But up until version 3 it's been all spec testing which has led to some definitely interesting regressions and we've noticed so far that it's been very helpful, it's been very useful and it definitely makes it a little more safe for us to make changes and not worry about, you know, if we do make a regression then now we can cover it visually instead of... you know, just with something that's sitting on jest.

 

Yeah, yeah, for sure. So just to clarify, it's more of your unit testing, code testing behind the scenes,

 

Mm-hmm.

 

just from running code functions themselves versus browser testing where you can actually see what's going on when it clicks and hits

 

Correct.

 

buttons and submits forms and all that kind of stuff. Yeah, they're two very different things and they're complimentary for sure.

 

So like if you had, a good example would be, we have an elevation composition function and its whole job is that you provide it with an elevation and then it provides you back with a class. That's its whole job. So we would just unit test or create a just specification test for that. It has an input and a. expected output. And then a component like vCard that maybe implements that and has a hover prop that whenever you hover over it, it changes the elevation from one thing to another. That's the E2E test to make sure that it looks the way that it's supposed to look and then the composition function we already expect to work because of its specification test.

 

Exactly.

 

Yeah, I think that things have just changed a lot in the last three or four years since Vutify 2. I think the whole and everybody's moved over to TypeScript. I think it's definitely standard everywhere,

 

Mm-hmm.

 

has been for a little bit. And then Cyprus has become more and more popular. So I think those were great additions to Vutify 3, just in the building standpoint.

 

Mm-hmm.

 

Maybe I'm jumping the gun here, but I the process from going from like view 2 to view 3, I know, or excuse me, viewtify 2 to viewtify 3 and also going major version bump from view 2 to view 3.

 

Mm-hmm.

 

There was definitely some things that you guys couldn't get into to viewtify 3. Can you talk a little bit about that and some of the decisions of some of those more complicated components that I think I hear that are going to be in 3.1 viewtify and that you're holding off on the 3.0 release that you just did?

 

So, sure, so I'll touch on that. Well, to kind of touch on the last point first, some of the larger components like data tables and calendars are gonna be moving to, we're creating a new process called labs. And the idea is that, you know, primarily right now it will be for large components from version two to version three. But in... In essence, what it's meant to be is that we have this large piece of functionality. This component is extremely complex or has this lot of functionality and we have to cover a lot of areas. But this component is in a state that can be used, but it's not in a state that's 100% feature parity with the previous version. So that's something that we're doing aside from version 3.1 to hopefully get fingers crossed. But like this year... some components in the labs where people can use those components now because they're in a state of being able to be used but not to where we've released it as part of the core framework.

 

So is labs like another package, or

 

Well,

 

is

 

it'll

 

it a

 

be

 

part

 

another

 

of the?

 

package inside of Vutify. So

 

Okay.

 

you would have your imports from Vutify. And then if you had, we're still kind of working out all of the specific details, but let's just say data table, you would be able to, once we have it released, you would be able to pull the data table from the labs and it would be a separate implemented package that you would add into Vutify that you would be able to use these before they were considered 100% feature parity with version two. All right, so that was the, so, and then, So that was kind of like addressing the tail end of your question. But as far as how we determine features and releases and pushing things back. So unfortunately, open source is very hectic in terms of the people's ability to contribute and the sustained income that comes from it. So a lot of times what I'm having to do changes quite a bit. And when that occurs, and we have weekly team meetings, would always get together and try to assess. We have a list of everything that's being converted to version three. So we would get together and determine, okay, one of the big things for components to be developed is having a champion, right? So when we have a developer that maybe primarily works in let's just say the date picker, right? We're kind of always, we're all working on it. But the idea is that they're the primary person behind it that drives its development. And the ability for people to contribute the amount would kind of make us have to adjust the, you know, the release of a potential component being or not being in the release. About, I don't know, I think at the end of last year, and then we did it again once about four months ago. kind of sat down and had to reevaluate, or had to evaluate, okay, which components are left? Of those components, which components are we considered, I'll just say complex for lack of a better word. And, you know, of those complex ones, do they have a champion? Do they have someone that is primarily working behind it? Because, you know, there are so many things in the ecosystem that if somebody's not working on data table, yes, I could stop and completely work 100% on data table, but then that blocks another flow. And then that's kind of the way that we've approached it up until this point of saying, okay, which components are too much to get completed before this X and Y time and or is the component and Not a super popular component, you know, we look at statistics and look at data of like, okay skeleton loader got pushed, right? it's a component that a lot of people use but it's one of the least popular ones, we weren't completely decided on the new interface that we wanted to use for it, so it got pushed. Whereas something like Calendar got pushed because the person that originally developed Calendar disappeared. So it can kind of vary depending upon, but typically it's just based upon one of those two factors. Now moving forward with version 3.1. I actually did update the roadmaps on both the current and the next documentation today to accurately kind of reflect what's going on. There were about 48 tasks in version 3.1 milestone and as it stands right now, everything that's in that is intended to either be there or be part of, when I say this labs, labs is just a, it'll be just a separate package in the repository, but it'll, instead of it all the consumption by the user is done from a different package. So that way, whenever we do eventually release these components and put them onto the main package, it's going to be a much smoother transition.

 

Yeah, and I just want to say, and thank you for that explanation, that would you say 99% of all, or 95% of the components in Vutify 2 are in Vutify 3? It's just a few, like three or four really larger components. Is that accurate statement?

 

Yeah, I'd say the biggest ones that people most care about that are not in version 3 release were data tables, date picker, time picker, calendar, maybe even in that order. And the, but the good thing is, is that two of those are pretty much almost done. And the third one is, well, data table had some complications because we spent a while trying to figure out the structure we were going to use to be able to support. fixed vertical and horizontal scrolling, which kind of put the back. And then also the only person that was working on it was the person that was also doing a whole bunch of other stuff, Albert. So it's one of those large ones. But there are some other small things that we haven't added. Like I said, skeleton loader. And if that happens, it's usually because of, like I said, either we haven't come to terms on an interface or we don't have someone then get behind it. But. Everything that most people are going to need to use in an application, minus data tables, is in version 3. And we have a lot more components and things that are ready that are going to come out, you know, in version 3.1. They just weren't finished or they didn't make the cutoff. Like they may have even been finished before 3.0 released, but they didn't make the cutoff to go in it so that we didn't have to account for it. Does that make sense?

 

So, okay, so I'm looking at the documentation pages right now and I'm comparing the 2.6 version with the, the only thing I see available in the dropdown is 3.1 alpha. And there's a lot of things I don't see listed in the 3.1 alpha docs that are in the viewpoint two. Is that just because documentation's not up to date?

 

You'd have

 

I mean.

 

to let me see where that's at. Are you on nextfutifyjs.com or just futifyjs.com?

 

Next at butafyjs.com

 

Okay, so yeah, so the next documentation does have a few things that are, is missing some things from the regular documentation.

 

Okay.

 

It's currently in the process of being updated. The, for the most part, all the content is there, but there are some things like that drop down that weren't put back in yet. That was probably just... forgot about it or missed it. I know it was implemented originally because we didn't have menus complete at the time. And

 

Ha ha

 

I guess

 

ha.

 

I would just say go back there and add it yet.

 

Okay, so just to clarify, the next.butyfijs is the correct place to go for the 3.x

 

Yes.

 

documentation.

 

And if you go to the main site, it has a big banner at the top that says, hey, if you want to check out the new version, and you can click on a button.

 

Oh yeah, start exploring beautify 3.

 

Yeah, and this has been a long time coming in. Would you say, I know technically when Vutify before it did the major release bump, and it was in beta or alpha status,

 

Mm-hmm.

 

there were companies using it in production, correct? Even though technically you weren't recommending it at the time, as of now you are recommending it to use in production. So it's

 

Mm-hmm.

 

had a lot of use in wear and tear.

 

Yeah, it's had quite a bit. Yes, we will always say don't use alpha software in production because that's what you're supposed to say, but people are going to do what they're

 

Hahaha.

 

going to

 

Hahaha

 

do. And I was building applications with it as well. And I'd say that from my point of view, it has been very well received in terms of just working right out of the box and people being competent of having it in a production environment. Things like the Vutify store. are running on the new version, right? So we had some skin in the game. So if it's not working right, it's breaking, you know? So, but yeah, we've worked with plenty of companies that have already implemented or started to implement version three in some capacity, and it's been great results all around.

 

I think the term there is you're eating your own dog food, correct?

 

Yeah.

 

To borrow from Microsoft? Yes.

 

Yeah, and you guys have been offering just forever like business enterprise support as like paid options.

 

Kind of. We've only recently, so the enterprise is something that I have up there now, something I implemented after my trip to Toronto because people were basically saying, because we had the ability, well it was always been up there, the ability to schedule support. But everyone was saying that it's not obvious where to find it. So actually what is up there now under the enterprise new is something that we put together. as just more direct like, hey, you can get support from us, which is the logical step forward to maintain some sort of revenue income. And we're really excited about, it's more than just we have regular support, we have a couple different things we've been putting into place like different application review processes and stuff like that so we can work with companies to get them the best out of their application. But... Yes, we've had support in some capacity, but it's never really been, honestly never been really utilized that much. So we just always had to do a better job of getting in front of the people. That's kind of my fault. I'm a reluctant, I've always been really reluctant to get into those particular avenues of income because I always made it, I always felt like people would think that, well, this is not at the heart or essence of open source. But I figure after five, six years, Butify is done. done good to the world, so we're going to try to see if we can increase our capabilities with getting some higher incomes and whatnot.

 

Well, you got to make money somehow. To me, that seems the logical avenues to provide paid support, you know?

 

Now.

 

And if anything, I mean, enterprises, I mean, it's a bane of the open source community and it's commented on frequently that you'll get large. corporations, large businesses who using

 

Mm-hmm.

 

open source and making tons of money and they don't contribute anything back. They don't donate, they don't do anything, they don't donate development time. And

 

Mm-hmm.

 

there are some that do, but to me, it seems logical that hey, there's a great way to get some money back to support what you're doing is provide

 

Mm-hmm.

 

that level of enterprise support, pays for itself basically.

 

That's the way we look at it. It's like protecting your investment, right? So if your business depends on Vutify, then it would make sense for you to ensure that Vutify has the resources to be maintained.

 

So that kind of leads me to the next question then. So we know that view two is, I think it's fair to say, I think they've announced it's going away eventually. It's gonna be

 

Yeah.

 

sunset. And does that mean then viewtify two will be lockstep with view two and how will that work for long term support? And are you encouraging everybody to upgrade from viewtify? Well, obviously if they go to view three, they have to.

 

Mm-hmm.

 

What's your thoughts on all that?

 

Well, I think it may not always be the case, but in terms of Vue 2.0 sunsetting, we'll probably be somewhat in lockstep. Our current process is looking towards 3.1 and quarter one of next year, and then once we release 3.1, we would spend a development cycle preparing 2.7 for long-term support. And now I don't know what Vue offers in terms of long-term support. I know that we're gonna do... between 18 to 24 months I think with version 2.7. And there's definitely some companies or businesses where upgrading really isn't gonna be an option and not necessarily even because of Udify because there's just a process for upgrading to Vue 3 in general, which really kind of makes that a larger hurdle. Version 2.6 and ultimately version 2.7 is a solid piece of software. I mean, you could get, it would be useful with no more support. for years to come if you really wanted to. It's been tried and true. So I do imagine that after 2.7 though, we will definitely continue obviously our long-term support, but the idea is hopefully that we'll have enough resources to where I can have someone dedicated on it and not have to take all of mine or all of Kale's time. But I think that, yeah, I think that's what we're looking for right now.

 

Yeah, I'm assuming, like I think the ecosystem in general, I think it's been speeding up and more people are upgrading to view three all the time, but I would assume that there's just still the majority or maybe a slight minority. People are still using view to fight to still using view two. They haven't upgraded yet.

 

Mm-hmm.

 

I know, yeah, that's the case at my, you know, for my day job, we have a huge, huge view app, you know, hundreds of components and upgrading to view three is going to be no small task. Now it will be easier. with the Vue 2.7 release in that you can implement Composition API and some

 

Mm-hmm.

 

of the other Vue 3 features while you're still on two, and therefore, when you do throw the switch and go to three, then it's gonna be a much smaller task. So

 

Mm-hmm.

 

my guess is that's why they did that in 2.7. But... But yeah, it's true with any big release like this, any CMS, any system that when you have things, version that's been around for so long, there's so much built with it

 

Mm-hmm.

 

that it's gonna take time to get everything upgraded. And you can't really, it's difficult from the open source perspective to say, okay, no more LTS, that one's not supported anymore.

 

Mm-hmm.

 

And everybody's still on it. They're going, what about this?

 

Yeah.

 

Maybe you just do bug fixes and stuff like that. You're certainly not gonna enhance an older version anymore,

 

Mm-hmm.

 

right? But maybe just enough for bug fixes as needed.

 

Mm-hmm. I think most I think they're the only things that are getting backported to version 2 Anything are for version 3 are gonna probably be simplistic implementations. Maybe classes and whatnot You know class changes we for example, we changed classes in version 3 So in version 2 6 we kind of stopped gap that and and made some conversions to where people we have an ESLint plugin that Makes upgrading a lot easier than without and we're it kind of automatically goes in there and takes the different names or different names of classes and converts them for you. We did this for version 2.6, we're doing it for version 3. And you know, hoping that it will alleviate some of that pain because large applications definitely can be, it can be very cumbersome trying to upgrade. And that's another reason why we have the support. at least open up that aspect because you know I've been working in this, Kale's been working in this so deep for so long we're very comfortable in knowing how things have to be, how to upgrade different aspects of an application from view 2 to view 3. Done probably 50 applications so far. So yeah it's definitely a process and we're constantly improving our tooling to try to make that easier. Just depends upon the size of the project.

 

Is there a migration guide on your docs? I'm guessing

 

No,

 

there is somewhere.

 

very,

 

Oh.

 

very small one. Yeah. So this is another one of those things. I, you know, I, we had someone that was helping with, um, writing this guide because it is very massive. Um, and they went in my eye and doesn't mean it still doesn't need to be written. But it's like it's a triage kind of thing. So when you only have so many firefighters, you gotta pick your fires wisely. And while an upgrade guide is obviously important, our stop gap was well, we have this ESLint plugin that gets us most of the way there. Focus the effort on this instead of, you know, it's how many releases we had, how many commits? Like I think 1,100 commits, it's just a lot to go through. Even with automated tooling that we have. So that's kind of what happened with that. That process we do have one that's kind of actively being developed somewhat in our pull request. But again, you know the people that we were working with, you know, got busy or something happened and that's just life.

 

No, that's completely understandable. I mean, it hopefully shouldn't be like with your ESLint plugin. And I mean, if you're upgrading a large app from view 2 to view 3, it's going to be difficult. I think I've never heard someone say, oh, it was simple. But I think you're just going to have to take the time to move things around and figure out.

 

Mm-hmm.

 

how to do it and using that plugin definitely sounds like it would help. And there's a Discord and there's a whole bunch of other... I see your support is pretty long. I'm sure there's other questions people answered

 

Yeah,

 

on

 

we

 

the migration stuff.

 

Discord recently, well not recently, I guess maybe it's six months or so now, introduced threads, kind of like what Slack

 

Yes,

 

has,

 

yes.

 

which has massively improved the ability to help people because you can contain things in a thread. And we definitely have a very, very active community full of people helping with support and whatnot. So that is always going to be there for sure. And for the people that need more, we'll have that as well too. Yeah, upgrading application from version two to version three is going to be a chore no matter what framework you have. So.

 

Yeah, that's the point. Yep.

 

Yeah, side note, you know, you mentioned discords and threads. I have, I'm looking at my discord and I have like 10 different open source communities that I'm in, anything from Astro to Tailwind to Laravel to Inertia, whatever. And one of the interesting things I've seen implemented in there is that when you go into one of the support channels and you create, you know, you ask a question, it creates like a ticket. And everything

 

Hmm.

 

is encapsulated within that ticket. When somebody answers you, it's within that ticket. But you basically have a form at the top. So it's a create ticket, put in a title, put in a description.

 

Mm-hmm.

 

Then it adds it as a separate item that's isolated from the main discussion. So

 

Yeah.

 

that feature is really nice,

 

That's pretty cool.

 

for sure. So with the move to the Composition API, you know, the debate whether that's better or worse always rages on and then, you know, people are coming to accept it for the most part. Did that enable you to do anything easier with Vutify, maybe allow you to add some features or some components that you weren't able to do with the previous structure at all? Or was it just a matter of rewriting Vutify to provide the same functionality with the new underlying paradigm?

 

I'd say about 80-20. So about 80% of it was not one-to-one, but the process of implementation was very similar. Even when we used mixins, things were put together compositionally. The other 20%, though, we were offered some new tooling in Vue that made things possible that weren't possible before. Some things like teleporters. We used to have to manually move elements throughout the DOM. Now view has built-in functionality for that. Another one would be suspense, which

 

Yes.

 

isn't released fully yet. That's still there and we're kind of gated by some SSR issues until that's released. But you know the ability to suspend all elements from rendering until X condition is met and then this is particularly important with our layout system. So that offers some new capabilities. The way that provides and injects happen in version three, which are, which providing inject systems existed in version two, but they were not as prominent as they are. I mean, we even used some of them in version two, but for version three, they're the primary way of communicating information down. That's how we do, we have global properties. We have global layout systems and language systems and all these things are using the default view provide inject system that has been expanded. It's using symbols now. That's enabled a lot of benefits from us. Kale being able to set up the TSX is pretty awesome because it allows us to get some of the I don't actually remember the exact tools that are compiling it now, but there are benefits with the, I think it's maybe the view loader, I forget what it's called, that they optimize in the compiler that you really only get if you use templates. So being able to have better support for TypeScript to allow us to move to something like using regular templates, we've had some benefit there as far as performance goes. And other than that... Some of the caveats for objects and arrays that existed in version 2 for reactivity, we worked around it just fine in version 2, but what it allowed us to do in version 3 is just write things cleaner and more straightforward, avoiding so many odds and end use cases. I'd say those are probably some of the biggest ones that I could speak to.

 

Yeah, just so just to define some things for the uninitiated or those aren't familiar with it, teleport and suspense were a couple of really nice additions to teleport and Claire. Correct me if I'm wrong in this, but it makes it's a very easy way to allow you to move things within the DOM in your component, where if you have, you know, if it's being rendered in the DOM at some particular place and you want to move it up to the header

 

Mm-hmm.

 

for some reason, you know, it's a built in functionality in Vue 3. that allows you to do that. Did I get that right?

 

That's correct.

 

Right. And then suspense, boy, the talk about one of the pains in the rear with U2 is anytime, you know, let's say you're loading a page and it takes time to load, you know, cause it's asynchronous. And so you don't want your user to be wondering what the heck's going on? Why isn't this responding? Hitting click, click. And so you throw up

 

Mm-hmm.

 

a GIF, or is it JIF? I won't get into that debate. You know, of a rotating wheel or something, a busy, something to show that it's busy. And then,

 

Mm-hmm

 

you know, once your data is loaded, then you update a value, a variable, and you get rid of the image. Now, you just basically can have two chunks in a suspense element that says, okay, here's what you do, here's what you show when it's loading, and then here's what you do when it's done.

 

Mm-hmm.

 

So it really simplified some of those boilerplate type of headaches.

 

Yeah, that's, those are, I'm sure as being on the cutting edge and doing this, you're looking for every single API that view three now offers and seeing if it can benefit you and what you're doing, I'm guessing. So all these features are probably pretty helpful.

 

Even ones that are API based on the browser. So we only support evergreen browsers now. There's no more Internet Explorer support, which has also allowed us to do things like support grid and use some of the new

 

Oh.

 

browser APIs that are available. I know we haven't implemented all the ones we wanna use yet, but yeah, the team is constantly looking for what is on the bleeding edge so that that can help us solve. a problem usually something to do with like dates or you know suspense with asynchronous actions but yeah anything that we can get our hands on.

 

So, Viewtify 3 supports all major browsers, like two versions back? Is that right? Or a few versions back?

 

I would want to look at here specifically what Kale put because he's the one that designates a lot of that. Well, I'd like to support these browsers and he figures out the technicalities of it.

 

Ha ha ha.

 

No worries. While you're

 

Yeah,

 

looking at that.

 

but no specifically define, but yeah, Chromium, Firefox, Safari are all supported and then Safari 13.1 does require a polyfill. But other than that.

 

Yeah, it's awesome. All the work you guys have done. It's great to see this out and how far it's come. You guys are still doing amazing updates to it. I did have a question. I know our friends at Nuxt3 came out

 

Mm-hmm.

 

earlier this year. I think a lot of people, at least I just did a video on my channel, on Vutify. Cool, let's see this with Nuxt. What is your relationship with Nuxt? Is VitaFy 3 completely Nuxt compatible? What do you think about that?

 

Well, like I said, I've met the Chopin brothers, and they're great people. And more power to them in their open source framework. I don't use Nuxt. And this kind of goes into the whole limited time aspect. So because I don't use it, I'm not kind of embroidered into that community. In version two, there was a separate community Nuxt plugin that someone else maintained that was separate from us. I can tell you that there are people that use Nuxt with version 3, Nuxt 3 with beautify 3, because I see them talk about it in our Discord channels. But we haven't reached a spot where we are going to release a specific guide or stating one way or the other until we've sat down and we're comfortable as a team for people that are actually using it. Because like I said, I'm not using it so I'm not, I don't even know. I don't even know what Nuxt is for besides SSR stuff. That's how long it's been since I've even delved in it. I know it's important to support Nuxt because a lot of people use it, but the way that we develop everything supports baseline view SSR. So I can't imagine we would have too many issues that would stem past implementation headaches and whatnot.

 

Yeah, I get it. I think, like I remember with with least version two, Nuxt and Vutify went together like peanut butter and jelly, you know, it just

 

I'm

 

worked

 

out.

 

really great and everybody loved it. And I think

 

Thank you. Bye.

 

a lot of people like getting it working with Nuxt 3 and it sounds

 

Hmm.

 

like people are getting it working. But I know it's still really new and you guys are focusing on making sure everything is stable and get the new features out.

 

I mean, once we say, hey, once we put Nuxt on the installation page, then we better be ready to answer questions about it and be able

 

Yeah.

 

to understand that this is a that. So that's also part of the reason for some content that's missing on the new documentation, because there are just a couple unknowns that we're just trying to get to on the stack.

 

So you've mentioned some of the other people that help you on Vutify. I think it should be noticed that if I'm, unless I'm incorrect, it's a sort of a family affair for you because I see Heather Leader as her

 

Yeah.

 

name in the Discord. Correct, now in past, when we've interviewed in the past, I think at the time she was your fiance,

 

Mm-hmm.

 

if I'm wrong. And so now you

 

Potentially.

 

guys,

 

She's my wife now, though.

 

yep, yep. That's right, so what's Heather's role in the Vutify ecosystem?

 

Well, everything behind the scenes. And also everything that I don't end up doing or want to do, she ends up taking. For example, we're going to Amsterdam in February. So she does all of the logistics for setting up planes and hotels and working with the event coordinators to make sure that we are where we're at when they need us to be. everything to do with you know working with we have vendors that sell in our store everything you know I'm in an office and this is actually a new office that I'm in she you know make sure that we have the things to keep moving and she's also started recently doing a lot of the social media and marketing and what not after we've, you know, as we've released version three. But yeah, everything behind the scenes that's not to do with coding, and she does coding too, but if it has to do with the business, she's probably taking care of it.

 

Awesome. It sounds like a... She keeps the wheels turning, huh? Keeps everything greased and moving.

 

She just sends me out there to go find some sponsors or go woo some people. She just kicks me out

 

Hahaha

 

the door. And then I just come home and say, here's what I found. And then she takes it and puts it back into the machine.

 

Awesome. So it looks, I'm looking at the roadmap page and it looks like it might be a little bit behind I'm guessing just because of

 

Well,

 

documentation.

 

unless you're cached, I updated it today.

 

Oh, did you?

 

So.

 

Okay. So I see the Titan target release of Q3 2021.

 

Nope, you're cached.

 

Okay. All right.

 

This

 

Oh,

 

is what

 

here

 

I,

 

we go.

 

I just

 

Refresh.

 

yelled at Kale about this. I was like, Kale, the cache isn't reloading properly.

 

Okay, so What's for those who aren't looking at it? What's coming down the road? From a roadmap standpoint for a 3.0 and 3.1 You'd mentioned getting some of the other things across the line like the data tables and

 

Mm-hmm.

 

the date picker and that kind of stuff So basically sort of getting up to compatibility from a future standpoint with the previous What's after that?

 

So after that, so once we reached version parity with version two, I wanted to have kind of a maintenance cycle that's going to probably occur in the middle of next year. Most of my time is being spent in the documentation right now. Kayla is heading up a lot of the technical aspects of development. So, I'm going to go ahead and start with the documentation. So version 3.1 for us is kind of the 3.1 which is a code name Valkyrie. Let's put all that information up today.

 

Hehehehe.

 

You know, is going to be trying to bring up some more components over to reach future parity. Bug fixes and issues that we found. Even though we have a couple bugs, well I'll tell you, version 2 to version 3 it feels seamless. And just like, it feels so smooth that, you know, it's hard to believe that we don't have... more issues to be honest, we've been expecting fires and it's not been that bad. But you know, the version three one shoot for quarter one of next year to try to have some new, some of the other components ported over. I don't think we're going to have any new components in three one. We may have some, we've may have some new functionality that we're adding. But after that version three two, which I think is middle, middle of next year will be around the time that we released two seven. Nirvana, which is going to be the LTS version for version 2. And I'm hoping that by version 3.2 we will have everything out of Labs by then and be 100% feature parity with version, with the previous version. And then hopefully version 3.0 on will be us adding some new things. We have lots of stuff that we've wanted to do brand new for a while. So once we get caught up to that, you know, on the road for new components and new features and functionality, better development experience, things like that.

 

Awesome. So it sounds like you definitely got enough to keep you busy for a while, eh?

 

Oh man, a couple years at least.

 

Right on, and then 4.0 comes out and well hopefully it won't be huge. Whatever that is, right?

 

There's let me tell you right now, you've heard it here first. So we've rewritten the framework like three times. Like three times since the beginning, we have written it rewritten it from the so I wrote it in 2016. We rewrote it in 2017. We rewrote it in 2018 and 19. And then we just revert version three. It does not happen anymore. So

 

Hahaha

 

I can tell you if anything, I'm hoping that there's no, uh, and I can't see why there would be any large dynamic changes to the way that version three is. recommending people compose things, you know, with composition functions. And since everything is built on that, then we're looking like all the focus will be on improvements as opposed to massive conversions. So even 4.0, we're, it's probably gonna be more focused on developer experience stuff to make it just easier for people. But get into that another time.

 

Hey, Eric, you're muted if you're talking.

 

Oh, I found the mute button. So this semver version of Vutify will always match view. So like view 2, Vutify 2, Vutify 3, Vutify 3.

 

I don't know, yeah I think up until that point, I don't know, you know, not to say that when view 4 comes out that will release view to 5.4, I do not know. But it wouldn't be done intentionally unless for some reason the stars are aligned. So view to 5.2.6 and the way that lined up with view and what not is just more of a coincidence than anything.

 

Ah, okay.

 

So, and the version 3 is just well, obviously it's the version 3 so the major iteration, but yeah everything else is kind of by coincidence.

 

All right, so is there anything else about Beautify 3 that we haven't discussed that you wanted to cover before we wrap up?

 

Well, not before we wrap up, but I will say that there are a ton of new features that we added that make it really address a lot of the other issues, a lot of the issues that people had with the previous versions of customization. Probably one of the most notable everyone to check out is global defaults. You can now configure the entire application from the root nested comp, nested options per component. We have things like component aliasing where you can create your own custom virtual components and then apply defaults to them. And yeah, you can get started really easy. Go to tryvutify.com and it's got instructions to be able to get you right in on version three and right into some of the documentation and things to look out in the new version.

 

Awesome. All right, well, thanks for coming on. Before we get into pics, if people want to follow what you're doing and give you money or see the, hear the pearls of wisdom that drip from your lips like water, what's the best, where's the best places to do that? So, I'm gonna go ahead and start with the first one.

 

My Twitter handle is at zero skills, Z at the beginning, Z at the end. I'm not huge on social media, so the best place to get ahold of me would probably be our Discord server, which is community.vutifyjs.com, and that'll give you an invite link to that. And if you're feeling real froggy, well, my email is john at vutifyjs.com. Feel free to email any questions, comments, concerns, just say hi. And if you're interested in supporting or contributing to the project. We have many avenues for that. If you go onto the main documentation page, you'll be able to see many links where you can click to sponsor the project. And if you want to contribute, I suggest coming onto Discord and reaching out to myself or any other developers. We'd be happy to talk to you.

 

Awesome. All right, with that, we will move to picks. Picks are the part of the show where we get to talk about other things, or we could talk about tech things if we want, movies, books, games, TV, you name it. Today we'll start with Eric. Eric, what do you have for us for picks?

 

Yeah, I'm going to do a little self-promotion. I just started my YouTube channel. Back up again, started making videos. Took a couple months break. So you can find that program with Eric on YouTube or eric.video. Just put that in your browser, that will redirect to my YouTube site. But I'm also really interested in what I'm doing at work too. We're doing some really cool new comp- We're doing some really cool, we're calling them connected components that work with React and Vue and Angular to connect to AWS services. So like we have one now that works with maps. So if you want to add a map to your site, it's really easy. Just pop it on there. So I'm just gonna give that a plug. It's ui.docs.amplify.aws. And you can learn all about that.

 

So just out of your curiosity, mapping is one of those things that I've always read about and never had the time to delve into. What are you using for your mapping infrastructure?

 

It's all on AWS. So

 

So AWS

 

AWS

 

has its own

 

has

 

mapping.

 

a geo service, so you can do all your mapping through us.

 

And so they provide your own layers and all the images and that kind of stuff.

 

Yep, yeah, we have a whole location service that does geofencing and geospatial data and everything. And we have some of that built into our component.

 

Awesome, awesome. Good deal. Yeah, we've talked about that before about all the different view components that they're building that allow you to hook into the ton of AWS services that are out there. So yeah, check it out for sure. If you're a big AWS user. Was that it?

 

Yeah, that's it.

 

Alrighty, so I will go next. For those of you who are regular listeners, you know that I'm sort of a fan of the dad joke. I won't say how good they are, let's just say I put them out there. So first of all, do either of you guys hear about the guy that had the irrational fear of buffets? He just couldn't

 

No.

 

help himself. So, I'm gonna go next. Thank you, thank you. So when I was little, my parents, you know, eat soup like a lot of people do, and my parents always fed me alphabet soup, and they said that I really liked it. But actually, they were just putting words in my mouth. And then finally,

 

Pretty good, Steve.

 

thank you, thank you. What do you call Spider-Man on a climbing wall? Peter Parkour.

 

Thanks.

 

Yes, thank you. Thank you. All right. So with that, John, it is your turn. What do you have for us?

 

I've been spending a lot of time in Figma. I wanted to learn, or I wanted to use an app, something that was easier than Photoshop to quickly develop art assets for Vutify. And I recently kind of dove into it. You could see in the new docs, like if you were looking at the roadmap and those video, or those little pictures at the top, those are all pictures that I've been creating in Figma and I've been also creating the Vutify Figma UI kit. in it to help supplement those images. And I've been having a lot of fun with it. It's been one of my pain points over my career, my inability to be able to design things. So I've been enjoying diving in as of late.

 

That's interesting you mention that because you know I've talked about before how I am the least creative design type person ever and it's the bane of my existence too and just creating simple logos or images or something like that is a skill I haven't had. So you found Figma pretty easy to learn even for a design challenged person.

 

Yeah, it's one of those applications or one of those products where everything just kind of works. Things that you just do that you wouldn't expect. You're just like, oh, I think this should work and it just kind of works and everything just feels really intuitive. And yeah, I've just had a really good experience with it.

 

It's been interesting with all the hubbub around Figma since they got bought for, was it, $20 billion by Adobe? And within the past month or so as of this recording.

 

Mm-hmm.

 

And I know a lot of people are saying, oh man, Adobe's gonna take it over and it's gonna go downhill just like other things Adobe's taking over. So that remains to be seen, but I'm sure for now it's still just as good as it always has been.

 

I can't imagine they'd take features away from it, so hopefully not. But, you know, been wrong before, but for now, it's working out great.

 

Good, good. Yeah, figma, is it figma.com? I can't remember the, if

 

Or

 

you just

 

figma.com.

 

Google it, I'm sure you'll find it. We'll throw

 

Yeah, it's

 

a link

 

figma.com.

 

in this one. Yeah, and we'll check that out. One of those rare five letter domains for sure. So, all right, with that we will wrap it up. Thank you to Eric for coming back and guest hosting with me. It's always nice to have somebody on the panel with me. Thank you to John for coming for the third time to talk about 3.0, no coincidence there. And yeah, we will talk at you next time.

 

Thank you very much, it was nice talking to you all.