Together with the FormKit author Justin Schroeder, Michael and Alex discuss the challenges of building forms on the internet.
While it seems like a simple task, forms can be complex and pretty time-consuming. Especially when it is more than a Newsletter or Contact Form.
Justin shares his experience building FormKit (multiple times), a form library for Vue.js, and how it can help developers build forms faster and more efficiently. From Accessibility to actually covering edge cases such as form hydration and repopulation!
Of course, we couldn't let Justin go without talking about some of his hot takes from Vue in 2024, over to Vapor Mode, and Tailwind.
Links marked with * are affiliate links. We get a small commission when you register for the service through our link. This helps us to keep the podcast running. We only include affiliate links for services mentioned in the episode or that we use ourselves.
Chapters
Welcome to DejaVue
Guest Introduction
How did you get started in programming and Vue.js?
Frameworks as resource for learning patterns
The biggest reason to change a framework
Which framework would you choose for a new project?
SolidStart as a fresh start for a framework?
Adapting and managing expectations as a maintainer
Why Forms are hard and how does FormKit came up?
Accessibility for complex forms and components
How does FormKit sustain itself?
Physical to digital Forms with AI
Do you have to utilize AI as a Developer?
Justin's Hot Takes 🌶
Vue in 2024
Vapor Mode
Tailwind and headless components
Wrapping up
Together with the FormKit author Justin Schroeder, Michael and Alex discuss the challenges of building forms on the internet.
While it seems like a simple task, forms can be complex and pretty time-consuming. Especially when it is more than a Newsletter or Contact Form.
Justin shares his experience building FormKit (multiple times), a form library for Vue.js, and how it can help developers build forms faster and more efficiently. From Accessibility to actually covering edge cases such as form hydration and repopulation!
Of course, we couldn't let Justin go without talking about some of his hot takes from Vue in 2024, over to Vapor Mode, and Tailwind.
Links marked with * are affiliate links. We get a small commission when you register for the service through our link. This helps us to keep the podcast running. We only include affiliate links for services mentioned in the episode or that we use ourselves.
Creators & Guests
Host
Alexander Lichter
Web Engineering Consultant • Founder • Nuxt team • Speaker
Host
Michael Thiessen
Full-time Vue educator
Guest
Justin Schroeder
FormKit CTO & Open Source Maintainer
Editor
Niki Brandner
Audio Engineer and Video Editor
What is DejaVue?
Welcome to DejaVue, the Vue podcast you didn't know you needed until now! Join Michael Thiessen and Alexander Lichter on a thrilling journey through the world of Vue and Nuxt.
Get ready for weekly episodes packed with insights, updates, and deep dives into everything Vue-related. From component libraries to best practices, and beyond, they've got you covered.
Michael Thiessen:
Welcome to DejaVue.
Alexander Lichter:
It's your favorite Vue podcast. You probably know it by now, but otherwise, you should check out all the episodes. We're in, well, a 40 somethings episode here, fresh in the new year, after hearing, well, some predictions and a little recap. Yeah. We are here not alone.
Alexander Lichter:
First of all, I'm here with my lovely co host, Michael Thiessen. Michael, how are you doing?
Michael Thiessen:
I'm doing pretty good. How about you?
Alexander Lichter:
Can't complain. Can't complain. Still same old, same old. Yeah. And, Michael and I are here with the wonderful Justin Schroeder.
Alexander Lichter:
Justin, how are you doing?
Justin Schroeder:
I'm doing great. Thanks for having me on, Michael, Alex.
Alexander Lichter:
Of course. And, I mean, you are, well, quite well known in the Vue community. You, and, of course, a lot of other people from your team maintain quite some open source projects. You're an open source creator. I think mostly people know you for this little project around a very easy topic in the web - forms.
Alexander Lichter:
Right? The FormKit. Uhm, so.
Justin Schroeder:
Yeah. That's true.
Alexander Lichter:
Yeah.
Alexander Lichter:
Of course, we'll dig into why forms are not as easy as people usually believe they are and why all applications are kind of big forms with a little bit of gimmicks in there, but also other projects around, that that you did and, maybe also some hot takes that is, well, just as well known for.
Alexander Lichter:
So but maybe let's get started with something that we usually ask people on here, Vue.js - How did you get into programming eventually to use Vue.js and also why?
Justin Schroeder:
Yeah. Good question. I mean, I think my programming journey is like probably so many others. I got interested in it when I was really little. So I actually grew up in Europe, in Germany and Italy.
Justin Schroeder:
And my parents moved when I was a young kid from, Germany to Italy, and I didn't know a soul in the whole country. And I was like in 4th or 5th grade. I was a young kid. And so I was sitting around like, I don't know what I'm going to do. And I started dinking around on a computer.
Justin Schroeder:
And next thing you know, I had written this would have been in 1998. And I wrote some JavaScript which was like basically didn't exist yet. I mean it was like so brand new. And all it did was make an alert pop up on my screen that said whatever message I wanted to. And I was like, this is incredible. I am the master and commander of the universe.
Justin Schroeder:
And from then on, I just started kind of programming.
Justin Schroeder:
So I did a little bit of BASIC when I was a kid and I did Java because Java was all hot back then. And all roads lead back to the web is what I've learned. It doesn't matter like which direction you wanted to go in. Even if you're like a like a systems programmer, you end up trying to do systems programming for the web because that's where people are.
Justin Schroeder:
So at some point, I think I was a sophomore in high school, and I came home for the summer and I was like, okay, there's this new way to make websites that doesn't involve tables anymore where you like to lay everything out with like CSS. I'm going to learn that and I'm going to learn this language called PHP, which is also relatively new as a way to like make websites do things. So that was my mission for the summer. I did it.
Justin Schroeder:
And then I kind of thought after that that was the end of programming for me. But, so I went to school to become a pilot when I went to college and kind of put this fun engineering thing on the side. Did that. Got my flight ratings and everything. Went and got a job as a pilot.
Justin Schroeder:
Flew for a few years and then got married and realized like this is a horrible career. Because we were married for I think 2 weeks and then, my company sent me to somewhere for a month and then I came back and was there for like a week. And then they're like, alright you're going to Chile for another couple months. I was like, I think I quit.
Michael Thiessen:
Yeah. Wow.
Justin Schroeder:
So I just decided to make a quick career shift. And that would have been back, 13 years ago or so. Picked back up all my old habits and, you know, like I think almost every Vue user, I was a Laravel person for a little while because I was in the PHP world, you know. And then Vue was actually, you know, really popular. But before I did Vue, I did React because React was earlier than Vue.
Justin Schroeder:
And so I wanted to get an idea of what this React thing was. So me and at this point, I was working at an agency and me and my coworker, who I love so very much, We wanted to try this React thing, but we didn't understand it. So we decided let's program our own version of React in jQuery because we understand jQuery. So it's built a a reactive framework in jQuery. And it wasn't like we were going to open source this or anything.
Justin Schroeder:
It was just like, can we understand it? So that way now like, I think it's almost irresponsible to pick up a tool if you don't understand sort of, like, what it's doing at least to some degree. So we did it, and we shipped one project with our crazy insane react-y jquery. And then we started using React until Taylor Otwell's famous tweet being like, Vue is Cool.
Justin Schroeder:
And then we're like, alright. Let's try that. And, that, you know, the rest is history.
Alexander Lichter:
What do you think how much time was there between you starting to use React and the tweet from Taylor Otwell, just like roughly?
Justin Schroeder:
Oh, not long at all. I mean, I would say I probably shipped 3, like full production apps in React. So we're talking probably less than a year, maybe like 9 months that I did React full time and then picked up Vue after that. And I don't even remember. I want to say Vue 2 was not out yet.
Justin Schroeder:
It was not stable or something. Everybody has this in their timeline, so other people will know more precisely than I will. But, you know, it was very early. Like, we start I think I started with Vue 2 and was, like, reading the chain blog, not understanding, you know, what was getting dropped from Vue 1 or something like that. So it was in those days.
Justin Schroeder:
Definitely yeah. I don't know. 6, 7 years ago. I keep it's a long time ago, it feels like.
Alexander Lichter:
Probably even more. Yeah.
Justin Schroeder:
But, like And that was me.
Alexander Lichter:
Interesting. And then, like, you you stopped
Justin Schroeder:
Oh, yeah. It was 2025. That was way before that.
Alexander Lichter:
Yeah. Yeah. Like
Justin Schroeder:
Oh my goodness.
Michael Thiessen:
Because I started 8 years ago, and that was, like, Vue 2 had been out For some time already.
Justin Schroeder:
So You guys are right. Yeah. That would have been, eons ago. Eons ago.
Justin Schroeder:
But Actually, a Nuxt Nuxt was, Nuxt was a godsend in that moment when you were when I was trying to learn this new framework because it was opinionated.
Justin Schroeder:
It's actually less opinionated now, of course. But Nuxt 2 was, you know, Sebastian's ideas were so baked into that kind of like the structure and the layout and the fabric of it. It was like that was almost my my learning tool more than the documentation. It was just, oh, here's how someone else had gone about thinking about where to put components and where to do this. And like, oh, okay, I can see how this works good.
Justin Schroeder:
And, you know, then you have a basis to form your own opinions. So I really appreciated everything that, you know, that Nuxt did for me back in those early days too.
Alexander Lichter:
So as you just mentioned, Nuxt, would you say this is more the patterns that Nuxt was promoting in terms of, like, okay. Here's the foil structure. Here's how we do things. Or also in terms of how Nuxt solve certain things source code wise, so, like, actually implementation details?
Justin Schroeder:
I don't think at that point I really had a great idea for what Nuxt was doing in its implementation other than it solved the server side rendering problem. So for me, like picking Nuxt at that moment was I get to use at the time we said isomorphic JavaScript. Nowadays, we think that's a gobbledygook term, but, you know, server and and, browser. And it solved that sort of that problem set for us, which was we need to pre render or server render. But then just just the conventions of where you put stuff and, you know, how you what directory structures look like and things like that.
Justin Schroeder:
That was it seems so simple, but when you pick up a new
Justin Schroeder:
I mean, I can't imagine nowadays trying to get into the web and just being completely lost at how many different tools are there are getting, you know, pulled in and compiled. Like, it is it's mind boggling.
Justin Schroeder:
And so being able to have something where it's like, Hey, you've got the pattern already here. You don't need learn this thing and then you can figure out other stuff, you know, learn, learn, learn the rules before you break them.
Michael Thiessen:
I think that's a really valuable thing. And when I first started, I was just doing front end stuff, and I didn't really there were other back end developers that dealt with, like, database schemas and stuff, so I didn't have to I just worried about the CSS. But then when I switched jobs, then I became a full stack developer, but we were using Rails. And so that was so helpful because then I could go and I could see, oh, well, okay. If I wanna update the database, there's this thing here that I can like, all of it goes into this folder, then there's another folder where we define, like, the actions, then there's another folder that we define the views, and then, like, there was a place to put things, and it wasn't just like, okay.
Michael Thiessen:
I just have to, like, figure this out and Yeah. You know, mixing database calls into your front end because you don't know any better. Right? And then it's just you have something to follow. Like, that's such a huge
Justin Schroeder:
It's really, really huge. And that's I mean, when I had first learned PHP, there were no frameworks. I wrote my own framework to make it work. And at some point, I got turned on to CodeIgniter.
Alexander Lichter:
Oh, yeah.
Justin Schroeder:
I don't know. Yeah. And when the writing was on the wall that CodeIgniter was going away, I was on some like IRC channel or something. I ended up getting in touch with Sean McCool. Do you guys know who that guy is?
Justin Schroeder:
I'm pretty sure that's his name. He's like an OG legend from the old the ancient days. And he was like, you should check out this Laravel thing. It's like brand new. It sort of works.
Justin Schroeder:
And that was also that was that was playing the same role for me in a different stage of my journey. It was like, it's great to come in with some pre formed ideas around some engineers who have already done it. I mean, if somebody is listening to this and is wanting to get into this stuff, don't try to learn all the tools immediately on your own. Go with something where you can get a finished product and then learn the tools one at a time. You know, maybe go back one layer of abstraction each time you do a new project, you know, like understand a little bit more about the stack.
Justin Schroeder:
But, yeah, use a tool that that's doing it for you.
Alexander Lichter:
I I can really resonate with that also coming from Laravel in the past and exactly the same feeling of, like, okay. You're not overwhelmed with, like, okay. Where should I put these things, and do I need sub folders to that? But do you have a rather clear structure with still enough flexibility and freedom to, like, make it your own in a project? And then if people was like, okay.
Alexander Lichter:
We have conventions. Let some other conventions. Or, hey. I don't like this because of certain reasons with, like, models and how they regard it, whatnot. So I really think meta frameworks or and and also back end frameworks really help with that and to not be like, okay.
Alexander Lichter:
I have to reinvent a wheel. I have to do it all my own. I can follow these conventions, and at some point, I can start also understanding, hey. Why is this actually happening? Why is that a good idea?
Alexander Lichter:
Or maybe why this is not the case for a project? So I I also think, as a beginner now, it's super difficult to, like, get started and just have not this, typical analysis paralysis where, like, okay. Which of the frameworks should I use? And then there may be not just one, but maybe 3 meta frameworks out there. Think of, like, I don't know, TanStack start, next, remix, and probably even more.
Alexander Lichter:
Or like hey, I just go build my own. So all are they by choosing React, first of all, which brings me to the point, why didn't you stick with React that you already learned and said, okay. You shipped free applications with that. What made you change Vue after going into that?
Justin Schroeder:
That is a good question. So my coworker who I was working with was really gung ho about Vue. He had not he was not part of the 3 projects, so I didn't react. And so when we were looking to do a new project together, it was sort of a greenfield. And from his perspective, just looking at the 2, Vue was going to be way easier to learn.
Justin Schroeder:
And I also enjoy learning new things. So I thought, yeah, let's give it a shot. And then when we did it, we just fell in love with it. You know, it was just so much easier for us to get our our heads around, you know, single file components in particular. At the time that was, you know, very unique and incredibly powerful.
Justin Schroeder:
And we were big CSS junkies. That was kind of like like we actually enjoyed CSS. And so the colocation of actual CSS, you know, not Tailwind at the time, but like actual CSS in the file fit our mental model really, really well. So all of those things I think kind of, you know, went together to make it a tool that at that company we we started to use repeatedly. And once you've gotten past the learning curve on a given tool it almost doesn't make sense to switch again.
Justin Schroeder:
Like there's very very little reason to ever want to switch once you are very very proficient at a tool. And you know one of the things I do a lot of times in one of my talks is show how that reason is getting like smaller and smaller and smaller over time. There's very small differentiations between these anymore. React is actually probably the most differentiated now because of the the render cycle that it has. And so much has coalesced.
Justin Schroeder:
So it's also it's easier than ever to learn a new framework, and there's like less reason than ever to learn a new framework if you're really good at one. And nowadays the biggest reason to change is the meta framework, not the framework. The meta framework is where like the new, all of the new important stuff is happening. So it's more important to pick a meta framework you like than, you know, which front end framework you want. That was just my opinion.
Michael Thiessen:
Well, and I think a lot of people end up learning new frameworks because they switch jobs and that's just like what they have to do. So they're forced to in a way. Yep.
Justin Schroeder:
Well, and it's funny because the cross pollination of ideas between the frameworks, everybody switches jobs. And then they're like, well, now that I'm using Vue, I like this one thing from React and now I'm done. And then they sort of end up making their way eventually into those those frameworks themselves. And we end up in a very, very similar place.
Michael Thiessen:
But they built some libraries so they can have that feature in the next thing. And yeah.
Alexander Lichter:
Interesting. So then you would say if if you let's say you have no knowledge of a framework right now, it is like, okay. Whatever is, like, out there. I don't know. I know jQuery.
Alexander Lichter:
I know JavaScript, HTML, CSS, and I would have to pick a framework or, as you said, more importantly, meta framework. Which is the horse you would bet on?
Justin Schroeder:
Well, I'm obviously very biased as are you, Alex.
Alexander Lichter:
That's why I'm asking you!
Justin Schroeder:
I I absolutely love Nuxt, and Nuxt 3. I think they're the most complete solution that sort of exists that gives you tools as far up the stack or down the stack you want. And I have I do occasionally do projects in others.
Justin Schroeder:
Like most recently, I did a project in Next. And obviously, you know, anytime somebody does something in in another framework they're less familiar with, there's going to be problem areas. But I kept being surprised at how little of the stack the Next, like, actually covered. Next didn't cover as much as Nuxt. Part of that is the fact that, you know, we have, you know, plugins and there's this entire UnJS framework that goes under the hood where you can go really, really down low or you can go really, really high up into things like, you know, you you don't get to quite modify the way Vue runs itself, but very close.
Justin Schroeder:
So you actually can if you wanna write your own render. But like, you know, not very many people do that. But you can go very, very high on the stack and still be within the Nuxt sandwich. And so I personally really love that because there's a lot of times where we've made Nuxt do crazy things that we needed it to. Like run Python as the back end instead of JavaScript or you know, do some pretty insane things that that you're just never going to be able to get Next to do.
Justin Schroeder:
And then I also love the fact that I can deploy it absolutely anywhere. You know, Pooya has done an incredible job of getting that stuff to run on anything. And Cloudflare in particular, because Cloudflare I would say is one of the hardest things to get stuff to run on when you want to run like not their boilerplate worker code. And so the fact that it works there is really, really, impressive. So that's a bunch of glowing review about it.
Justin Schroeder:
That being said I'm romantically smitten with, with Solid and SolidStart. I think what you know Ryan Carniato has done there is take his time and observe the way that all of these other frameworks have evolved over time and seen a lot of potholes that they found. And then try to build sort of like the best bridge solution for each of the big problems. And so he has a little bit of that benefit of hindsight. I mean it's not just him but, he's kind of driving the project.
Justin Schroeder:
But they get they've gotten to kind of look back and solve all the problems with a fresh slate with no real legacy. And so I think it's very, very cool what they've done over there. That that's, like, if I was just gonna pick one up for fun and play, I would start there. I don't know how many jobs out there are really in that ecosystem and whatnot. But yeah.
Alexander Lichter:
I guess not too many, but I think also, like, yeah, following Solid and and Ryan, especially also very closely because everything related to signals, performance, streaming, like, as you said, like, analyzing what the ecosystem has to offer right now, what are good options and where is room for improvement, especially without things like necessarily a compiler to fix things, let's say, quote, unquote, like, with the React compilers. Like, hey. I might your code faster by inserting memorization where it might be better. In a way, it's a it's a very interesting approach to say, okay. We don't wanna rely on it, another tool toolchain, but straightaway wanna hit it right.
Alexander Lichter:
So I'm I'm really curious where where this is going.
Michael Thiessen:
I don't follow a lot of other frameworks that closely, but one thing that I've noticed is that Evan You seems to be pretty good at also seeing what's going on in other frameworks and taking those ideas and incorporating them back, like, vapor mode for Vue and and other things, like, things that have been inspired from other frameworks and bringing them back and and not just sort of getting, like, tunnel vision and saying our way is the best way and everything else sucks, but just, like, being open minded and just trying to take the best ideas and incorporate them back. I think that's really
Justin Schroeder:
He's done a good job of that too.
Michael Thiessen:
Great. And one thing that I I love because it makes me feel, like, a lot more secure in the future of of view and not like that it will continue to evolve over time and not just be, like, replaced by the next great idea, but that it'll incorporate that next great idea at some point.
Justin Schroeder:
I I think Vue has legs because of the work of people like him continuing to glean the great ideas that are out there. He's talked about this before. There's always this sort of risk of being a legacy framework that you're unable to make the big shifts because of, you know, what it does to all the people who have built with your code. And that is like, that's the hardest part of, I think, any of these maintainers' jobs is you can't just break everybody's code and you can't break their expectations. And that means that like when a new idea comes out, you have to be really judicious about whether or not to include it, whether or not to go through the effort of bridging the expectation gap that exists between some new fancy API and the way your users are used to writing code, that kind of stuff.
Justin Schroeder:
Like you know, it like Vue would probably have have benefited from never having, like, global plugins. Because global plugins means there's global registration, which means that's all that's always going to be in your bundle and so on and so forth. But once you've given that expectation to users, you need to allow it to continue to exist. So the best you can do is say, well, now you can register your plugin not just globally. You can register it locally.
Justin Schroeder:
And that means you can tree shake it out. Where somebody else could start their framework and say, no that's not a concept from the very beginning. You import it here where you're going to use it and that's the way you write the code. And then that's like a big benefit from them because then they'll never be nobody can ever write code that doesn't get optimized in that way. So Evan, along with poor little me, have had to fight some of these battles and probably Alex and the Nuxt team too.
Justin Schroeder:
Yeah. Of like, we gave these people this great tool that actually has downsides in some other way, and now we need to keep their expectations while trying to shift the ball over to somewhere where, you know, it's better in other ways. So I think Vue is facing that along with React. I mean, React's now got their forget compiler and stuff like that, which is basically trying to do the exact same thing. Hey.
Justin Schroeder:
You can keep writing it the way you expect to write it, but now something fundamentally different is happening under the hood. Yeah. And it's interesting to see where these things are gonna go. I I don't really know. I suspect compilers are here to stay and get probably more and more and more command of our entire code stack.
Michael Thiessen:
Mhmm. I think it's like that problem in general though, is is like one of those, it's a good to have problem because it means that your project has users and a lot of things. A lot of things have this problem where it's like, oh, you know, starting a a start up, like, brand new, it's great because you can just do whatever, and you can move fast, and you can break things because you've got 3 users. So who cares? Like Yeah.
Michael Thiessen:
They believe in you, so whatever. But then once you are successful and you've got, like, a 10 year old codebase littered with tech debt and terrible things that you hacked to get there, but you've got thousands and thousands of users that
Justin Schroeder:
Are you attacking me right now?
Michael Thiessen:
I'm I'm I'm speaking from personal experience here. But it's just like the cycle that, like and you're like, okay. How do we change this without ruining everyone's life and, yeah, move forward? So
Justin Schroeder:
Yep.
Alexander Lichter:
And, usually, like, a full rewrite, especially for a software project, it's not possible. Like, you you can't put all these man hours in. Business will say no because what's the value in that? Like, how long does it take?
Alexander Lichter:
Even, like, with migrations, and we've seen it from vue 2 to vue 3. We've seen it from Nuxt 2 to Nuxt 3 that, like, people are very hesitant. I still I still work with a lot of clients that said, like, hey. We wanna migrate now because now we have at least the budget and somewhat of expectations, and we're not the first ones, as, for example, Sumit, who was on here a couple episodes ago, was saying, like, we don't wanna be the first ones migrating. We don't wanna have all the problems.
Alexander Lichter:
But still, it's it's a lot of work depending on how big your application is. So also Yeah. As an author of a framework or, like, a library, finding the nice balance of, hey. Here are all cool new things to play with. But, like, okay.
Alexander Lichter:
We have breaking changes. How can we make them as minimal as possible while still actually removing technical depth and making sure, well, things are better and more optimized, but also giving people time to migrate. It's really difficult to have, like, all these things together, and I feel like sometimes it's, like, the the good CAP theorem of, like, okay, you can only choose 2 out of the 3.
Justin Schroeder:
Right. Yep. That is true. It's a tricky balance.
Alexander Lichter:
It it definitely is.
Alexander Lichter:
But, as you said before, you also experienced, these problems that that, like, Evan, also people from Nuxt team had because you're also maintaining quite some open source libraries. And as we said before, I think the most popular one, in the Vue ecosystem, at least, is is FormKit. So maybe people might wonder, like, okay. A form, yeah, I smash in a form HTML tag and then the few input fields.
Alexander Lichter:
And, like, v model, we have two way data binding in Vuew. Maybe with the defineModel macro, it's even nicer now. What else do I need? And that's probably the people who didn't build a big form by now with all the business requirements, or That's true. Might want to.
Alexander Lichter:
So maybe it would be good to to, like, explain why is Formkit, let's say, quote, unquote, necessary to handle bigger forms or, like, a form library in general? And maybe, first of all, why are forms so difficult?
Justin Schroeder:
Yeah. There's a lot of reasons that forms are difficult, and I don't think starting out, I even really recognized it. So the precursor to FormKit was a project called Vue Formulate. And the precursor to Vue formulate that everybody heard of was a Vue Formulate that nobody heard of. And in the very first version of Vue Formulate, the entire goal was to try to get this is back in the Vue 2 days to try to get your form data into VueX.
Justin Schroeder:
It was like, let's get our data into the store. And that was that turned out to be actually like really challenging to do on a repeatable basis. And we wanted to do it on a repeatable basis because I was working at an agency. We're cranking out lots of these things. And so we ran a library to do it.
Justin Schroeder:
And in the end, we didn't really like it that much. So but what we did like was we liked the fact that we had created all these components to encapsulate the various inputs, you know, and then we decided we wanted to like reuse that idea in the future. So we rewrote the library. I mostly did it in the middle of the night and that was reformulate 2. And so the idea was we need something that bridges two main gaps.
Justin Schroeder:
1 is how do you handle the data in your form? And the second one was how do you handle the structure of the form and the markup that gets output? Because there's a lot of different pieces and parts, especially when you have to build accessible forms. So like the way that labels get related to fields, the way that validation rules do, the help text, the way fields relate to each other. This is like the most basic one.
Justin Schroeder:
But imagine, you know, a password and a confirm password. Somehow those 2 inputs need to communicate to each other. So you know which one that or that these two things are matching. Vue users can come up with probably a 1000 different ways to solve that particular problem. But creating a universal way for inputs to be able to communicate with each other was problem set that we had.
Justin Schroeder:
And so, you know, we created the second one, Vue Formulate 2, and it like we put it out there. At that point, I had put out tons of open source stuff in the past. And, like, usually you would get, like, 1 or 2 people that would use it occasionally. And then, you know, sometimes I would get an issue file or something like that. But these are very small basic.
Justin Schroeder:
Nobody was really using any of this stuff. They put vue formula 2 out there and it, like, took off. Like, it grew a life of its own and, you know, thousands of people started using it and we got tons of stars and stuff. And I was like, wait a second. I think maybe other people are having problems with forms too.
Justin Schroeder:
This was in the late days of Vue 2. So like Vue 3 hadn't come out yet, but it was like the writing was on the wall. And I was surprised that in the Vue ecosystem, which already had a lot of form libraries, that there was still such an appetite for people to solve the form problem. And I think what people started to resonate with was this exact idea that the forms weren't just the data problem. So you know like there's a lot of great tools out there like nowadays like Vee Validate would be a good example where you're able to model your data really well for the form.
Justin Schroeder:
That is a big problem set. But there's an equally big problem set of making sure your form is internationalizable. It has proper accessibility. It has the validation messages that are getting placed in the right places. It has all these different like nuanced behaviors.
Justin Schroeder:
Like when do I show my validation message? Is it on blur? Is it when you click in? Is it when I when I go to the next input? Is it when I click the submit button?
Justin Schroeder:
Like and what are the opinions about what the best practices are for those things? There's a big learning curve for all of this stuff. So to be able to encapsulate all of that and say, no, this is the comprehensive solution to forms, that was really appealing to people. And so that's sort of what the genesis of Vue Formulate was, Was it's an attempt to get to that. And then when Vue 3 came out, it was like we got to rewrite the whole thing.
Justin Schroeder:
So let's just start from the basics and solve this in a really fundamentally new way. And so that was where FormKit came in. And so the problem sets that FormKit solves are like literally anything to do with forms. From styling, accessibility, internationalization, behaviors, data flow, data validation, back end validation, placing back end errors back onto the inputs after they've failed for some reason. All of that, that entire stack, storing stuff in local storage and rehydrating oh, rehydrating forms?
Justin Schroeder:
Oh, my goodness. That alone, like, is a major problem for people. Right, major major problem. Because, if I have a form an the form changes based on the input of a form. Like let's say you're you're selling conference tickets and you want to allow people to click a button to add another ticket and then that requires a little bit more information. Click add another ticket, put in more information.
Justin Schroeder:
And let's say at some point I want to be able to have the ability to like edit that or resume, come back to it. Then the structure of my form changes based on the input data that's coming into my form. So my form is based on my form. You sort of have this interesting recursive problem. And there's a lot of ways to solve that.
Justin Schroeder:
But how do you solve that in sort of a universal way that you know that everybody on your team knows when I put the data in here, the form just magically becomes what it's supposed to be again. And in an accessible internationalizable way and so on and so forth. It's like they become very, very, very hard problems. And you can solve all of these problems just using Vue. Of course, it's totally possible.
Justin Schroeder:
The problem is you're going to solve it one time and then it's not repeatable. And when new best practices are out or something like that, you don't get the downstream benefit of being a recipient of it. There's so many issues with it. And so at some point, we realized when we were in the process of writing FormKit that like, wait a second, actually, this is like the entire application. Like, this is the entire meat of what people's businesses are.
Justin Schroeder:
They are forms, and then they've got gloss around the forms. So it's okay for us to build, you know, a very robust tool here where we can stretch it to meet the edge cases. We don't need to just be like a simple little utility. It's okay for this to be more than a library, almost be like a framework in and of itself. That's why we call it a form framework because it will stretch and become almost anything that it needs to be as long as it's sort of within the boundaries of a form.
Justin Schroeder:
That makes sense. I don't know if that answers your question. I just started waxing poetic there. But
Alexander Lichter:
No. I think it was pretty good. And I also wanna add something where you said, like, yeah, you can solve all these problems using Vue. I I agree. But you also need the knowledge.
Alexander Lichter:
And you already mentioned i18n, internationalization a11y, so accessibility. It's not like everybody knows how to make forms accessible in the right way. And I'm not only talking about, hey. This needs an area label if it doesn't I don't know if it's a button with just an icon. It's also about keyboard navigation and everything.
Alexander Lichter:
And I'm Yes.
Michael Thiessen:
Like Yeah. There's a lot of stuff.
Alexander Lichter:
It is. And we've all been to a lot of sites where we just wanna push tab or enter to make things work, and it just does not. Yes.
Justin Schroeder:
Yes. And and getting it right on, so like a text input is is relatively simple. There's still a surprising amount of complexity in it still, but it's relatively simple. But getting it right for something more complicated, like an autocomplete, you know, drop down list kind of stuff or paginated results of stuff. It's like that one input will take you months.
Justin Schroeder:
It will literally take you months if you want to check all the boxes. So what you do is you don't. You skip the corners. Right? You just like you just don't do it.
Justin Schroeder:
Like people just don't do it the right way is is what ends up happening. Or or you use, you know, some some third party solution. Like I want to say our autocomplete that we have as part of the the FormKit Pro package, like writing the first draft of that thing, I think took like 5 months. It was just for a stupid little input. It's insane.
Justin Schroeder:
You have to think about cache invalidation and multiple pages and querying. And how do you rehydrate a query result on the front end? Like, you know, if all I want to do is store ID 127, how do I make sure that I can repopulate that properly? There's it's like an endless list of problems. Sorry, Michael.
Justin Schroeder:
I cut you off.
Michael Thiessen:
No. No. I I was just gonna say that I, one of the the major things that I have built in my career was a a component library that I did a lot of work on. And so I had a lot of these forms, day pickers, autocomplete drop down things that I built, and I remember, like, even then, I was only working on it for a very specific set of use cases, not like a general auto complete that can be used anywhere. Yeah.
Michael Thiessen:
And I try my best to do accessibility and read through the the the guidelines of trying to decipher, like, there's lots of gray areas of, like, okay. But, like, do I need to put this label here or or not? And, like, I'm sure it was alright, but I don't know that it was amazing in terms of accessibility. And so, like, when you go to check out form kit, as many of you might be doing right now or later I think it's just you go and you check out, like like, the demo components you click around, you're like, oh, cool. Like, it does some stuff, but, like, there's way more going on that you don't see.
Michael Thiessen:
And I think that's probably, like, the biggest thing, because it's to be honest, to to get to get the CSS and the markup to have a little, drop down autocomplete, that doesn't take that long to do.
Justin Schroeder:
Few minutes. Yeah.
Michael Thiessen:
It's all the other stuff that's really hard that you don't see unless you're someone using a screen reader and you can't use it.
Justin Schroeder:
That's right. Yeah. And the the other benefit, of course, is that, like, when you wrote that library, if you made some mistakes and you published your library out there, somebody is bound to come around and say like, hey, it doesn't work in this particular way the way it's supposed to. Well, of course, sir. I've got it.
Justin Schroeder:
I didn't I wasn't a 100%. You fix it. You put it out there. And then down stream, your users get to receive the benefit of that. That's another really important thing when you're looking at accessibility for trying, you know, to use a tool that is responsible about that is you can receive the benefit.
Justin Schroeder:
So of course, we've gotten tons of pull requests of areas where we didn't do things right, you know, and we needed to fix them and we've done our very best. The other thing we did is we went out and we hired a studio, that employed blind people exclusively to do accessibility audits. And their goal was not to tell us if we checked the box, you know, of, you know, WCAG 2.0 whatever. Like their goal was to tell us, I'm blind. Can I use this thing?
Justin Schroeder:
And so then we got their feedback and tried to implement that. Some of that stuff had absolutely nothing to do with, you know, what all of the accessibility people, tell you about. And some of them were, you know, normal accessibility things. So, you know, we got, I think it was like a 10 page report and we went through every single thing and tried to address every single one of those things to make sure that we were doing it as best we possibly could. So, yeah, there's a lot that goes into these things, of course.
Justin Schroeder:
And the reality is, you know, a lot of the people listening to this are just to be honest, they're going to say like, it's not that important. My boss doesn't really care and so I'm going to move on. And like that's fine. Yeah, everybody has their own priority sets, but as a library it feels like it's almost a moral obligation to make sure that you're doing what's right for, you know, the masses of people that are trying to use your tool. And so for us, it was a very, high priority to make sure that we could do that stuff as best we could.
Justin Schroeder:
And of course, there's still areas that we're gonna we're gonna fail and we're gonna need to continue to fix and whatnot. Nothing's ever perfect, but, but we're trying.
Michael Thiessen:
Yeah. I know in the us and I'm sure the EU and other places have something similar, but they're like, you can get find pretty pretty hefty sums if your website or software or whatever isn't properly accessible, and so it can be a big deal.
Justin Schroeder:
It can be. It really can be.
Michael Thiessen:
So
Alexander Lichter:
I think that's that's one part. And, yeah, as you said, like, the EU also has that. In Germany, for example, now it's, getting into effect, like, half, like, in the middle of the year, you know, in June, July. It's also responsible for, like, pages out there to do b to c, for example, that they have to be accessible. Not only, like, government websites and whatnot where it should be a standard.
Alexander Lichter:
I think the other part is and and I agree with Justin there. Like, especially as a library is, like, some kind of obligation because especially if you have a lot of users, then every mistake you don't fix, they won't maybe not even notice or they they won't fix it necessarily. Yeah. But the other part there is actually make the effort and getting a report from people using it. It's like, it doesn't matter what kind of product you have.
Alexander Lichter:
Like, real user testing is so key, and especially for accessibility. There are also a lot of opinions out there, like, oh, should I even like put this label there? Should I use that tag or not this that? While usually people can tell you that they rely on assistive technology every day. So the easiest is asking them.
Alexander Lichter:
Right? And and I think that's it's important to highlight that this has been done because I know a lot of scenarios in a lot of libraries won't go like that far. It's like, hey. We wanna we wanna make sure this is right. I think I disagree with your statement, Justin.
Alexander Lichter:
It's like, yeah, of course, business wise, sure, every company has a different, let's say, priorities. But just by saying, okay. Look. If this is something, let's say, public facing, easiest case, ecommerce, then well, even business wise, there is a case for that. But beyond that, of course, you don't wanna say, hey.
Alexander Lichter:
Okay. People with disabilities, and it can be permanent or temporary. It doesn't matter. They they basically can't use the website or have a worse experience. I I understand that this is, like, a lot of things, like, oh, yeah.
Alexander Lichter:
We need performance and SEO, and it should be super fast, but nobody cares about accessibility, sadly. I hope that the law also will change. But in a way, I think also there is that obligation just to say, like, hey. Let's keep the interact make the Internet a better place to just make it usable for everybody as as much as possible.
Justin Schroeder:
I mean, that's what we want. It's a little bit idealistic to assume that, like, some person who's just learning Nuxt for the very first time is also going to be able to pick up the mantle of being able to do this. And unfortunately, that's just that's the reality. The other thing to consider is a lot of the most complex forms are in admin systems. And technically they are supposed to be accessible too.
Justin Schroeder:
At least in the United States with the American Disability Act. The idea is like you need to be accommodating to whatever somebody's disability is in order to have a job or receive commerce. So you know if you want to go to an ice cream shop, they technically are supposed to have a ramp unless they were grandfathered in, you know, before the laws were passed or whatever. And the same is sort of true for an employer who is employing people. But there are of course exceptions, right?
Justin Schroeder:
Like you don't have to the I don't know what's a ridiculous example. The UFC doesn't have to be able to like isn't forced to hire anybody of any physical capability to be a fighter, right? That's not that's not realistic. It would be you know unrealistic for a business to have to hire a blind person to do photography. Right?
Justin Schroeder:
Like, there are, of course, exceptions to these rules. And sometimes these admin systems sort of fall into that space, you know? I think that's where I see the most corner cutting is, like, they're just, like, let me get this thing working so that way my products can get
Michael Thiessen:
Mhmm.
Justin Schroeder:
Shipped or the boxes can get labeled or whatever the functional thing is that they're doing. And accessibility, you know, is the absolute last thing that they're thinking of when they're putting these forms together. And I want to be realistic that for people like that, I could talk about Form Kits accessibility all day long. And they're like, I just don't care because I want to put the label on my box that I'm shipping out. So I sort of understand both of those positions.
Justin Schroeder:
But yeah, especially for user facing stuff. I mean, it's important. My, my, my own sister actually is like a quadriplegic. And she needs all the accessibility things that you can give her. She cited, but she still needs all these accessibility things.
Justin Schroeder:
And it's incredibly frustrating to her, when, you know, things don't work the way that she wants them to work. Like she's trying to buy football tickets, American football. None of this none of this soccer stuff. And, like, in she couldn't do it on the website, because she can't drive her wheelchair into the stadium except for through a certain entrance. And she can only sit in a certain place.
Justin Schroeder:
And so she had to like call multiple times on a phone, which she can't use, in order to be able to, you know, get the tickets. And so you don't want to be part of the problem. You want to be part of the solution if you're a web developer, you know. And at the very minimum, choose libraries and Form by no means are the only one. But choose libraries, that are, you know, trying to help those people when you're building your systems.
Justin Schroeder:
Yeah. And there is a business case.
Michael Thiessen:
I wanna just add one last thing where there's I think there's, like, some side benefits too. So, like, when you write tests for your code, you often end up writing code that's better. Mhmm. And I think with accessibility, if you make your forms accessible, it's also easier to use for people who don't have any disabilities. So, like, keyboard navigation and all sorts of these other things are, like, technically, I don't need that.
Michael Thiessen:
I can click a mouse and and do it, but, like, if it's properly keyboard usable, then it's way better. And I Yeah. My time using that way more.
Alexander Lichter:
We always have a little frustration when you, like, hit tab, as we said before, and it just doesn't work. Okay. Then I have to use the mouse.
Michael Thiessen:
Or enter, enter, submit, and I'm like Yeah.
Alexander Lichter:
Yeah. No. I I I fully feel that it's I and also agree with that. That's like it gives better user experience no matter if you have disability or not. It can be enough that you're just like, I like to use the keyboard more, and not like, oh, I can't use my mouse for whatever reasons.
Michael Thiessen:
Just one pet peeve that I have to throw out there because just yesterday, I was on this UI and had a whole list of check boxes with the labels beside it. And when you put your mouse over the label, the the the cursor changed to a hover, and I was like, sweet. So I started clicking. No. I gotta go over to the the check box, which is, of course, like, the default, like, check box that's, like, 12 by 12 pixels, and so it's, like, a game of precision.
Michael Thiessen:
And so I was, like, if the hover like, it didn't change the cursor, that would have been okay, but because the cursor changed and you, like, tricked me into thinking I could click on it, it was, like, especially, frustrating. Yeah.
Justin Schroeder:
But
Alexander Lichter:
Like, you didn't I know
Justin Schroeder:
I'm just not being able to click to label.
Alexander Lichter:
Yeah. But it's and the best part, this is like a browser functionality. Right? Like, if you wrap your label around that that input, it's clickable, or if you use label on 4. But even if you don't know about the 4 attribute, like, if you wrap it around, it should work.
Alexander Lichter:
So, yeah, this this is also, like, use semantic HTML, like, okay, buttons. Right? Links, anchor text. So it's these are, like no nobody, like, has to be a crazy accessibility expert. I feel like if we take a look at the report, it's like, I think the something with 1,000,000.
Alexander Lichter:
I think AIM we have WebAIM, web accessibility. So WebAIM million report, it shows the top 10 mistakes on websites and the top 10 mistakes on websites. We all would understand how to fix them. Yeah.
Alexander Lichter:
It's it's so trivial. It's like missing all text, like, using buttons instead of links or divs instead of buttons and all these things, color contrast. So there are usually, in in the most cases, it's very easy.
Alexander Lichter:
And if that all would just work out of the box, like, software would get like, they they become so much better. We're not even talking about the the complex cases, which also, for example, FormControls with, like, nested forms that are super complicated and keeping the tab order there and so on and so on.
Alexander Lichter:
We're even talking about very simple scenarios. So
Justin Schroeder:
Yeah. That's totally true.
Alexander Lichter:
Like, just having a look at the reports, like, okay. I can most of these things, we can automatically test. It's like, okay. Let's fix them in a couple of minutes. Like, giving an alt tag to an image, either do it in your CMS, or if it's static images, write it in there.
Alexander Lichter:
It's not that tricky. Same with, like, buttons with just I can give them a label, give them a name to actually make sure that people can't see the logo. And also the search engine, they know what, the link is going to. That's a that's a huge part there. And, I feel like we could make a whole episode of accessibility.
Michael Thiessen:
We really could.
Alexander Lichter:
Yeah. I think we even said it before in our episode. So we might should do that at some point. But I think it's also a good point to to move on because you mentioned okay.
Alexander Lichter:
You you hired a a studio, that that works with many blind people to do a report.
Alexander Lichter:
You put a lot of effort, like, 5 months for the first draft of the autocomplete. Some people might wonder, okay. But it's a it's a free library. It's open source, as we said in the beginning. So how does that work?
Justin Schroeder:
Yeah. So FormKit Core is open source. And then FormKit itself has spawned a number of other, open source libraries. So there's FormKit core, which is all of the architecture for FormKit, and then every native input.
Justin Schroeder:
So text, checkbox, radio, select lists, all of that. All that is all part of the open source. Then we have a paid piece, which is what we call like synthetic inputs. And this is FormKit Pro. And it's just the like it's basically like the form components that are made out of divs.
Justin Schroeder:
That's the way to think about it. Right? So your auto completes, your date pickers, your mask inputs, things like that. Like these, you know, obnoxious tag lists, the stuff that takes a really long time to write and implement. And you can wrap your own.
Justin Schroeder:
So if you want to bring your own, you know, external library, like, I don't know, shadc yet or whatever. You can you can get all those wired into the open source core too. And there's some some people have even written those wrapper libraries and they're available open source. Ours is just our first party solution. So we kind of take the same, you know, very granular FormKit approach into those other components.
Justin Schroeder:
So that's, yeah, that's the paid product. And then That's
Alexander Lichter:
that's a one time payment, right, just to to iterate on that?
Justin Schroeder:
It's a one time well, the way it works is it's a one time per, like, project. Mhmm.
Alexander Lichter:
Yeah.
Justin Schroeder:
So if you are a business, you buy it one time for your project. If you're an agency, the goal is that you would buy that for each of your client projects and just include that in the price of the bill that you send to your client. And then we also have this, AI form generator where you can just, like, ask for whatever type of form you want and it'll generate the first task for you. We call it kick start because it's not gonna, like, you know, it's an AI as all the faults that AIs do. But it'll do its best given prompt to generate a form for you.
Justin Schroeder:
And then it gives you the Vue code for that at the end of the day. Or it gives you what we call schema, which is a JSON serializable format, which FormKit offers. Like you can store any FormKit form that you can make or even FormKit inputs that you can make. You can write them as JSON and store them in a database and then give them to our component and it'll rebuild your entire thing. So you can choose which format you want, Vue or JSON.
Justin Schroeder:
So those are the 2, like, paid products. And that's kind of our hope is that those would become a sustainable source of revenue to keep the whole project going.
Alexander Lichter:
Yeah. As you said, your hope is that it would. That means that you're not there yet.
Justin Schroeder:
No. Definitely not there yet. We have an agency as well, which it's like the real thing that's paying our bills. And also the way that we dog through this and it's an impetus for us to, you know, build it in the first place was we're building a lot of sites as an agency. Yeah so most of this is still being done as a an act of charity to the world which is fine.
Justin Schroeder:
But we hope that someday it would be able to cover the bills. It's actually surprising because there's a lot of really, really big companies that use FormKit, which maybe isn't shouldn't be so surprising.
Alexander Lichter:
That's not the surprising part.
Alexander Lichter:
Yeah.
Justin Schroeder:
Yeah. If you had told me and I'm not allowed to say publicly a lot of them, but they're all big brand names you guys have heard of. And if I could have gone back to the beginning and been like, these are the brands that are gonna use FormKit, then I'd be like, oh, well then we're definitely sustainable. But that's not the way it works. Right?
Justin Schroeder:
Because it's a product. So they buy it for the same price you buy it for.
Alexander Lichter:
Yeah. So that's that's the way it works. Unless they have, like, I don't know, 10 sides of legal contracts and then have to put the enterprise
Justin Schroeder:
That would be nice. That would be nice.
Alexander Lichter:
Well, that depends if you have to deal with the contracts not, if the sum is right, yeah, I get this. Okay. Then definitely also there. As I said before, link's in the description to to all of that checkout form kit, everybody.
Alexander Lichter:
And, if you use that, and especially I I also use the pro inputs in various projects, and people usually are super happy that they don't have to put in the work of, like, hey. I wanna draft my autocomplete straight away. So so that's, especially useful if you just wanna ship things and want battle tested components. I can just give a big thumbs up.
Alexander Lichter:
And I'm really curious what's what people did with with Kickstart because, I mean, you can even upload photos that are, like, hey.
Alexander Lichter:
Give me that physical, like, form and just, like, bring that in the words. Like, okay. I could digitalize my my whole company just by using that AI and some custom code.
Justin Schroeder:
Yeah. I mean, really blown away by, how good AI has gotten at that. Right? I mean, we're also just a user of AI, of course. And, well, it's not like we created our own models from scratch or anything.
Justin Schroeder:
But it has gotten incredibly good at being able to do that translation layer. And then we brought a bunch of super innovative, genuinely innovative ideas, I think, to the AI space that we kind of pioneered in Kickstart. And we'll eventually ship other things using these same concepts. But that we're able to make really good deterministic decisions based on these fuzzy inputs. And that's really the magic of AI is like, can you take fuzzy input and turn it into determinism?
Justin Schroeder:
Yeah. And this is not what chat gpt does. It takes fuzzy input and it outputs fuzzy input or fuzzy output. And there's it's a bit of a party trick because the fuzziness of the output could like sound good to our human ear. But if you try to make that actually do code like things, it it it's pretty hard.
Justin Schroeder:
And so a lot of time and effort was spent on trying to understand a good architecture to take those fuzzy inputs and create like actual hard code at the end of the day that work for a user and was fully aware of everything that FormKit could do. And so yeah, the people who use it, like it's funny because there's a free trial. Anybody can go there. It's, kickstart.formkit.com and just type something in for fun and and you'll see. But so there's a free trial and then and eventually you hit like a limit.
Justin Schroeder:
There's like a token limit basically. Once you hit your token limit then you pay I think it's $10 a month or something. And that unlocks it to unlimited. So as soon as somebody gets past that gate, you just see them like use it, use it, use it, use it, use it, use it, use it, use it, use it, because they're doing massive translations of particular sets of data they already have. That's the that's by far its most useful application.
Justin Schroeder:
So, you know, like, actually the the US government was really interested in this a while ago and using Kickstart because they have literally thousands of these paper forms that they need to then convert into digital forms as they're constantly modernizing processes and stuff like that. And this saves literally countless hours by being able to put it through a system like that. So I think it's still interesting where things like this are going to go. And, you know, I've definitely learned that developers are scared of AI through this. They're reticent even to use it because of kind of I don't know if it's an existential fear or just kind of a concern that if we all adopt this, then what we do changes and we don't want to change what we do.
Justin Schroeder:
Like, you know, almost like somebody coming and being like, you can't use Vue anymore. And you're like, well, I don't like what you're saying. Yeah.
Alexander Lichter:
Got that. Yeah.
Justin Schroeder:
So I'm not sure exactly what it is. But
Michael Thiessen:
I think there's a lot of uncertainty as well of, like, okay. AI is clearly changing how we write code, but how is it changing? And, like, it feels like it's it like, it's not like other things where the pace of the change is pretty slow over time, like, oh, we used to write jQuery, now we write Vue, but, like, that transition can happen pretty slowly. You just, like, switch jobs. You don't have to really, like, worry about suddenly your skills no longer being valuable because over 2 months, everyone switched from jQuery to to Vue, and you don't know Vue yet.
Michael Thiessen:
Right? I think it's like the it feels like it's going faster, and you're like, well, a year from now, is it still gonna be worth it for me to do what I'm currently doing? Or do I need to, like, learn some whole new thing? And if so, like, what what is it that I have to learn? Like, that's totally unclear.
Justin Schroeder:
Mhm
Michael Thiessen:
And I think maybe there's something of that in there.
Justin Schroeder:
Yeah. These are big, big life questions, that are hard to answer for people. But I gave a talk one time at one conference only ever. It's the only talk I've only ever given once about this exact problem. And it's just my opinion, but I really think that people need to jump on the bandwagon.
Justin Schroeder:
And I know that it's uncomfortable to have to learn something new.
Justin Schroeder:
And AI is not going to like literally replace you tomorrow. But if you are not an AI engineer, and I don't mean you're making AIs, I mean you are using it to do what you do and know how to leverage it. I do think you're going to get left behind. And that's uncomfortable and people don't like that.
Justin Schroeder:
And unfortunately, I just I really, really think this is true. And so I would really encourage everybody to, by a minimum, start using it to help you write your code. You know, go use Cursor or something like that. I was like like here, in the US, I, you know, was at a conference with some people and I was asking, you know, who was using Cursor and whatnot. And, like, everybody was using Cursor.
Justin Schroeder:
And then when I was in, in Bonn, Alex was there in what was that? October?
Michael Thiessen:
Yeah. We did a little panel.
Justin Schroeder:
Yeah.
Justin Schroeder:
We did a little panel.
Justin Schroeder:
And on stage, I said, how many of you are using Cursor? And I think there were 3 people in the audience that put up their hands. And I that that worries me because I just think that you're at a severe competitive disadvantage. And so I know that it's uncomfortable, but I would strongly recommend people at least start trying this.
Justin Schroeder:
It is a game changer. Whether or not it's perfect, that's not really the discussion. It's not perfect and it makes lots of mistakes and you still have to be an engineer, but it's coming.
Michael Thiessen:
I completely agree with that. And I think that it's a totally different way of writing code as well. So it's it's hard in that way because it's it's not like learning a new programming language or learning a new framework because that's a whole, like, different way of thinking about your problem and how to attack it and how to, like, use this thing to help you. Or it's almost more like like programming with another person than, like
Justin Schroeder:
Yeah.
Michael Thiessen:
Using a tool. And you almost have to, like, get to know this other person, and then that person gets upgraded, and you're like, okay. What? Can you do things better now? Like, oh, okay.
Michael Thiessen:
You're better at this, but you still suck at this. Okay. Cool. Yeah. Like, now I know that I can, like, work around that a little bit.
Justin Schroeder:
Yeah. I I really like to thinking about what AI does for you, it's very much like photography. And go with me for a second here. Like in the early days of photography, what made you a photographer was having a camera. Okay.
Justin Schroeder:
And then cameras became more popular. And so being a photographer was like doing a good job of having expensive equipment and using it effectively. And then
Michael Thiessen:
Be able to focus.
Justin Schroeder:
Yeah. Sure. And like now everybody has cameras and the cameras themselves are excellent across the board. Like you don't even have to be a good photographer to take good pictures. So then what does being a good photographer mean?
Justin Schroeder:
Well, it boils it down to the essence of what it was in the very first place, which was like capturing an important moment, which is about being in the right place, having the right idea, like being there with the right tool at the right place for the right moment. And seeking like knowing how to seek those things out. It's a much more like all it's a it's a much harder thing to do, honestly. Like go to, I don't know, the war zone or the poverty stricken area and taking those important photos is what it means to be a great photographer now. Or even if it's a wedding photographer, like, knowing how to deal with the pressure of that moment.
Justin Schroeder:
I I shot 3 weddings, and they're horrible because it's like that that moment that they're gonna kiss is the only time in history that's gonna happen. You can't be like, hold on a second. Could you do that again? No. You gotta capture it at that moment.
Justin Schroeder:
Right? So Yeah. So, like, that's what it became to become a photographer. That's what it means now. And that doesn't mean that being a photographer is any less valuable.
Justin Schroeder:
It's just a little bit different. And in some ways it's even more valuable. And being an engineer is a similar thing now. We're boiling away like for a while what it meant to be an engineer was somebody who had a computer because it was all engineering. And then what it meant was like, okay, well now you're actually good at writing code.
Justin Schroeder:
And now we're realizing it's actually not so much about the syntax. It's about the way you break down a problem. And the syntax is becoming less and less important. And what's becoming more important is how you solve problems in the real world, which is what engineering is supposed to be anyway. So, yeah, I would just encourage people to to jump on and and start using it.
Alexander Lichter:
I think there is a a really good article from Adios Mani, who's working at Google. Probably a lot of people at least some people know know the name rings a bell, called The 70 Percent Problem, Hard Truths About AI Assisted Coding. I really think AI is a tool, and I agree with the article to to large, or, like, to some degree at least, that it doesn't improve the quality of the code necessarily because it learns from, well, all the code that they're there, and it's usually not the best. But you have a really good velocity with that. You have a really good pace.
Alexander Lichter:
But now I see usually I being used as one extreme or another, like, not at all or, like, tap tap tap tap tap tap and cursor. And, like, don't care. Tap tap tap doesn't work. Again, let's let's try something different. Or, like, okay.
Alexander Lichter:
This code doesn't work. Somebody posted, and people like, hey. We got this from here. ChatGPT said it should work, or something like that. So it's either full on the AI train.
Alexander Lichter:
I just built my whole business with AI, my whole SaaS, whatsoever, my whole product, Or yeah. No. Not a no AI at all. I think the, like, the middle way of, like, okay. Use it use it as a tool, and use it where it makes the most sense.
Alexander Lichter:
Like, I use Copilot, for example. I don't use Cursor, but I use Copilot a lot while coding, and it helps a lot with velocity. I still think about the code that it's generating, and everybody should everybody should double check that. It's a bit
Justin Schroeder:
Yeah. Definitely.
Alexander Lichter:
Like, you can't just say, like, okay. Whatever is there is fine, because, okay, if it doesn't work, you might see that for the happy case, but you won't test the edge cases as, like, a lot of developers don't. Maybe maybe you just missed one. So it's really focusing on on the architecture more and, yeah, reviewing the code. Treat treat AI a bit like the junior developer that just does things for you, and you tell him, oh, hey.
Alexander Lichter:
That's different. I want it differently, or, hey. That's not good code. So it's it's really about how you use it, and don't go to either of the extremes, I would say.
Michael Thiessen:
And one use case, like, is also, like, architecture, like, not having it write the code, but, like, for example, I wanted to implement a feature one time, and and I needed to update my database schema to do that. And so I'm like, okay. I know how to do database schemas, and I kind of understand joins a little bit, but, like, I don't really know. And so, like, describe the problem a little bit and say, here's what I've my current schema looks like. Give me 3 different options, and, like, list out, like, some pros and cons for each.
Michael Thiessen:
And then I go through and read that and say, okay. First of all, does this actually make any sense? And usually, like, usually it does these days. You know, that's that's one thing that's also challenging is that AI is, like, every few months getting so much better that if you tried it 6 months ago and it was weird, it's probably way better now.
Justin Schroeder:
That's true.
Michael Thiessen:
And and makes way less mistakes than it did before. But, like, I'll go through that, and it gives me these 3 different options, and then I can see, oh, this way is kind of interesting. I wouldn't have thought about that before. This is the way that I was doing it, or I was thinking about doing it anyway. And then there's this third option, and I can kind of like, oh, maybe I like this idea from this one.
Michael Thiessen:
I can kind of incorporate that, or you can, like, chat a little bit back and forth and say, well, what if we tried to do this? Or, actually, I don't like that, but this part and then it kinda comes up with some ideas, and then you can say, okay. Now I've got some, like, better ideas that I can work with, and I'm still deciding. I'm still the one making the decision and thinking through, like, okay. Of these three solutions, what actually makes the most sense?
Michael Thiessen:
Because I'm the one that knows the entire code base and how it all works together. And
Justin Schroeder:
Right.
Michael Thiessen:
You know, the future where I'm the next features I might wanna add or whatever else you might take into into consideration there. And but it can help you, in a lot of different ways.
Justin Schroeder:
Yeah. And and the big one to me is using it to actually solve, not just like having a help with the code, but having it be part of the solution to your problem. So these APIs are out there. You can plug AI into almost any problem you have and amazing things pop out. It reminds me of the early days of HTML5 and CSS where we didn't know what what we had in our hands.
Justin Schroeder:
And we were all just trying to figure it out. Like, it's interesting. Media queries existed way before responsive design. Well, way before, but significant amount of time before responsive design. Right?
Justin Schroeder:
And it took Ethan Marcotte basically being like, hold on a second. I could make the same website work in both places. I don't need to create the 2 websites. That idea was already or the the technology was already there. It just needed a human to come around and be like, let me bridge the gap.
Justin Schroeder:
Let me come up with the idea. It's like we have all been given that opportunity right now. Like, if AI doesn't get any better from where it is right now, there is at least $3,000,000,000,000 worth of companies to be built on what currently exists. What currently exists. We don't need AGI or anything else.
Justin Schroeder:
Like what exists right now is enough to help your business solve its problem. And so and like as engineers, that should be part of our our palette. Like, we should know when to reach for that tool versus some other tool. And so that's what I would encourage people to get involved with too is, like, start playing with this stuff and figure out how to make it solve, your business's problems or your technical challenges. That really doesn't have much to do with FormKit. But
Alexander Lichter:
Well, I mean, it's it's a nice it's a nice bridge to, a little section in the podcast that we, wanted to introduce just for you, because we, like, we we mentioned you here and there also in the episode of Evan You because you have, quite some hot takes every now and then. So, with this little segment, and we'll we'll just call it Justin's hot takes. Let's just throw in some, like, some keywords, some topics, and then just, discuss maybe hot takes you have in mind, just, like, suit your opinion, on these topics, and then just, like, see how many we can can
Justin Schroeder:
Oh, you've got the topics?
Alexander Lichter:
Yeah. We've got the topics. We'll throw them at you now.
Justin Schroeder:
Throw them at me,
Alexander Lichter:
You have the hot takes
Alexander Lichter:
I'll have to smack them.
Justin Schroeder:
Alright. Let's go.
Alexander Lichter:
Yeah. We we can start with a very simple one. Vue in 2024.
Justin Schroeder:
In 2024?
Alexander Lichter:
So last year.
Justin Schroeder:
Yeah. Vue in 2024.
Alexander Lichter:
Yeah.
Justin Schroeder:
Okay. My hot take on that is that Vue suffered a little bit in 2024.
Alexander Lichter:
Interesting. Why that? On what in which way?
Justin Schroeder:
It suffered because there was no big hotness. Right? It was just stable and working and doing its job. And there was a lot of really big hot things out in the world. Right?
Justin Schroeder:
There was, Svelte 5 and runes and solid star shipping and all of this other stuff that was happening in the world. And Vue was just chugging along like a like a good worker. And so from just a public perception, I think that, you know, that it was it actually struggling? No. But that's I think that's the perception.
Justin Schroeder:
And in reality, I think eventually people will enjoy the stability. But, yeah, that's what I would say about Vue in 2024.
Alexander Lichter:
Interesting. I think so based at least on there are a lot of surveys, of course. But based on state of JS, actually, people were really happy in terms of retention positivity with Vue this year, not as happy as, like, Vue 2 times. So
Justin Schroeder:
Because it didn't change.
Alexander Lichter:
Yeah. Exactly. Because of stability, because the people who were churned by you 3 or maybe, like, just had to get used to that, at least that would be my Internet. They're happy with, hey. It's there.
Alexander Lichter:
It works. The ecosystem, especially, I think. And and PhoneKip is a big part there, but also other libraries like Inspira UI, like motion-vue, Framer Motion now being available for other JavaScript frameworks, more framework agnostic stuff to bridge the gaps to say, okay. We don't have, like, an ecosystem that, let's say, hangs behind that much. Of course, there's still some parts that that could, like, be improved always, but to have to feel like a bit more whole as a Vue 3 ecosystem.
Justin Schroeder:
Yeah. I mean, I would say that, like, my hot take for 2024 is that it seems like it's not doing well. And my hot take for 2025 is I hope it keeps doing that. I hope it doesn't need, like okay. Here's here's a hot take.
Justin Schroeder:
This might be on your list. I'm not that jazzed about vapor mode.
Alexander Lichter:
That is on the list of course. Yes.
Justin Schroeder:
I'm not that jazzed about it. And I've talked to you some about it, Alex. But and it's not because it's not technically amazing. It is technically awesome and it's very much the right direction for a framework to move. My hot take on it is that it undoes a little bit of what's been done over this period of time.
Justin Schroeder:
Not because it's incompatible. There's no like, thank goodness, there's no, like, big incompatibilities coming. It's just another way to do things. And so my hot take on that is less ways to do things that are better.
Alexander Lichter:
I wouldn't even say that's a hot take, like, in general. I I think, like, when we think about how many ways there are to write a component, like, we probably could find 5, 6 ways. But Yeah. The usual way, like, we say, without any libraries, like, Vue Vine in there, by the way, recommended if you wanna have multiple components in one file Or, like, I don't know, the template option for when you use it with a CDN. There are a few last of, like, okay, options API, composition API with out script setup, which nobody should do anymore, and composition API with script setup, which is the recommended way.
Alexander Lichter:
Then we have, like, okay, Vapor, which is like the composition API, but also not feature parity yet. So, yeah, I see where this is going. Though, I guess, in a way, it's also like, at some point, there will be feature parity, and, hopefully, maybe at some point, the options API can also be used in vapor mode. Nobody knows if that will be the case or not. But at least the composition API, there there should be feature parity except things that are not needed, like v-memo or something, which ideally, when vapor mode comes out, there is less friction for the end user.
Justin Schroeder:
I think the friction for the end user, the friction won't be there. There's going to be this long period of time where people like me and, you know, other library maintainers are feeling like like second class citizens until our libraries effectively support vapor mode as a primary thing. So I think that that's you know I just think less ways to do things is good. And at the same time like I get it like I get it because if I was maintaining Vue I would be doing the exact same kind of thing. This isn't a dot at at Evan.
Justin Schroeder:
You're gonna get me crucified, Alex. Come on.
Alexander Lichter:
No. No.
Michael Thiessen:
It's also like it's a feature that's I thought you were going this way with the Vue in 2024 one where there's a it's a marketing problem where if you didn't have anything flashy or exciting to get people excited about it, and vapor mode is exciting, but also it's not exciting in that. It's like, oh, you just flip a switch and it's faster, but how much faster does my Right. View code actually need to be rendered faster for a lot of people?
Alexander Lichter:
Doesn't matter.
Michael Thiessen:
Yeah. Doesn't they don't need that. For the people who do need it, they're like, yes, give it to me now, but, like, it's not like the composition API or, like, some other new, like, defined model. It's gonna make your life every day is gonna be easier because of this new feature. It's just like a yeah.
Michael Thiessen:
I flipped that switch a couple months ago, and I guess our metrics are better, but I haven't looked at them in a while. So, you know but, again, I agree with you. Like, this is the way the framework frameworks have to get faster and leaner, and you can't just like.
Justin Schroeder:
The amount of time and effort that is being spent right now to shave microseconds off of framework times by the collective world is it's very significant. And I really don't I don't want to diminish how important performance is and that effort is because it is important. But I also have felt it on the other side, which is when somebody as a maintainer, when somebody comes to you and says, hey, this isn't performant, it's like I don't know what it is. I don't understand this, but it's like somebody sticks a burning spear directly into your heart. And and it's it feels awful.
Justin Schroeder:
And so I get why the maintainers are in this, like, little battle thing that keeps going on. And every time somebody's like, hey, look at this one. It's a little bit faster. Then there's always counter articles being like, well, actually, you didn't try it in this way, you know?
Michael Thiessen:
And it's like the worst insult as a developer.
Justin Schroeder:
It is. It is. It's like the worst insult. Yeah.
Alexander Lichter:
But it also sparks, like, innovation. For example, we've seen with Johnson.
Justin Schroeder:
It does.
Alexander Lichter:
Yeah. It's it's crazy.
Justin Schroeder:
It's it's so it's like this good thing. And it's also this, like, kind of weird frustrating thing because as a as a consumer, I am also intrigued by it. And so like I think one of the reasons that it hits me so hard is like I know how much I actually do calculate that into my mental decision making when I'm choosing a tool to use. Not because of the metrics at the end of the day, because the metrics on all of these things are great nowadays, but more just like, well, you know, solid is really fast, but Svelte 5. Oh, yeah.
Justin Schroeder:
And maybe for my next project, I'm gonna pick Svelte 5 because it was faster.
Alexander Lichter:
Based on some arbitrary benchmark.
Justin Schroeder:
Yes. Exactly. And so that we're in a weird place with all of that. And so I understand how Vue Vapor is, like, important because it's an important way to show that the concept of Vue is compatible with blazing fast everything. Anyway, more hot takes.
Justin Schroeder:
More hot takes.
Alexander Lichter:
I I think also, like, just just to add there, it's also a way to show that Vue is still relevant. Isn't like, okay, we're keeping up with the trend, quote, unquote, trend of, like, signals now also in the template. So that's also an way apart. Plus, I can see at least a niche part of applications where this is really useful, for example, data visualization, huge entries of, like, data tables and whatnot. So there is benefit.
Alexander Lichter:
Is it for the 80% case? Probably not because it doesn't matter if a landing page is, like, rendering 10 or 11 milliseconds on the browser. Right. And Vue is already the fastest SSR framework, at least given one benchmark out there, so that's also good. But that's a that's a different story.
Alexander Lichter:
Michael, wanna pick a a topic there regarding Yeah.
Michael Thiessen:
I think we got time for a few a couple more hot takes here. And then, so how about Tailwind? Do you have a hot take on Tailwind?
Justin Schroeder:
Oh, I did.
Alexander Lichter:
You did?
Justin Schroeder:
My hot take on Tailwind was that it was hot garbage. And not even that it was hot garbage. It was actually a really well made poison for the ecosystem.
Justin Schroeder:
And I have decided that I've lost. That's what I've decided. I still think it's a little poisonous.
Alexander Lichter:
Why?
Justin Schroeder:
But I'm like but I'm just like I also didn't like Prettier and I don't like I still don't like the way that Prettier formats my code, but it's like I lost the battle, so I'm just gonna embrace it. So I've decided I'm just gonna embrace Tailwind. I use it on everything. My I've swallowed my pride and I'll just go with it. And there's some things I like about it, of course.
Justin Schroeder:
And here's what I don't like about it. What I don't like about it is it caused all component libraries and everybody to stop shipping DOM elements. And I think that this was really bad. There used to be a day where your component libraries shipped the DOM elements. And that was good because it meant that accessibility and these other problems were located in one spot.
Justin Schroeder:
We could fix them in one spot. Now everything is headless. Everything is headless. It's almost like very, very few people do what we're trying to do and ship the DOM elements. And the reason is you can't get your style classes on the DOM elements.
Justin Schroeder:
Right? If you ship them more than 1 layer deep, you need to now provide some mechanism to get them down there. And there's tons of like everybody invents their own. There's no standard. So there's no like, you know, like for for us, we do it based on we we name every single DOM element in form kit.
Justin Schroeder:
Every single one has its own add address or name. So it'd be, like, you know, the the wrapper, the inner, the input, the help, the description, whatever. Oh, they each have their own. And so it's like that dash class. Right?
Justin Schroeder:
So, like, input class or whatever. And so you can put them all on the outside, or you can write a reconfiguration object for it, whatever. But because there's no standard for it and there's no, like like, really somebody should come up with an open source standard that all libraries can can choose to adopt for how to handle this problem. People just don't ship inputs anymore. And instead, headless has become the thing de jure.
Justin Schroeder:
And I think that is almost entirely driven by utility classes. Not entirely, but almost entirely. So that's that's my gripe about it.
Michael Thiessen:
I've never heard that one before, but I that makes sense to me. And so there's 2 things that I've realized recently, some drawbacks to tailwind. And, generally, I love tailwind. I've been using it for years in all my projects and all that. The first one is that it's not good for technical education, and so because I've used it all the time, I just have it in all of, like, the the code that I write and the code in my courses and in my blog posts and everything else, but it's really distracting.
Michael Thiessen:
There's a lot of, like, extra things on the screen that don't need to be there when you could just have a single class name and then, like, hide away all of the CSS and styling stuff when you don't need it on there. And I've gotten, like, lots of feedback on that in in the past, and so I've decided recently that for education, I'm not gonna use Tailwind just to, like, simplify what what people are seeing. The second one, which I haven't confirmed and need might need to do some more experimentation with this, but I think the AI struggles with tailwind partly because you have to output more tokens to get all the the styling on your on your elements, but also I think there's an issue with consistency because, I mean, you can solve this if you, like, encapsulate different components and stuff like that. But if you have an entire app, let's say, and you want to update the styling for that entire application, AI, you basically have to rewrite every single file or edit every single file in multiple like, every single class tag has to be edited Yeah. To update that.
Michael Thiessen:
Whereas, if you had, like, a single style sheet, you could just output those style sheets that need to be changed. And so I suspect that, yeah, if you switched to a less tail and more just like vanilla CSS, it might be more effective with LLMs, but, yeah, that's that's not a strong conviction yet because I haven't actually tested that one that one out yet.
Alexander Lichter:
I have I have a few takes on it as well. I think it's pretty interesting, like, especially education part as I also use Tailwind in most of my examples, workshops, and so on. Think if you really just wanna say, okay. Let me remove that part from the template because it's distracting or it makes the the lines, like, 500 characters long, you could technically still use at apply and saying, hey. In a real production code, you would write it there.
Alexander Lichter:
So you could still stick with, like, your design system whatsoever, but then people are like, hey. WHat is this @apply? And so and so I I kinda understand, like, especially if you're not focusing on CSS. Just say, like, hey. Here's some content.
Alexander Lichter:
I get it. The vanilla CSS part in AI is pretty interesting because if you would write CSS for your components, then you would still have that in the components with scope styles. Yeah. So that would probably have the same issue unless you say let's say I don't know. I I talked about it, I don't know, a month ago or something where you say, like, let's define headings and typography and have an own component that says, hey.
Alexander Lichter:
I have a heading. And I can say the heading has a specific semantics, so, like, h one to h six. Right? Or, like, a paragraph or diff if you yeah. As as an escape patch, which you never use.
Alexander Lichter:
And it has a specific look. So it can look like an XL heading, a superheading, I don't know, a subheading, whatsoever. And if you have that all and you want components, say, like, I wanna change all the headings on my application that use that component, it's possible, but it's it depends on how your architecture is side, of course. If you use Tailwind to just, like, say, okay. I describe all my h1s in the same way.
Alexander Lichter:
Ideally, you have some kind of abstraction, and Tailwind, of course, delegates that over to component framework.
Justin Schroeder:
I think Tailwind is a massive success because React didn't have scoped styles.
Alexander Lichter:
That's a hot take. Like, that's it. That's that's the hottest hot take so far, I would say. That's Yeah.
Justin Schroeder:
I think that's that's what made it take off. And then once it reached a critical mass, everybody else, like, just kind of adopted it. You know what I mean? Like, in Vue, I think the use case is smaller than in other places, but it's still I mean, it's fine. It's fine.
Justin Schroeder:
I've written
Alexander Lichter:
You accepted it.
Justin Schroeder:
Several sites now in it. And Yeah. Actually, FormKit ships tailwind styles now. And we even have a tailwind style editor where you can, like, you can generate your own theme and then download it. And it's all tailwind.
Justin Schroeder:
And so I'm on team team tailwind, but I do think it was a little bit of a step back for the library ecosystem, unfortunately. And I don't really see a way to resolve it, unfortunately. It's except maybe a massive effort to get on board with a standard.
Alexander Lichter:
On the note of the headless parts, I would even ask, is it that bad that component libraries don't ship the DOM elements anymore? Basically, here's your functionality. Here are, like, recipes that you can copy, own the implementation, and do it yourself. And if they're, like, functionality wise problems, let's say how headless UI, for example, is doing that, which is also from from Tailwind Labs. Right?
Alexander Lichter:
It's open source libraries. Okay. You can you can copy that, like, out of this box item. And if something breaks, then we can fix it. And as you said before, you get the the fixes, like downstream as an end user.
Justin Schroeder:
I mean, my opinion is yes, it is bad. And I think, of course, headless UI that and it's a very small little library, headless UI, but it's put out by the Tailwind team because this is the problem. All previous UI libraries were almost impossible for Tailwind users to use. They couldn't use them so they needed 2 design systems. And so that is what really gives rise to it.
Justin Schroeder:
There are some benefits I think to headless. I'm not going to say the whole thing is trash. I particularly like it when the stuff that you're doing doesn't have DOM related to it. The problem is these like component libraries are mostly DOM. And you're putting the burden of doing a lot of the accessibility work back on the user.
Justin Schroeder:
Not entirely, but most of them. Because there's so many data attributes and other kinds of stuff that needs to go along with that. So the user is response it's fine. If you go to the headless UI website, a lot of their examples are not accessible. There are examples aren't.
Justin Schroeder:
Yes. Because they're not doing these exact things. And this is true across the board. Like if you go and look at headless component libraries and you look at their accessibility specifically on their form elements, most of them are not accessible because to make them accessible would require putting tons of different data attributes throughout there, and they don't wanna do that on their examples because it muddies it up.
Michael Thiessen:
But but can you just
Alexander Lichter:
in the component itself, like, in the list box, element or list box item that you, like, basically
Justin Schroeder:
could, but you're responsible for writing the list box element.
Alexander Lichter:
No. No. This this is also was shipped by Headless UI. Right? Like, they have, like, a, let's say, a list box.
Alexander Lichter:
Like, they have certain Vue components that you can still basically inside that list box itself, you can put, like, some of those elements, dividers, whatsoever. So in a way, there is accessibility based on that built in, if you have it like that. There are
Justin Schroeder:
there there's definitely some there's definitely some of the features of these things built in. And it particularly happens when the DOM element, whatever the DOM element is that they're shipping, is part of the thing that they're shipping.
Michael Thiessen:
Yeah.
Alexander Lichter:
Right. Of course, everything custom you have to deal with yourself. That's that's true. That's absolutely correct.
Justin Schroeder:
Which is the real value of headless. Right? That's the that's the primary value of headless is that you get to provide your own dump. Like, there's a time and a place for it, but I don't know.
Alexander Lichter:
I mean, especially if you say
Justin Schroeder:
That's my opinion.
Alexander Lichter:
If you say that list box, let's say, option or list box options components, they are unstyled and you could style each of them, then you have, like, that at least how how conceptually what my understanding of that. They just say, okay, if this box options basically, okay, you have, like, a UL or L whatsoever or however it's, cemented correct, then you have the list box option. You can dial you can provide whatever you want around that. So you have the semantics and the accessibility inside of components based on what you provide also as data and everything around you can style. But, of course, it it depends also in library how well this executed, and that once again puts the the part to library.
Alexander Lichter:
But
Justin Schroeder:
There's a lot of yeah. There's a lot of that kind of stuff that goes into it. I mean, I will say, headless UI has done an admirable job of trying to be accessible across the board. Like a very admirable job. Most of the stuff is very, very good.
Justin Schroeder:
But there are places where the burden goes back to the user. I don't remember them off the top of my head. We did a whole audit of this stuff at one point.
Alexander Lichter:
But the user is also not aware if Yeah. Okay.
Justin Schroeder:
There are places where the burden goes back to a user to put those kinds of things on there, right? And then that's where things get sticky. I mean, it's sort of true across the board. It also is a pain for the user. So the the solution is you what you mentioned is you give people a version of all of the code ahead of time, ShadCN style, and then it's up to them to choose how to, like, put all that together.
Justin Schroeder:
That's sort of like the solution to the problem of headless being a pain. The problem is that's also a pain. I have talked to so many people that have used ShadCN that really don't like it. I have yet to actually I have yet to find somebody who actually enjoys it. Do one of you guys enjoy it?
Justin Schroeder:
You'd be my first.
Alexander Lichter:
I didn't use Shad cn in particular, but Radix or, like, also Nuxt UI is doing the thing pretty well. Yeah.
Justin Schroeder:
Okay. Yeah. I haven't I haven't tried Nuxt UI Oh,
Alexander Lichter:
you should.
Justin Schroeder:
Since they did since they did that, the whole raid x thing.
Alexander Lichter:
Also, v v three alphas Tailwind is I think when this episode is out, Tailwind v 4 is released already.
Justin Schroeder:
So I know. I'm actually excited about that one. I think Same. It's a good update. 100%.
Justin Schroeder:
It's a good update.
Alexander Lichter:
Making making things simpler.
Alexander Lichter:
Justin, we have a lot of other hot takes on the list, but time is is running, unfortunately.
Michael Thiessen:
So many hot takes.
Alexander Lichter:
Of course you have to come back on. Maybe we we even just do a whole hot episode. We're doing a giant hot takes.
Michael Thiessen:
That would be fine.
Justin Schroeder:
Yeah. I'm gonna yeah. People are gonna be so mad at me again.
Alexander Lichter:
That's fine. That's fine. Let it explode again as long as nobody calls you, you know. Oh. Let's let's keep it there.
Alexander Lichter:
Only good vibes. Everybody, comment your hot take somewhere on social media, and follow Justin. Justin, where can people follow you, actually?
Justin Schroeder:
You can follow me on x, @jpschroeder, or bluesky jpschroeder.com.
Alexander Lichter:
And, of course, check out formkit & kickstart. All Links in the description to everything. Justin, thank you so much for taking time and talking about
Justin Schroeder:
Super fun, guys. Thank you. I really appreciate it.
Michael Thiessen:
Thanks' for Coming on.
Alexander Lichter:
And for everybody, still not at the latest episode. So if there's a new one, check it out. Otherwise, the older episode, we have amazing episodes there, predictions, other, well, so to say, hot takes, but also some recaps, and talking, of course, about Vue and the whole ecosystem. Thanks, everybody, for listening, and, see you all soon. Bye bye.
