John Leider:
So where Vuetify kind of excels in this area is we have such a large API of functionality within the framework, some of our components could be standalone libraries that you get the ability to have this flexible component that covers a lot of different areas.

Noel:
Hello and welcome to Pod Rocket, a web development podcast from LogRocket. I'm Noel, and with me today is John Leider creator, and CEO of Vuetify. Vuetify is a Vue component framework, maybe like the Vue component framework. I feel like it's probably the most well known one. John is joining us to talk today about how it works, whether it sits in the Vue ecosystem, the release of 3.1. Welcome to the show, John.

John Leider:
Thank you. Thank you for having me.

Noel:
Of course, of course. Again, I'm excited. I'm a long time Vuetify user. I remember V1, we were using it internally, a couple of employers ago on some internal dashboards needed a component framework for it. It was super awesome. So I'm very really excited to talk today and I've been using it ever since. But let's set the stage a little bit so people that aren't as tuned into the ecosystem what's going on, kind of know what's going on. Before we even go there, can you tell us a little bit about yourself, career and web dev and how you found yourself writing a Vue component framework?

John Leider:
I started pursuing web development in 2013 when I got out of the military. I started to go to school for it in late 2013 and beginning of 2014, I started actually working for it. Over time, ended up at a company named the Fast Ford Academy. And while I was there is when I ended up developing Vuetify. I had worked with Vue since the Alpha and for the newest versions that were coming out, version two of Vue, I wanted to build some sort of framework that could be reusable. I wasn't a big fan of Bootstrap.
Anyways, I ended up building a small little library that was based off of Materialized CSS and I kind of liked it, but I got to a point to where there was nothing else to convert, so I wanted to make my own. And I started building Vuetify mid 2016 and one of my buddies at work ended up seeing it and convinced me to actually publish it for open source. The rest is kind of history. It took off. I released the first alpha December, 2016 and by October of 2017, I was quitting my job for full-time open source work. And I've been doing that in some capacity for the past six years.

Noel:
Maybe again, to kind of contextualize for people that aren't familiar, what is Vuetify? Maybe even just what is a component framework in these kind of new paradigms of front end libraries?

John Leider:
Sure. So working in Vue, there's a heavy emphasis put on small compartmentalized pieces of functionality known as components. And if Vue were to be the blueprints of a house like the walls and the structure Vuetify where the paint on the walls, where the design art on the wall, we use Vue as a base to build these reusable components that are designed so that you don't have to create your own and maintain their functionality throughout applications. So Vuetify gives you a collection of these predefined components that cover a wide range of use cases when building a monitoring web application. So it's more tailored towards developers in the sense that since Vue is a development platform and you're going to be working in that regardless, Vuetify would be the same. So in that we are basically able to abstract away the necessity for users to have to pre-roll and create new components every single time, whenever they're working in projects and let them focus more about implementing what they're working on.

Noel:
I think that syncs up with my journey as well. I'm a developer but I'm not a designer and I find myself often I want to build something and make it usable and not terrible, but also kind of pretty and nice. So it's like it's awesome when I can go pull a component library off the shelf and it looks pretty good and it can do the thing I needed to do and I can just get it rolling without needing to worry about spacing and mobile behavior and all this stuff. And it's been a huge saving grace. Can you tell me about what kind of drew you to material? Why did you choose material and then was there anything in particular that you think put you in a good position to be designing these super agnostic components that would work for a whole smattering of front ends?

John Leider:
Well, I gravitated to material because it was one of the few design systems that had, well, compared to everything else, very well-defined concepts and implementation for the components. So I had this specification that I could follow and I didn't have to consider why it looked that way, just that it looked that way. And at least now with version three, it more so serves as our baseline because we've really improved the ability to customize and implement your own design system. But material was just a really good baseline.
It had some examples already out and the one at the time that was out with the material kind of design didn't match it exactly. And those things kind of bug me. So that's why I have an intent. That's why I ended up saying, "Well, I'll do something that's my own so that I can be OCD or over analytical on it myself," which ends up, I think, producing a better product. So once material was implemented, that was for the most part the guiding direction for the first couple years of the framework until we started to arrange things to offer design options outside of the material.

