Fabian: all of us want to build like the best possible solution and win as many users by building something like standard schema and improve the web and our community in general.
[00:00:28] Introduction
Andrew: Hello, welcome to Dev Tools fm. This is a podcast about developer tools and the people who make 'em. I'm Andrew, and this is my co-host Justin.
Justin: Hey everyone, uh, we're really excited today to have Fabian Hiller on with us. Uh, so Fabian, you, uh, are the creator of Valibo uh, and. Formisch. And you are also one of the co-creators of Standard Schema, and we're really excited to chat about that. But before we dive into our topic, uh, we'd love to just hear a little bit more about you.
So would you like to give us an intro?
Fabian: Thank you. Um, yes, I can do that. Um, yes, the most know me about, um, the work I did, um, for valibot Formisch and a few other things, and my involvement in open source. Um, besides of that, I work as a software engineer. Um, I'm originally from Germany. Um, before I went to college, I started two companies, one kind of agency or service business.
And then, um, about two years later, a startup where we helped influencers sell advertisements. And then later on I went to college. And I always did many, many things on the side. I produced video courses, um, for, I think it's the largest IT publisher in Europe, um, where I teach htm CSS, tailwind, bootstrap, and many, many more things Also about design and components, which was back then, I would say still a newer topic.
And yeah, and I got slowly involved, um, into open source. I was probably one of the earlier React users. Um, I built a really huge application on top of hooks while it was still in beta. And I always loved the community. And then at some point I felt ready to give back or contribute and build my own projects and.
The first public project was modular forms that some maybe know. And then, um, that was also kind of my intro to um, um, Ryan Kado, the Creator Solid Chairs, and also then later on my intro to Ms. Khari Decorat of Angola. And that's how everything started. And then valiBot, I made some good decisions when building Valley Bot.
Also, of course had a little bit of luck and, um, valiBot, um, became really popular really, really quickly and it's now, um, probably, um, among the most popular schema libraries and yeah. And, um, last year I somehow ended up building a form library. But yeah, we can talk about that, uh, later. And yeah, I live right now in New York.
Um, and I, I think that's probably the most important information.
Andrew: Yeah.
[00:03:45] The Birth of ValiBot
Andrew: So I wanna dig into why you started Vali Bot and like, uh, where it came from. So, while I was doing my research for you, you actually did this as part of your bachelor's thesis, which before this, I didn't even know there was a thing as a bachelor's thesis. So that's interesting. But I also found it interesting that like.
They let you focus on like open source library work. So can you kind of tell us how that all came together?
Fabian: Yeah. Um, so my initial idea was to write a thesis about education. I was really heavily in education, for example, with the video courses I created, but I also did a lot of YouTube before that. Um, and I'm also part of the student shift film. Um, that's, um, that's an organization from Germany that, um, sponsors, um, a really small part of students with like, excellent, um, performance.
And there, there is like a really specific application to get into and as, and one part is to hold a presentation. And my presentation there was about education. And I think I have, and back then had many, many great ideas on how, for example, education in Germany, but maybe in the world in general could be improved.
And so that was my initial idea for the Bachelor thesis. But um, it turned out to be really, really hard to get like the best people in the world, especially entrepreneurs, to supervise the thesis. I really tried hard. To get to them, but they're often busy with other things and have probably not a huge benefit in doing that.
And so I thought, okay, maybe let's go in a completely different direction. And this direction was open source because I was already heavily involved in open source and I, yeah, worked hard to build up a network. Um, it was not intentionally, it just happened because I guess. Work was okay. And that's how um, I ended up asking, um, Ryan and Misko to super my, to supervise my bachelor thesis.
They both knew each other and after I could, um, um, convince one of them the other joins, so that was great. Um, yeah. And then, um, I came up with a few topics. Then at the end, um, we kind of decided that, um, building a schema library could be, um, the best scope. Um, I also had ideas about improvements for solid shares and improvements for quick, but, um, the batch thesis has like a scope of about three months, and if you, some people maybe only do research and then bring it together, but I, I had to.
Do research, I had to implement a library and then have to write everything down. So, um, three months timeframe, um, looked great for this idea. And, um, the reason, um, why a schema library was probably that I was probably among the earlier, so users. And I saw a huge potential, potential inside, and I also used it heavily, but since I was also, um, looking at that time into solid shares and other solutions, um, that are in general more efficient, usually with a smaller bundle size, but also with the faster runtime.
I also look for ways on how we could reduce, um, so, and make it smaller. Do not like pull up the bundle. Um, of course if you have like next chairs, as in like a huge component library, at some point it doesn't matter. But if you have a really, um, um, if you have a really, um, slim setup, for example, solid chairs, then um, sort quickly doubles the bundle.
And so there were the idea on investigating if it's possible. To reduce the bundle size, and that's basically my bachelor thesis. I prove it on top of a schema library, but the thesis is mostly, or partly written in a way so that it could be applied to basically any JavaScript library. And we also saw this movement, um, for other libraries like, um, um, a few years ago.
Firebase, we wrote their library in a mostly module pattern and a few others, um, tried or did it too. And I hope I could also inspire some people to look into that. And, um, in simple words to outcomes or two insights from the thesis was that, um, you could achieve smaller bundle size, um, by either, um, building a modular architecture.
Or by using a compiler, there is a third option. But that depends on a pre-processing step. It's basically maybe almost like a compiler. But, um, for example, if we would go beyond what roll up or roll down of four, three shaking, you could also load a bundle size. But yeah, that's, that's another topic. I know that some, um, tech companies like Google, they have their own compilers that partly does that.
But, um, if you. Um, like, um, split off class, um, um, methods and so on, that gets risky and that's why you need a lot of tests to make sure that you don't break anything. And that's why probably most popular bundles don't go that far right now. And yeah, and that's kind of how BOT started. And based on the research I did, um, I implemented the library and then.
I think before I actually started writing the thesis, um, announced it together with my supervisors and we got a lot of traction on XI think more than 500,000 impressions, probably even more because um, other people we posted it on match their own posts on top of the announcement we did. And yeah, that's how we got traction and a lot of feedback.
And while writing my thesis. The library involved a lot because, um, people, um, recommended improvements. Um, and yeah, that's how kind of, um, it all started.
Justin: It is awesome to have a thesis that you're writing where it's like you're not doing a thing just like in a hole. You're just like researching by yourself, trying to figure something out. You have like a bunch of people coming in. I mean, and I know you usually have an advisor, but it's cool to have external folks pitching in also, I'll say I've read a few, uh.
Um, different people's thesis in my time, and they're not always the easiest thing to read. I feel like academic, uh, papers in, in general, like some of them have this quality where it's like hard to read, but like, yours is very delightful. It's like the best read me like for, for like, you can really sit down and kind of understand the scope and like the domain and like how it's built and everything, and it's just so.
Easy. And that's, uh, that's pretty huge. Uh, so props for that.
Fabian: Yeah, thank you. And I think that's actually like the hardest part explaining, um, for some people complicated, uh, things really easy so that even someone with no or less background or context can understand it. Um, and I think that's something I try to do with all the work I do and publish. You probably see this pattern in the source code, but also in the repository.
I try to keep things clean and simple, but I'm still high professional and with high quality, and yeah. Thank you. Thank.
Justin: How did, uh, how did Misko and, uh, Ryan in influence the sort of design of the app or your thesis? Like what, what was their role and like how did they help shape it?
Fabian: Um, you talking about my supervisors?
Justin: Yeah. Yeah. Your supervisors when, when
Fabian: Okay. Um, I would say, um, the way I work is mostly very independent and. That also makes sense and is important if you work with people like Rhino because of course they have also a lot to do on their own. Um, so I basically, um, checked in with them regularly and updated and we had a Discord chat together and I think we had like two or three calls where I updated them shorter results.
And then got feedback and besides, um, and of course they then read the thesis and also reported back to my university. But besides of that work, maybe the even more important part was, um, publishing the library and doing work on social media. Um. Yeah, because that basically met the, the work and the library visible to others and basically started this whole open source project or movement.
Andrew: I think, I think, uh, I was on Twitter at the time and I saw a lot of Val Bot when you first were advertising it. It was all over the place. Um, but let's drill down into, uh, a little bit of the u uniqueness of the library. Uh, you said that it's like 95% smaller than Zod, that's a huge difference in size. Uh, what like design decisions did you make to like, make that possible?
And why wouldn't it be possible in something like Zo?
Fabian: Um, the main reason, um. So for, for volley bot is that Mar Volley bot builds on a modular architecture that basically means, um, every function has only one functionality and multiple functions can be combined with an, um, tooled out IPI design and. In really, really simple words, when you use Bali bot, you only import what you use.
And because imports, um, are treated static, they can be tree shaking at build time. And that means any, that code that would never be executed can be removed. And because of that, um, in most cases, the bundle that Wally bought. Add to your JavaScript bundle, and we are talking about the library bundle, not Dakota, right?
Um, it's probably around one to two kilobytes, even through the library in total is probably around 10 or 11 or 12 kilobytes. And the library is also implemented, extremely consistent. And for example, if you use the string schema that adds. Probably around 400 something, maybe 500 bytes. But if you add the number schema, it probably only adds like 50 to 70 bytes on top of that.
Um, because we not only focused on the modularity, we also focused, uh, on being able to have, like, achieve a high compression rate when bundling, um, or when G zipping the LI code.
Justin: So it's like using the same dinner. Fires and trying to do things to make sure that it's like internally consistent, I suppose.
Fabian: Yeah, so I would put it this way. When you build a modular library, the, the start is the hardest part because there you have to figure out how you can combine or connect the individual building blocks. So what contracts are you using? And because a modular architecture forces you on think a lot about that in the beginning.
Um, your API if you don't screw it up becomes kind of automatically, um, somewhat consistent because, um, you need to design it in a way that every building block can basically be replaced. And that's what is possible with Value Bot if you don't like how an action works. Just copy it over, change it, and put in your own code.
And that's really simple. And that's not that simple or not possible with other libraries that are maybe built on like classes. Also object oriented. 'cause it's way harder to insert anything into.
Andrew: So one of,
Speaker 6: sense.
Andrew: so one of Zos major selling points is the TypeScript integration. Uh, I think that's why the API exists as it is, it uses the TypeScript builder pattern. Which is used in a lot of different other libraries to get, uh, like really, really nice types. Uh, does Vebo have something similar? Like do the type, does TypeScript work in a similar way with the library?
Fabian: Um, yes it does. Um, but we need to distinguish here. So what are you referring on? Like the types reproduce or are you referring on like the um, DX when you like type?
Andrew: A little bit of both.
Fabian: Okay, so one of sorts creators benefits is um, maybe also the reason why vali bot is so popular, and that's what, as you said, a buildup pattern.
Where you basically chain methods. The cool part with that is if you call a method, you can write the library in a way that it, um, knows its own context. And if you put a dot, then it only then types script will only recommend the things that are actually available and make sense. And that's really great because that allows many users to use that without.
Reading their documentation or do a lot of research because they can just start with like a basic type like string, um, enter a dot and then see what's available. That's a little bit different with Value Bot because it's a modular library. Um, so, um, there is a little bit more effort necessary. Um, we could solve that with an VS.
Code extension, but so far, um, there was not. Enough in sentence. I'm not sure if that's the right word to do it. Um, so I think, um, this would be solvable also with modular Library, but with more effort and, um, yeah. And um, for Modular Library to get pretty close, it's super important that you have a really simple and strong mental model for Volley Bot.
Um, we have a mental model with rebuilding blocks. The first are schemas that are basic, um, data types like string object, date, and so on. Then we have actions, actions, um, have other actions. They, um, can validate an already known type and for example, can validate their format. For example, we could validate, um, that a string matches an email.
They can also do transformations. They can also add metadata. And the third building block in Ali Bot are methods that allow you to use or modify a schema or action. And together, um, they allow to build complex S schemas. For example, uh, one of our most popular methods is our pipe, API, that basically appends a pipe to the first schema.
That you pass to the pipe and it's super flexible because you can say pipe string and then you can put whatever you want want after that, you can validate its format, you can perform transformations, you can append meter data, and basically the data flows through the pipe in a sequential way. And, um, that's probably also one of the.
Features P um, users love a lot about vali bot because it's highly flexible and I think, um, doing the same with, so in some cases is a lot more cucumber or what pronounced right? Yeah.
Justin: Yeah, I, I do like the examples are very legible and it's, it's nice, especially when you have messages in there, they kind of like stack linearly because it's just this, um, yeah. Pipeline of,
Fabian: Yeah, exactly.
Justin: cool. Um, wanna switch topics a little bit? So one of the, well. To tie this all back together, uh, one of the things that I liked about your thesis is you talked about the ecosystem.
You sort of acknowledged elza and archetype, um, and Tia, uh, I forget what the, the other one was. Um, and it was like, cool, cool to see that. View of the, the landscape and, and their trade offs and their performance and everything. Um, but it's, it's funny that now you've come together, uh, with uh, Colin and, and David bla, who's the creator of Archetype.
[00:22:30] Standard Schema Collaboration
Justin: So Colin's creator of Zod, and David's the creator of Archetype to sort of like do a mind meld and create a standard schema, which is, uh, this. Um, sort of unifying, uh, interface for schema libraries. And I'd love to hear a little bit more like, how did that come about? Like, 'cause it does seem like y'all, I mean, I don't wanna say are competitors, but like your alternatives in the same sort of space.
So you kind of competitors, so like how did that Yeah. How did that come about?
Fabian: Yeah, so, um, maybe it's good to know that even before standard Schema happened, I talked to Colin and also to David, and I think David even read my thesis in advance, or I at least exchanged ideas with him because I also looked at archetype and also had questions back then. So there was already, um, a con connection probably pure of like interest in each other and what we are doing and yeah, it's funny.
Of course we are somehow, um, competing with each other, but I think in like, uh, in like a cool way, I think all of us. Um, of course want to build like the best possible solution and win as many users as they can, but I do also strongly believe that all of us see the broader impact we can have by building something like standard schema and improve the web and our community in general.
And standard schema happened because, um. Column the creator thought mentioned the initial idea many, many years ago, probably now, four or five years ago. I'm not totally sure, but it's, I think it's mentioned in our readme or in our, on our website or it was mentioned. I'm not sure anymore because we probably updated it.
He read about that and that was the time I was building modular forms and I already saw an value in such a, um, unified interface. But I haven't started W Bot, and there was not a huge incentive in pushing that further. And I think about two years after he posted that, I picked it up again and talked to Colin because I saw a huge benefit for Value Bot, but also for the ecosystem if we create such an interface.
valiBot struggled at that time with, um, being kind of ignored, um, by popular or newer popular libraries. For example, maybe the open ISDK because this libraries often used sort as the default, and that basically excluded all other schema libraries. Also somewhat blocked innovation into space. And because of that, I reached out, um, to Colin and proof up, um, his own idea again, and I don't remember all the details, but I think I also wrote an initial version for the spec and sent it to them.
And then we had, um, calls, um, where we discussed it. I'm not sure how many, but at least a few. And then I think maybe one month or so before we published it, we as already by that time we reached out to many other Schema libraries, schema Library offers, but probably a month before we published it, I think.
Um. David joined and then we were basically a fixed team of three by that time, and David also brought in, um, got ideas and basically we freed together, then crafted the spec and I think launched it in December, 2023. No, 2024. Um, yeah. And from there on. It was like a really, um, wide ride. Uh, many popular libraries, um, supported it right away and many more followed shortly after.
I haven't checked the recent numbers. Maybe it's a little bit less because of the Christmas time, but I think we hit, or we were close to 60 or 70 million monthly downloads and. For example, um, sort value button archetype don't even include our own NPM package. So if everyone would do that, it would probably be a lot, lot more and we would probably be close to be one of the biggest NPM packages.
But yeah, that's basically also a great part of the specification we created. It's just an interface you can just. If you want, write the interface yourself. As long as it matches the spec, it'll work and others can use or accept it. And maybe to, um, catch up. Um, for some of you that don't know what you're talking about, um, standard schema is a standard interface to work with a schema library.
And we started with a spec for validation and types. So basically this interface allows you to infer the types from any schema library that supports it and also do validation. And recently, um, probably like now, two months ago or so, we published another spec, um, called Standard Chase in Schema that allows you.
Um, to get the Jason schema for any, um, schema library that supports the spec. And, um, that was probably especially important, um, for all the AI hype because here we need, um, structured data that that LLM can understand to generate a structured output. And of course also for, um, other areas like open API generation and yeah.
Speaker 6: Andrew, you wanna do the next one? You're muted though.
Andrew: ~~Uh, sure. Uh, ~~so you mentioned right there that the metadata in the schema is useful for AI structured outputs. Can you expand on that? Like how, how does it, uh, find use?
Fabian: Um, one example is that you build an agent and an agent, um, use the other. If we build agents on top of lms, then we give. Our LLM tools that can execute various actions and tools in this case can kind of be seen like tools that we use as humans to do whatever you wanna do that, um, can be, um, you could, for example, build an agent around existing software that provide APIs, um, for example, to create a calendar entry or whatever.
And
for these tools you usually have, um, structured input and sometimes also structured output. And this is necessary because the tool itself, um, executes custom code that you define. So the LLM has no idea about it. It only has idea about the input and the output and. The LLM has chop to select the right tool and also provide the right input for it.
And sometimes the LLM should have additional information to do its chop better, and that's where additional metadata comes in. Additional metal metadata can be an a title for an object property. It can be a description, for example, if, um. The LLM should pass over and user object, for example, with an email or H or whatever you can describe what this property is doing.
And you could even provide example values so that the LLM understands maybe how the formatting should be, and that basically, um, can help to achieve better results.
Justin: That's cool. So I mean, it really is just like. Schema for structured output, I guess like broadly just like helping the, the generation. Um, I saw Versel came out with a, like JSON render library, uh, recently, which is kind of makes me think of the same vein. It's like the structured output thing is a, is a, is a big topic these days.
Um. I mean, maybe a related question while we're on the topic of ai, and, and I'm curious if you've, how much like thought you've put into this, but like as an, as a library author, um, when you're, when you're thinking about building something like, you know, be it a, a. Schema library or some other thing. How do you, how do you think about making it work well with like AI tools or LM integrations?
Because it's like there's one thing, the historical thing of like, we wanna build for humans and now there's this like new world where like you're also building for bots and like how does that change your design decisions?
Fabian: I would say it hasn't changed, um, so far a lot, but it's not, um, because it doesn't make sense, it. Probably because valiBot was created pre AI hype. Um, valiBot is now, I think two and a half years old, if I'm not wrong. Um, and back then code, sorry, coding agents weren't used as they are used now. Um, but on the other side I also, I'm not sure if it would have changed anything.
Um. What, uh, we, so it is true that especially volley boards struggled initially because by the time some of the first use for LLMs were trained, volley board was not yet that really present in the training data. And that's why, um, the earlier LMS couldn't really write helpful value pod code and we had another issue.
Um, we. Had bigger, we had a full rewrite of the library in, uh, spring 2024. And some of the training data still had a lot of the training data still was based on old Wali, but API and that makes matter even complicated, but that was nothing we could have planned. And, um, yeah, what, so nowadays I would say, um, the newer models, they.
Pretty good in writing Volley Bot, and if they are not, you can just provide them our L-L-M-T-X-T. Um, we have put a lot of work on making that easy. So you have the option on just passing over a list with uls and the LLM can then pick and follow it, or you can. Provide the entire documentation or just the guides?
Just the API references and you can, even if you use the docs and you open up page, just put um, a.md behind it and then you get a markdown version and then you can pass it forward. And um, I see now more and more tools like Context seven, I think was the name that indexes. Um, docs or also LLM TXTs. And if you provide that as an um, MCP, then LLM for example, as part of their planning mode or even when they're executing things, they can, um, use that to figure out how to get it right and figure out what W bot is and how the API and everything works.
Um, and I think with that, we are now. At a point where it shouldn't be a problem anymore, and I expect that it gets even better this year. I expect that LMS will try to use more and more up to day updated information and maybe freshly fetch it. And that's why I think it will become less of a problem. Um, but yeah.
I'm also curious about what you can do to. Build a library. More AI native. As of AI native, I mean that AI can easier implement and use it. Uh, maybe that's a topic for this year, but we'll see.
Speaker 6: You're.
Andrew: Yeah, it, it's funny how in the end, like good AI ready code really just means like you checked all the boxes of pre ai good code. Like you have good tests, you have types that are descriptive. You have JSON doc, you have docs. Like if you have all those things, you can kind of distill it down into like a good AI integration and it's, it's just kind of funny how full circle that is.
Fabian: Yeah, and I think, um, I think for example, simplicity and consistency is also like key on, um, helping AI get the job done. Because if you are, if, if no human understands your library, it's unlikely that AI will do. And if you, for example, like bot have a strength, a strong mental model that hopefully makes it easier for humans, that should also make it easier for lms.
And another thing I try to focus a lot on. Not providing 10 ways to achieve like the same result. In most cases, there's only one way in Wali bot, and that makes it also a lot easier because, um, if Wali bot code is part of the training data, then the wali bot code is more consistent and then it's more likely that the I will generate the code the user would expect.
Justin: Yeah, that makes a lot of sense.
[00:38:13] Formish: The New Form Library
Justin: Um, I, before we sort of run out of time, I would also like to cover the other library you've worked on recently, form ish, uh, or for however you say it. Uh, yeah. Um, there are. A good number of form libraries out there, and it's a subtly challenging problem. Um, I mean, having written one or two now, at least two, like I'm sure you're much more intimate with this problem domain than, than most.
But I, I'm, I'm curious like what motivated the library? Um, like why forms and, and how do you think like this is different than, you know, existing solutions?
Fabian: Um, so Mod Forms, as I said earlier, was my first public open source project, and it was a form library that had the goal to be a modular and, um, small, and that basically inspired a later on Valley bot and. I built a form library back then because I was a heavy user of form libraries. And also back then when I used React, um, when hooks were and Beda, I built like the whole form logic myself.
That's why I knew many of the pain points and I try to fix them and make them better with, um, modular forms. And I think to some degree I was successful, but to some degree, maybe also not. I think, um, the API ideas I had were great and I think that's what many appreciated. And I'm not sure, I think at the same type, um, farmhouse was started.
I don't think he was inspired by. By modular forms, but we had some similar ideas, at least he later on, um, convenient, joined Dan 10 stack and built 10 stack form, which is also, uh, a really similar API design. And, um, yeah, the reason why I built it, because I felt like forms are not yet solved. I think, um, reactor forms.
Went in the right direction many, many years ago. But it also felt like over time it got like bigger, more complicated and more and more and more. Um,
and I basically tried to simplify that and fix it. And modular forms unfortunately had a few problems. Because of the internal implementation and this and a few other things, motivated me to get it right and build a new form library called Form ish. So Form ish is heavily inspired by Machu Forms and all the learnings from the past.
Also inspired by the work idel and tried to fix all these issues and. Another goal was, so modular forms was also available for a few frameworks like React, react, solve it Quick. But I, back then I tried to implement it a framework, agnostic core. It also worked, but it at extra code, um, to the bundle size.
And at the end I decided, okay, screw it. Let's just duplicate the code. And that made it, of course, super hard to maintain because we had to do the same edits four times. Now with LLMs, that's maybe no longer such a big of a deal, but it's still beneficial, um, if you have a framework agnostic core. And the cool thing before much is that the framework agnostic core does not add any additional bloat to your bundle.
It does not add any additional load to your runtime performance. And we achieved that with a special build step we built on top, um, of the core package. And what makes form very different from all the other favorite agnostic libraries and maybe other libraries in general is. That in it inserts the reactivity blocks of airway framework in the build step, and because of that, the reactivity you get is fully native to the framework you're using.
If you use solid GS under the hood, it'll use solid G signals. If you use quick, it'll use their signals. If you use SWT and so on, a few, it will be native to your framework and you can expect a native experience. Um, um, yeah. I think
Andrew: Y Yeah, the API is is quite nice. I, I like how you just like give it a schema and then you're kind of just off to the races. Uh. I see in the docs it says it's built on top of Ali Bot, but like, could we use like standard schema, compliant schema libraries for the schema prop? Like is it kind of like, would it be possible to switch it out like that?
Fabian: yeah, it's possible. Um. Back then when I started the work on form, it was not yet clear where it is going. I had like ideas on how to improve and fix things, but it was still something probably no one have built in that way before. So there was no blueprint. I had to experiment a lot and actually I build it initially, um, framework independent, but then at some point.
I decided, okay, screw it. Let's just, um, depend for on value bot for now to just simplify this part and focus on the part that actually matters to build a new form library. Um, formal, um, value bot is mainly used for types and also there is like an initialization part where. We use the schema to initialize the signals for every state of your form, and that's, um, where we need wali bot specific code.
But besides of that, um, it's not very specific to, to wali bot. And we could, um, outsource that in an adapter style header.
Andrew: Interesting. Uh, let's just wait for Justin to come back now.
Fabian: Yep.
Andrew: Um, I think he probably got kicked out of his meeting room. Oh, there he is. Uh,
Justin: Uh, um,
Andrew: Justin, do you wanna ask one of the future questions then we can, uh, start to wrap up.
Justin: Sure, sure. Sounds good. Um, cool. Let me get back in place. Uh, I had a, a pharmacy delivery, so I had to take it. Um, okay, cool. Uh, so we, we've talked a lot about. V
[00:45:29] Future of Developer Tools and AI Integration
Justin: alidation libraries about building libraries for ai, about compatibility between validation libraries, um, forms, modular architecture, covered a lot of ground. Um, and we always like to ask a future facing question. And there's one that I think is interesting here.
Um, so in some ways you're limited by the language capabilities. By the tool capabilities. So we talked a little bit about how. The approach of mod modular architecture for VA bot, um, can be a little bit limiting. 'cause you don't have the intelligence like autocomplete, right? You don't have the Zod like dot, and it like fills out a method for you and you could potentially like build a tool for that.
But I'm curious, are there like language features or like TypeScript features that you think could improve, like. How you built Valley Bot or like, you know, how you would go about solving this problem. Um, any like specs on the horizon that you're like, oh yeah, if we had this, like, I mean like the pipe operator maybe.
Like is that a, is that a thing that you think would like help? Um.
Fabian: Um. So the pipe array, probably not. I looked into that, but I'm a bit out of context now because it's probably more than a year ago. I think for a library like Vali Bot that does a lot of type calculation, it would probably help if that would be more flexible or maybe even more powerful. But, um. It's not that I have looked into type script that deep to make like direct recommendation, but sometimes, um, calculating as inferring and calculating complex types can result in a lot of extent checks and can get really deep.
And it also seems like, um, that especially for big. Project. This can also affect the TypeScript performance and therefore our editor performance and can make the DX way worse. Um, TypeScript goal will probably improve a lot of that, but that's the first, um, that comes to my mind. And other than that, I'm not sure I have to think about it.
Andrew: Yeah, it, it would be nice if there were, like, it sucks that all TypeScript programming is basically just a bunch of ter Aries like it, it's like the pseudo language. It would be so nice if you could like write a little, like a little function body somewhere to be like, okay, we have some variables. We don't have to use those as generics.
Yeah. There's a lot of room for improvement there, I think.
Fabian: Yeah, and the code that we as library offers of a library like Voli Bot or maybe other format other libraries write that is like an area where even the best LLMs struggle completely and give you like nonsense results. Um, because also most developers haven't, or even can't write these types because they're really, they can get.
Really highly complex, especially if you want to make them performant. And, um, yeah. Um, ish has some of these types with our paths where we only recommend you the next path item that is actually valid for the thing that you are building. And yeah, that, um, requires a lot of like research and test and. Yeah, and I think, and hope we got it right with form because there were problems with modular forms.
And I also think, I haven't looked at any form library, but um, I think form could be also maybe one of the first libraries that will reach 100 person test coverage. And will it be super stable probably very, very soon. Also available for all major frameworks, and I hope more and more developers take a look at it because I think it can be the future of form development.
And yeah, we will see probably this year where it's going.
Andrew: Well, that wraps it up for our questions. Thanks for coming on. Uh, you've done a lot of really cool work. Uh, I love your focus on modularity and small bundle size. It's definitely something that we need in the world, so thanks for coming on and talking about it.
Fabian: Thank you. Thanks for having me.
Justin: Yeah. Thanks Fabian. It's been, it's been great to have you. Um, I think like valibot is awesome. Um, and you know, the work around standard schema and form ish, it's all great. Uh, I'm really looking for a replacement for rat cook form. I'm kind of at that place, so it's timely. Uh, but yeah, no, so great chatting with you and maybe we'll get a coffee soon.
Fabian: Thank you.