Noel:
And as you said, there is customizability now, but even in those earlier days, were there ever times when you were trying to implement a component or something where you, I don't know, kind of butted up against the spec? Something didn't seem to be working quite like you wanted it to or was it always pretty easy to adhere to what was specified?

John Leider:
So for the most part, and I would say that there was enough information, especially in the version two of the material specification, I knew that they're on version three now. I believe it's still largely in beta, but at the time, version one had a pretty substantial amount of specific unit specifications for border radius or shadow and whatnot, and very few you had to fill in the blanks. Most of that came in the way of dialogues and cards, which share a lot of the same styling. But the implementation in the framework or in the material design spec called for a much different style dialogue, which didn't really make sense.
And so there's a couple things that we kind of made executive decisions on. "Hey, we don't agree with this or we're not going to implement it this way." Sometimes it could be a technical limitation, which early on the outlined class was, or me the outlined style for the inputs, it was something later on that we figured out how to do not so much of a janky way because there's a special animation for having to label transition into the middle of the outline. So that takes a little bit of effort.

Noel:
Can we talk a little bit about responsiveness and mobile? I feel like especially with Vuetify, I've always been very impressed by, I would just always do my dev work on my desktop and then I put it into mobile mode and "Everything basically works." I feel like it was kind of my first web dev experience where I had that. How did you achieve that and was that something you had to think about pretty proactively?

John Leider:
Well, it's definitely been a proactive effort for the team to improve not only the mobile functionality of the application, but also the accessibility portion of it as well. It's something that we had a very long time to hammer home in version two, and it's definitely an area that the team is excited about expanding in version three in regards to translations and whatnot. For the mobile first, we have a lot of improvements that make it easier to support different screen sizes.
There's a whole new menuing system, an overlay system for positioning elements and even new layout systems that out of the box means that when you put it on the code and the editor, it's just going to work. And that's my kind of approach on things is I like things to whenever you use them, they're simple but flexible where you can either use the components in a way that we just say, "Hey, here's some default properties that you can set it up and just do the default look." Or doing things advanced where we say, "Okay, you don't like the way that we do something. Well, here are the individual components and functionality that we use to build this and you can make your own."

Noel:
I think that that kind of transitions us a little bit into comparing to other component frameworks, especially ones that kind of focused on that responsiveness early. You mentioned Bootstrap before when you were talking about what inspired you, in your head, how does Vuetify position itself against those other frameworks like materialized, bootstrapped?

John Leider:
So for me, I've always had a knack for being able to spot things that seem out of line or off centered and it would present itself as like, just kind of bug me. I'd be staring at it, I'd be like, "That feels bad," or something along those lines. And in comparison with some of the other frameworks. So we got to Vue three late, but now that we're here, there's only two or three that have actually been ported over to version three. I know that there's a Vue Bootstrap or Bootstrap Vue that's an implementation of Bootstrap with Vue components, but there's only three or four that I believe are on version three. So that's kind of fragmented the market a little bit in which has, I honestly think promoted a lot of people to move towards strictly CSS based frameworks like Tailwind because the community was kind of fragmented and then also it was injured by the introduction of Vite, which is amazing, but killed kind of a multi-year evolution of UCLI and the ecosystem behind that.
So I think that maintaining my own framework as opposed to using someone else's has really always been stemmed from just annoyance of seeing things that are not correct and wanting them to really be fine-tuned and easy to use. I don't consider myself a really great developer, more of a worker bee, especially when it comes to some of the advanced concepts in version three. We have some really smart developers on the team, but I'd like to think that since the way I approach things is often very bullheaded and blunt object and not really always following the intended steps of things. I believe it is been kind of the advantage of me to create something that when you're working with it, it just feels good. And I think that even what you said earlier with how easy it was to implement, the idea is just to focus on that aspect and not think about all of the little details that we're able to handle.
And that's probably from the beginning what set me off to wanting to do that. And also everyone likes to do their own thing sometimes. Honestly, it was kind of lucky how Vuetify took, I did not expect it to take off the way that it did. And I think over time that's kind of, yeah, I've been the motivation of seeing the way that other frameworks and things develop because we take ideas from the whole community. We'll go around and try to get an idea of what functionality may be exists in this component for them. Because for the most part, most frameworks are going to have a very solid core collection of components that are the same throughout cards, buttons, everyone's going to have some of these basic inputs, whatnot. So it's moving beyond that when we implement things that are either new in the system or kind of already exist and we're trying to get an idea of what functionality people will use.
And I think that over time as we've ... Well, especially with version three, we're still doing a lot more porting than we are creating new stuff, which I kind of miss doing and getting to. But I guess it's that approach that has always made it more enjoyable for me to proceed with creating Vuetify in such a manner. I'm an impatient person, so I always like to do things in a hurry. And when you're working with a lot of people, sometimes at open source, it can be very slow. Even from us, which is difficult just because we have so many users on GitHub especially.

Noel:
Yeah, you mentioned the ... I don't know, some friction that was caused in the upgrade period. I think the ecosystem as a whole, especially with Vue here, the switch to three, I think I felt that as well. There was a period where I was like, "I want to be using V3," but Vuetify wasn't totally there yet and it was hard and I was like, "Oh man, I really want to do this. Do I use the old version? Do I look for something else?" So I think there was a lot of people that kind of felt that pain. Do you think that there could have been more done on the Vue core side and the design, the APIs there to make it easier for these big libraries, the component frameworks to adapt? Or do you think the most of the changes in the difficulties caused you were necessary?

John Leider:
The move to version three was to convert the way that we built the components. We heavily used the system in Vue two called Mix Ends, which were, for all intents and purposes, kind of like what the composables are now, but they were abstracted in a way where it's very likely you could have naming collisions and you could really never understand totally what was available to a component. So moving to Vue three for a large amount of our mix ends, they did transfer nicely to a composable. They just take a couple couple properties and then they spit out some classes based upon what that input is. So they're treated almost like pure functions. But as we got to some of the more advanced functionality as a new dialogue positioning system where whenever we're opening or animating a dialogue, it traverses from the origin point of the button and has this nice effect of expanding out.
And as we had to port some of this functionality over even some of the existing, it took a lot of trial and error to get to a point that was what felt like a really good development stack. I think early on, another thing that really hurt our conversion over to Vue three was there were some aspects of the Vuetify framework where we utilized some Vue internals. And in addition to that, while most frameworks were built using a combination of template script and style and some would shape or form, Vuetify used render functions for everything, which was a completely different approach to developing because you had no kind of visual template, everything was done via functions.
So in that way it was nice in some regards to port over functionality, but in the end we had to do a lot of R and D and it took us down a path where we finally discovered or were able to properly implement TSX, which really cleaned up the templates for us because writing the components and using our render function approach and version two was it felt difficult and it felt like it would be difficult to get people to be able to contribute due to the complexity behind it. So once we moved into TSX, it really started to come together for us in terms of how we were going to construct the components. And TSX was really great for, while there were some different syntaxes that users would have to get used to, it was much more readable.
So we had more power than the regular template because we were able to have type safety inside the file and whatnot, able to provide declarations for slots so that you get IntelliSense for what's available whenever you're using the component. So a lot of this was one of the big changing points for us in our development cycle, but what really ended up hindering us the most was just the overall effect of COVID on Vuetify was primarily funded from GitHub and Patreon. So when COVID hit and things started to get kind of bad, obviously sponsorships are the first place that companies cut and I had to change what I was working on to make ends meet.
And the development cycle just got really delayed because of that. And we had a lot of developers, we used to have a core team and a contributors team. They weren't necessarily core members, but they were very highly active within their repository and they made lots of changes to help push Vuetify and get a lot of, oftentimes some of the lizard work tasks done like documentation and a lot of mundane tasks kind of lost most of them and ended up sticking with a core set of members who, and open source people's ability to contribute usually waxes and wanes over the years with different cycles of the type of work that they do and different points in their life.
So it was kind of a combination of all of that that really put us so far behind on getting this implementation out for users. And what I mean by that is the developers who are working with Vuetify, being able to actually read and understand our codes so they can contribute back because we just haven't had a lot of manpower resources and it's really hard to find a good contributor and keep them. Either I'm really bad at it or it is genuinely hard because the nature of what it is, and I totally get it.
I hold no ill will for people that want to contribute on a consistent basis but end up not being able to complete their commitments, which is totally fine, but what ends up happening is we'll have something like the upgrade guide from version two six to version 3.0 get basically halted because the person who was working on it just wasn't able to contribute anymore. So those are some unfortunates that have ended up because of the ability to get the proper vacuum behind the framework. But we're picking up, I think we're doing good. We're going to have the version three docs as the main very soon. Been working a lot on our API generator. I think one of the biggest reasons that we're able to get so much done for the small team we have is how much we have automated and how much we have that's just automatically generated to create all of our API pages automatically.
But yeah, it's been a long road, but now that we're in version three, we're moving forward pretty good and we've conquered most of the really hard issues as far as functionality in version three. Now a lot of it is just now implementing that into ... we have some components that haven't been reported from version two and they still need to be reported over. But then also using this process that we finally have defined out, it's hard whenever you're going to release the next major version because it's like the last opportunity you have to make these big breaking changes and you don't want to come into it where you miss a property that was supposed to be combined and it wasn't, or this functionality that was supposed to exist on this component that didn't make it properly.

Noel:
I'm sorry to hear that. And it sucks that you guys had to deal with those logistical challenges, but at least I didn't and I hope no one else was holding it against anyone. I feel like everyone knows there's a big major change, the underlying framework that, especially a project that this ... well, with the scope of Vuetify, I think there's a lot of empathy out there. So I was just happy to see it, three come out and be in a good usable state. I want to get into 3.1 and kind of what's happening now and what's on the horizon. But before we do that, maybe just to entice devs a little more who have never really used it, can we talk a little bit about what using Vuetify is like? We've talked a little bit about [inaudible 00:21:25] components just like buttons and topples and cards, but how is interfacing with them as a developer and what other kind of functionality can Vuetify provide?

John Leider:
Vuetify is going to provide you with everything that you need to create a web application using Vue. Now this application doesn't necessarily have to be for the web. You can work with multiple different platforms for generating Vue and mobile and et cetera and so forth. Ideally, what Vuetify is going to do is if you have this idea that you're trying to work on and maybe you're good at getting data or maybe you're good at creating UI layouts and whatnot, what Vuetify is going to do is kind of step in between the application logic and the application design and mirror those with ... every application's going to have a button, but what features and functionality does that button have? Because if it can be styled to match any design system, well, then not only do you get to easily have something that looks unique, but it also comes with all this extra functionality that maybe you wouldn't have even had if you built it in house on top of providing you this complete structure.
And not only that, but the information, we have lots of guides, but I'd like to think pretty good documentation for explaining users how to get in and work with this really easy small steps. One of the ways that we like to separate ourselves from other libraries is every component should be functional with no configuration settings. So being able to easily put a data table up or put a date picker up when you don't have any values, you don't know what colors you want or anything else with no configuration options and just working, which basically makes it easier for you to implement things like small prototypes with applications where you maybe need some functionality. That is one of the big reasons ... For example, not to tangent off here, but one of the big reasons why I started Vuetify was I was having issues implementing application layout level components in Bootstrap.
I got application bar with an navigation drawer and working together and I just wanted these two to work together and know that either the drawer was closed or was open without having to control of these weird data properties and all this extra kind of code jumble that you have to write in some of these CSS frameworks to get basic functionality. So where we try to excel in is, "Okay, we take these core concepts that have been built into Vue, which is a popular," you've got as far as I know that some of the top three biggest is React, Angular and Vue. So you've had this really strong core framework in Vue that gives you this very well-defined path for developing applications. And we just kind of slide in as just an overlay of that, not trying to change the concepts that the user use.
You would interact with our components the exact same way in terms of concept conceptually with props and models like you're taught in the Vue docs, you'll operate in the same manner in Vuetify. So it always feels like this natural usage. And as a developer, when you're putting together application or even someone who's not a very experienced developer, one of the first things you're going to probably do is if you're in the Vue ecosystem, you're probably going to be looking for something that's going to help you put together things faster. You're going to get plug-ins for the router and for the store state. So chances are you're going to be looking for some sort of design system to implement and you are going to wind up somewhere where components are implemented in Vue where you can then just put them in your template performance configuration options and move along.
So Vuetify kind of excels in this area is we have such a large API of functionality within the framework. Some of our components could be standalone libraries that you get the ability to have this flexible component that covers a lot of different areas and you don't have to worry about, "Okay, I have ... Button is available in six or seven different ways and all these different variants and with Borders and without." And it's like all this stuff is built in with Vuetify, so you don't have to think about it. You can just essentially configure how you want it to operate and then you implement it as your own design system.

Noel:
Yeah, that's very well put. I don't feel like that's a tangent at all because I do think that Vuetify is layout and wire framing system is a secret sauce in there that is very, very helpful beyond what a lot of other component libraries give you out of the box where just like you said, I can use Bootstrap whatever and build all this stuff, but then as soon as I want everything to change a little bit, when a user clicks the hamburger icon, the nav bar slides out, it's just like, "I've got to do all this work again to make sure everything works." But having that concern be handled by the component library is just empowering as a dev, working on different device sizes and all that stuff, I think is really, really powerful.

John Leider:
Yeah. That was always one of the main focuses early on was layout stuff and version two, we only really had one layout configurable, but now in version three, our new system, you can have them nested as far as you want. You can have a small little defined width and height area of your application that has application level components inside of it that just works. So it's even more powerful now. It's one of the more awesome parts of the framework because before, in version two, we would have some of these arbitrary props, which would tell you that maybe an application toolbar that goes to the top of your screen, sat outside or excuse me, on the right side of the navigation drawer on one side, whereas on maybe the other side, instead of it coming up next to the navigation drawer, it sits above it. And we would have these props to kind of say, "Okay, this is the general structure of the application to help me get set up."
But now we have it where it's registration order. So if you want to have an application bar sitting over a navigation drawer, you just order it. You would normally within the template and then it just pops up that way. And then we do have some properties to allow you to fine tune that if you need to do something special and change locations dynamically. But the whole thing is in mind is it's always just you write very little to see a lot of things happening, and then you get to have this massive configuration. And we really just try to focus on concise language, very semantic language. And that's another thing we've really done well in version three, kind of compressing some of these properties into that are multiple into one exclusive.
We had all these different variants in version two, but now we actually have a variant system, which is an elevated button or a flat or a tonal or an outline. And then this concept is then implemented on all other components that share that same kind of base functionality. Usually, I call it sheets of paper. So you've got cards and buttons and sheets and drawers, and these are all within the material design spec pieces of paper essentially. And that's why also all of these contain the same general functionality because it's built off these little tiny pieces that we put together to make this overall fully featured component that you get to implement.

Noel:
Yeah, so we're talking about new features a little bit here. What's new in 3.1, what's kind of just come out? What should the devs that are already familiar maybe, but they haven't seen the newest version, what should they check out first?

John Leider:
So one of the things that we were most missing in version three was data tables. It's a very large component to accommodate some of the features and functionalities that were highly requested in version two, such as virtual scrolling and more advanced grouping mechanics. The data table itself ended up getting split into three different implementations of data table for server related or virtual scroll related. And I forget the other one off the top of my head, but there was enough unique about Data Table to have these functionalities in their own individual component. But some of the things that we would implement on server side are very contradictory to some things that we would maybe do on virtual scroll. So it makes him difficult to implement them in the same component. So we found ourselves in a lot of if else and all these different comparisons to try to see which one we should display.
Right, okay. So what this did is it kind of took a component that is already complex and then we had to implement it multiple different ways. So long story short, this massive abstraction pushed it out of the development window of releasing fully featured parody with version two when we launched version three. The idea was we would create this new, I call it a new development channel. It's called Labs. And what it is, it's something that we introduced in 3.1 because it's technically a feature and what Labs is, it's a channel for us to let users utilize components that we deem accessible in Labs, but access them in a pre-production state where it doesn't have the one-to-one feature set of version two, which we are requiring before the release. So if the features and functionality in the data table as it exists right now probably cover vast majority of user use cases.
So even if data table doesn't have this new grouping mechanism that we are working on, most users may not really need that. So we've released data table and virtual scroller as part of the 3.1 general release where we had bug fixes and some regular features. But those two are now in Labs channel. And we have a couple that are on the horizon like calendar, which is another big component where most of the functionality is there. It's maybe 85, 90%, but it gives the users not only the ability ... well, we get some really good feedback actually, because a lot more people are messing around with it. And it allows us to maintain these in a way that doesn't break semantic versioning because your packages and components are imported from an entirely different path.
That's a big thing in three working towards version 3.2, we have some new features and functionality in regards to the defaults system. So we're exposing the ability for you to hook into our global defaults so that now you can create your own custom component and you can using it whatever its name is, define that in the Vuetify defaults configuration option, and then configure and define your props inside of our defaults function exposed. And then you can hook in and tap into the same functionality that we use to give Vuetify components default value. So that's one of the big things coming up in version 3.2.

Noel:
Nice. Awesome. If I can rewind us a little bit to the Labs, the components that are in Labs, I'm curious, would you say those are production ready? If a user has everything that they would need for their calendar or whatever is already implemented, would you advise against users using that in production esque apps? Or do you think that the interfaces are stable enough where it should be fine?

John Leider:
We always say that it's not production ready because you really should always treat Alpha Software in that manner. What I would like to say is one of the developers Vuetify is that the currently implemented functionality is pretty solid, especially if you're running a admin dashboard of sort that is maybe less user facing. So yeah, I'd vouch for the implemented functionality that I'm pretty confident that it is operating in line with how it did. I actually personally manually converted every version 2.6 data table example to diversion three, and it was not very much. And going through and utilizing what was there felt very solid. But it's an Alpha channel. It's because we're just not a hundred percent sure. We always recommend do not use Alpha software in production, but if we're giving it to users to use, it's because we're convinced that the quality level is we're looking to get tangible feedback. We're not trying to put something that's in the beginning of development stages into this channel.

Noel:
I think confident, but cautionary is [inaudible 00:34:17] place to be there. Is there anything else kind of on the horizon that you're excited about or want to share and point devs to more generally?

John Leider:
I'm really excited. One of the components that's going to be coming to Lab soon is the infinite scroller. So I thought it would always be cool to have a virtual scroller and an infinite scroller because those two could technically work hand in hand. So we're having that and I'm kind of excited to experience it. The calendar is coming along really great, and I'm really excited for users to see how they can interact with them. Honestly, I'm just excited to get the rest of the, we do have some components that still need to be poured over that are definitely core and Vuetify as a whole is lacking without them.
But that's our biggest focus this year is now that we have this, what we feel very strong foundation Vuetify built on, these design philosophies and concepts are strong enough to where once we have the resources and a person or someone who's able to start porting particular functionality over, that it's going to be something that we can actually do as opposed to we have to still continue to develop new processes for handling different functionality, if that makes sense. So the core stuff is really there. Now it's just making sure that we're figuring out how to utilize it to have these port components over to version three.

Noel:
Well, if there's anybody listening and they want to get involved and help support the project, how would you ask that they do so? Where do you guys need help the most?

John Leider:
So the biggest help is always going to be contributing to the documentation. It's a Herculean task to maintain all the information that we have. Beyond that, getting in contact with us on Discord or even GitHub with issues is always going to be the best way to contribute with your time. If you have more money than you have time, we have a couple different ways that you can sponsor and support the project. The way that I typically point people is to GitHub, because that's where we're hosted at. A lot of companies use GitHub and it's a commonplace. So they have a section of GitHub called GitHub Sponsors, and then we're able to put up information about ... Transparent about what we're making and some of the stuff we're working on, and you can donate there and get some perks for your company and help keep open source project alive.

Noel:
Well, again, if there's anybody listening and you're a dev person and you don't have design channels, you want to build cool stuff and you're struggling with it, I implore you to check out Vuetify if that's not obvious already, I love it. It saved me hundreds of hours of work, I'm sure.

John Leider:
That's awesome. I'm glad to hear that.

Noel:
No, of course. Of course. Yeah. Thank you so much for coming online and chatting with me, John. It's been a pleasure.

John Leider:
Absolutely. Thank you so much for having me. It's been fun to talk about it. I love talking about Vuetify. I think that's really cool that you've used it. Way cool. So that's super awesome. But yeah, thank you for inviting me and I'd love to talk to you again in the future when we have some more stuff coming out.

Noel:
Of course, of course. Thank you so much.