Kate:
Hello, and welcome to PodRocket. I'm Kate, the producer of PodRocket. With me today is Evyatar Alush. Hi Evyatar, how are you doing?

Evyatar Alush:
Hey, doing fine. How are you?

Kate:
Thanks for being on today.

Evyatar Alush:
Thank you for inviting me.

Kate:
Also with me is Noel from... He's been on a lot of podcasts lately. Thanks Noel, you've been crushing it.

Noel:
No problem.

Kate:
One of our engineers at LogRocket and one of our hosts on the PodRocket team. So, Evyatar is the creator of Vest. So, if you wouldn't mind just telling us what Vest is and we can get started from there.

Evyatar Alush:
Yeah, sure. So, Vest is a form validations library. It's a declarative form validation library and it draws its syntax and style from unit testing libraries like Mocha or Jest. So, if you've done some unit testing in your JS apps, you'll feel very much comfortable using Vest and it'll be very similar and very familiar to you.

Noel:
Nice. Very cool. So, I've looked at the docs and stuff. I feel like I've got a pretty good handle, but one thing that confused me a little bit when I started reading in my understanding was... Vest, it claims to be declarative, but also to pull inspiration from Jest. So, what does that mean? How do you have a declarative validation library that also is inspired by these testing frameworks?

Evyatar Alush:
So, when writing unit tests, you actually do get quite declarative when not specifying the specific test logic like constructing marks or whatever, but you have a very declarative structure inside the library specifically. For example, you have your describe block and each of the test is very much declarative and actually even tells you what it's supposed to be doing inside a description for the test. And then, inside of it, for example, if we use expect you have ingest, you have expect to be something or whatever metric you there.

Evyatar Alush:
So, very much of what you do inside your unit test, other than the construction of the test or construction of your functions, is very declarative. So, this is the declarative part that I drew from unit testing to Vest.

Noel:
Got you. So, the expectations that whatever your testing framework setting is declarative itself. Yeah. II think that's probably a good way to put it. I think a lot of people-

Evyatar Alush:
Yeah. Exactly.

Noel:
When they're thinking about their tests, they're like, "No, I do all this work to get it set up." But the meat of your test is just, does it look like this, right? So, once that clicked for me, I was like, "Oh, I get it." What got you interested in this space and how'd you get on this path?

Evyatar Alush:
So, about in, I think 2015 or 2016 with a previous employer, fiber.com, we started writing unit testing for our JavaScript tests. And we also had many forms in the website and we didn't know how to deal with them. We had to write duplicate form validations. We had validations that did not match in the client and the server. It was really hard to maintain because many form had many interdependent fields. And when we started writing the unit tests and I started learning about the structures, back then it was Mocha, I saw a pattern that aligned exactly with the way I thought about unit testing, because basically, as I said before, we have this big testing suite.

Evyatar Alush:
Inside of it, we have different tests that what we actually want to do is check that our functions match some expectation or some assertions. And if we take the same concepts into the world of form validation, well, basically that's exactly the thing we're doing. We have a form which could be described as our suite and inside of it, we have some different assertions that we want to run our data against. So, we're not testing functions, but whatever we are testing is pretty much, or can be pretty much, the same structure.

Noel:
Got you. Nice. Yeah. So, was the goal just to ease the cognitive load of having to think in two different ways? Or were you trying to set out and create a module that could be used in test and also form validation? Or what was the goal when you started?

Evyatar Alush:
So, when I started writing Vest or actually it was the predecessor of Vest, it was called Passable, I recreated it two years ago. I mostly thought, well, it could be an interesting idea to experiment on. And the more I wrote it and the more I built the framework itself, I realized there's something in there that's easier to understand and way more expressive than anything I've done before.

Evyatar Alush:
Because when writing form validation, we never even know where to stuff our validation logic, because it can be inside our chain channeler, it can be in a third party library that's completely separate from our feature and is unaware of our feature, it can be a mix of both.

Evyatar Alush:
And it's really hard to maintain going forward. And the more I wrote Vest and the more I used it, I actually realized this is sustainable and actually usable in the long run. And that's what made me go fully into Vest and invest more time in it.

Noel:
Nice. Can you give an example of one of those... An external library that would be needing to do validation on a form?

Evyatar Alush:
So, I don't want to talk about any specific form validation library because, well, I think most of them are actually great and they come to solve some real problems and they have some real valid solutions. And I mean, they've proven themselves to be very useful. I mean, they're being used by millions of developers. But I'm going to describe, I think, the three types of formal validation libraries that we have today, and I think Vest is the fourth type of formal validation library.

Evyatar Alush:
It's a new breed or form validation libraries. So, we have the original or the basic, the most basic form validation library, which is actually not even a form validation library. It's more like functional validators. So, we have a function like is number or is email, and we just run some data against that function and you don't get much control over the flow of data inside your feature, or you don't get any structure, actually.

Evyatar Alush:
And I think a second type of form validation library is something that's widely used, which is scheme of validation libraries. And we have many of those. Usually used in the API's, but I've also seen it used in the client. And basically, what you have there is specify some structure that you want your data to follow. For example, adjacent schema. And then, the username has to be a string and the password has to be some kind of validation function and whatever you have in there.

Evyatar Alush:
And this is really good and really, really useful, but mostly when dealing with validation on the server. But how do you deal with a schema when the user types? For example. And what you end up doing either directly or indirectly with the library is whenever the user types is just trim away or remove parts of the validation that are not related to what the user just typed. For example, the user typed inside the username field, also the password is a part of the schema. So, you don't have much way of controlling which field is getting validated.

Evyatar Alush:
And then, you have the third way or the third type of form validation libraries, which is by far, I think, the mostly used today, which is UI libraries or UI utilities that manage form state. And these are usually tied to a specific framework like react or review or angular. And you have a library that can manage the form state and also the validation. And usually, what they give you is either components for inputs, or they give you some references that you have to put on your element or event listeners.

Evyatar Alush:
And they are really good, but they also come with some cost because, first, they are tied to one specific framework. So, if you have multiple apps... For example, you have multiple apps on the same site, or you use micro-frontend architecture, whatever that is today. But you use micro-frontend architecture with multiple frameworks, you cannot share between them. And also, you have some third party library handling your UI and taking some control over your UI. And then, well, you have to deal with it.

Evyatar Alush:
And the fourth type is basically Vest, which I think is unlike all the others. And there are, I think, 10,000 validation libraries on MPM, but I think Vest... There's just one of those, which is a validation library that only takes care of validation. It thinks about your form and feature as a whole. And it is very much inspired by unit testing and takes it to the next level with a stateful validation.

Noel:
Got you. Yeah. Can you go in to that a little more in what you mean by how it only cares about validation?

Evyatar Alush:
So, most of the UI libraries that manage validation or form state actually take care and handle your form state. So, you give them the inputs and they save it and they also give it back to the UI, most of them, not all of them, of course. But Vest doesn't care much about the data. Of course, you're passing the data to be validated, but Vest doesn't care much about the shape of the data, as in schema validation. And it doesn't care much about what's ever happening in the DOM, it only cares about the validation.

Evyatar Alush:
And then, you can do some creative stuff because can express your validation regardless of what's happening in the DOM. But still, you can have a lot of control. So, you can write multiple tests for the same field because it doesn't have to follow some structure. I can have multiple tests for username. And then, as a result of that, multiple errors presented to the user, just because we can write multiple tests for just in a single field.

Noel:
Got you. That makes sense. I feel like that delineation is pretty clear to me when we're comparing them to the UI libraries that track state, or schema validation libraries. But how does that differ from your first type, the functional type. Because those feel pretty conceptually disjointed. Those really are just caring about validation, too, in the typical sense, I would say.

Evyatar Alush:
So, these are disjointed as you mentioned. Basically, you can write whatever it is and whatever you want and you can actually even use them with Vest. Vest doesn't care which assertions you use, even though it does come with a lot of assertion libraries or assertion functions. But what Vest does give you is specify some sort of structure and some sort of internal state poor validation. So, it doesn't care about the state of the form, but it does care about the validation state.

Evyatar Alush:
So, for example, if I type inside the username field and I go out then to see if the username is already taken and then the user types in another character, Vest will cancel the previous request. And then, only show the validation for the new request. This is one example. Without a tool like Vest that can handle multiple fields, it will be very hard for me to make tests for fields that are cross-dependent or interdependent. For example, password and password confirmation. And when all the tests are disjointed, yes, you get all the control, but you have to assemble everything yourself.

Noel:
Got you. So, is it fair to say that the advantage that Vest is really leaning on over those functional... The super old school type, is that it's tracking and aware of the validation state itself, even if it doesn't care much about the form state.

Evyatar Alush:
Yes, exactly.

Noel:
Got you. Yeah. Cool. Okay. That's a super clean way to put that. Nice. Awesome. So, you talked about cases of asynchronous logic or validations that have to call out to a server. Does Vest provide a lot of utility for asynch calls that may need to be debounced or something like wait until a user stops typing for some amount of time? Does it have those utilities baked in? Or do you have to bring your own from Lodash or something?

Evyatar Alush:
So, the most I've seen today being used and being needed by Vest is not debouncing because debouncing is very much tied into business logic and how you want your user to experience the website or the application. But Vest does give you some utilities for handling, not just asynch validations, but validations as a whole. So, for example, I told you you can write multiple tests for the same field.

Evyatar Alush:
So, for example, let's go back to the username example. If I have three tests for username, for example, one username must not be empty. Second username must be more than three characters. And third username is already taken, for example, on the server. Vest, first of all, allows you to specify, well, do not run the asynch test unless all the previous test for that username field already passed. So, this is one.

Evyatar Alush:
And secondly, as you mentioned, these asynch tests can be very costly and we don't want to just go out to the server for every [inaudible 00:14:59] type. And we don't always know whenever the user is finished. So, one thing Vest does give you is immunization of asynch tests. So, for example, if you run a validation for username and the user regrets, types another username, and forgets about writing that first username, or even just hits backspace, if we have the result for that previous validation, we will not even go to the server to see that same result if we already have it. Does that make sense?

Noel:
Yeah. So, if they end up typing the same name that's already been typed, they get a local cache memoized version. Nice. Very cool. Yeah. Are there other good examples of that, other than checking for a username on a server, that might be pertinent?

Evyatar Alush:
So, this is the most used one and it's common enough to actually have to write a utility for it. But basically, everything that has to do with either heavy calculations or going to the server, email or username captures, if you implement your own, whatever it is.

Noel:
Got you. Yeah. I mean, I can think of a handful of others, potentially, that's cool. Are there other utilities like that, that Vest has become interested in maintaining specific logic for this use case?

Evyatar Alush:
So, the other main utility that Vest maintains is the itch utility, which is basically allowing you to specify dynamic fields. So, sometimes the user is in the control of the fields being presented or fields being sent because they can add items, remove items, and you cannot know, in the beginning, which fields are going to be validated. So, you cannot specify them inside of the suite hard coded. And Vest has an itch utility that allows you to basically iterate over an array, specifying the different tests that every item in that array has to pass.

Noel:
Oh, got you. Interesting. Yeah. Very cool. Is it tricky... That leads me to another interesting point. So, there is a list and there're dependencies between those items. Validation is concerned about the state of one, to test if another is valid, say you can't have two items, I don't know, with the same name, for example, in your list. Can you set up that kind of validation in Vest?

Evyatar Alush:
So, the nice thing about Vest is that at any stage within the validation, you can check the intermediate validation result. You can always... And you always have access to whatever's happened before inside that current suite run. So, if I run my validation, my asynch validation, and the third test is already matching something that I've seen before. Yeah. I can do whatever. I mean, I'm in control over there as a developer.

Noel:
Yeah. I think that paints a pretty good picture for me. One question that did come to mind as you were talking a little bit about your inspiration and having to maintain different tests, server and clients. I was like, "Does Vest have support for getting these same validations running in a JS or a node environment in the server?"

Evyatar Alush:
So, one of the main things that I think were key to me and very important to me when building Vest is that it has to be able to run on the server the same way that it runs in the browser so you can share validations between the client and the server. Because validations just on a client are not good and validations that don't match between the server and the client can be even worse because the user will be able to do something that they can be told later they're not supposed to be doing or vice versa, even worse, they'll be able to do something that they shouldn't be doing.

Evyatar Alush:
So, as much as you can, I prefer having validations both on the server and the client matching, and you can just run your form validation on the server. It does require one slight change, you have to un-register your suite between each request because otherwise you'll have validation suite state being retained between requests. But other than that, I mean, the same [inaudible 00:19:24] state on the server, I guess, you shouldn't link it.

Noel:
Yeah. Got you. Nice. How involved is that set up? Say you've got a typical app that's running JavaScript in some form in the server and client. How hard is that to set up?

Evyatar Alush:
So, creating a Vest suite is basically running the create function with a callback, that's all it takes. And what you want to do is just... You get a suite object and a function, and it has a property called reset. So, whenever you are done validating your suite, you call that reset and you are all set actually.

Noel:
Nice. Very cool. Yeah. So, I guess kind of in that vein, say you are a reactive and you're using some other validation library right now, and you're feeling some frustration about it. Is there anything in particular that you might... Or any particular problems that devs might be facing in their other validation suites that they're using that might motivate them to check out Vest in particular?

Evyatar Alush:
So, first of all, my advice to any dev listening to it, if it works for you, don't switch. You'll hate for switching, you'll hate the world for switching, don't switch if it works. But if you are having a hard time using your current validation solution, then you should probably try out Vest. By having issues working with your current validation solution, I would usually talk about bloat inside your feature code. So, your feature code is spaghettied with a lot of validation code, and every time you come to touch it, it's really hard to read or really hard to rewrite. Or even sometimes when making refactors, you have to rewrite everything just to account for the new feature or the new field.

Evyatar Alush:
And if you want to have some more order inside your validations, then yeah, Vest is probably the right solution because... I didn't mention it explicitly, but Vest is a validation suite that's completely separate from your feature code. So, you can see everything in a glance and you don't have some validation logic line around inside your feature code with the user interaction.

Noel:
Got you. Yeah. Very cool. Talking about devs that have these bloated validation layers and tightly coupled code and you change one thing and it breaks seven things. Is that a common pattern that you see out in the wild? Or is it something you've seen in past lives, past experiences where you have this really hard to manage, tightly coupled validation code?

Evyatar Alush:
It's not just something I see out in the wild, it's something I've been doing for years before writing Vest. I'm to blame for it as well. And yes, unfortunately, one thing we don't think about when writing our features is the validation, and this is sad because the ORM inside our feature is usually the gateway to the server. And it is the contract between the feature and the server and the reason we actually build the feature to begin with.

Evyatar Alush:
Also, this is the most likely part to break because this is, well, the most interaction heavy part of our app. This is where our users make the most interactions. They type, they touch, they click. So, if something breaks, it usually breaks there. So, I think it is worth investing in a solution that's also reliable and helps you maintain some order.

Noel:
Yeah, totally. Did this method of thinking where you're... To your point of, validation is the closest to the user and pivotal to the function of the app, right? Did that lead to the API decisions that you made when designing Vest? That developer experience?

Evyatar Alush:
So, the most important point or the most important idea I had to retain... And I'm reminding you, I started writing Vest, or Passable back then, drawing inspiration from unit testing libraries. So, my first ideal was to stay as close as possible to the world of unit testing and most API decisions in terms of structure, syntax and terminology is drawn and should be as close as possible to unit testing.

Noel:
Got you. Did you find something about unit testing to be particularly intuitive and that's why you chose it as the baseline? Or was it more of, we're doing unit testing anyway, let's try to mirror it.

Evyatar Alush:
So, the case of unit testing just makes sense when speaking about a form validation for the same reason that I mentioned before, you have a suite of different functions that run against some predefined tests that match some expectations. And I mean, if that syntax and that structure works so well for testing your code, why wouldn't it work so well for testing your data or forms?

Noel:
Yeah. I'm thinking about that as well. I feel seldom in my unit testing framework of choice and struggling with the API. It always feels pretty... It's doing what I want it to do pretty painlessly. So, I think I agree with that decision. I was just curious if that was a conscious thing or if you've been thinking about it ahead of time. That's interesting to hear.

Noel:
For other people interested in this space, writing developer tools that are in this tier, even unit testing, frameworks, validation libraries, anything like that, tools for devs. Is there any advice you would give them?

Evyatar Alush:
Not just validation or unit testing, any library at all? I think-

Noel:
Yeah. Really anything.

Evyatar Alush:
Yeah. I think this is one of the most interesting parts of software development. Because as engineers, we rarely, I think, solve hard engineering problems, but we usually write code for other people to use and we solve human engineering problems. And it's a tricky one to get right because if you do something wrong, especially in the world of open source, it is immensely difficult to fix later because, more often than not, whatever you add into your API, whatever it is, library of framework or tool, it will already be used by somebody out there. So, you have to get it right from the get go.

Evyatar Alush:
And I think there are three things and three goals when writing tools for other developers, API's for other developers. First of all, the tool you write has to actually work. It has to do whatever it promises to do because if it doesn't, then it doesn't even have a right to exist. It comes to solve some problem or answer some need. And if it doesn't, well, it shouldn't exist at all. The two others are more important in terms of design. Second, it has to be easy and intuitive to use. And this is a big part, how to make something intuitive, maybe I'll get to it.

Evyatar Alush:
And also, it has to be safe to use and hard to abuse. You cannot let your consumers harm themselves, it shouldn't be dangerous for them to use. And when you build your API, you are teaching your consumers language or pattern. You don't want to have them go to the documentation every time they want to use your library or tool. And instead, you have to try to be, at least, consistent, use similar naming and terms. And if you can, also build on top of existing knowledge. For example, as I did in Vest, I try to build on top of the developers already existing knowledge of unit testing, libraries and frameworks so they have a very, very easy learning curve when trying out Vest.

Evyatar Alush:
It's so similar to unit testing libraries, actually, that if I just hook a CLI to it, Vest can be used as a unit testing library. So, it's pretty cool. And regarding the tool being safe to use and hard to abuse, I think you have to build it and design it with safety in mind. So, sometimes you do have to allow your consumers do dangerous things, but if you do, you have to let them know it's dangerous. So, if you think about, I don't know, react, they give you dangerously said in our HTML, you can't use it without knowing you may be doing something harmful. So, it's really important.

Noel:
Yeah. Got you. That's a good example, probably, of a dangerous surface point in an API. What's an example of something that's easy to abuse in API's, that you're trying to avoid when doing API design? How do you make your surface hard to abuse?

Evyatar Alush:
You can make the surface hard abuse... And abuse doesn't necessarily mean do evil things. I usually think people are good and try to do good things and have good intent, but hard to abuse usually means doing something they're not supposed to be doing with your tool. For example, using internal API's that are not a part of the documentation or the contract. And to make something harder to abuse, usually you have to think about those as well, because everything in your signature, even though it's not a part of the contract, everything exposed to the consumer, every perceivable behavior will be used by somebody.

Evyatar Alush:
And then, when you want to make some refactor, or when people start breaking because you made some change because you were unaware that they're going to use it. Well, they abused it, even though they didn't mean to, because we're developers, we have magic powers, we can see code and we can use it even if it was not intended to be used.

Noel:
Yeah. I feel like this is a point we've landed on with a couple of our recent podcast. We were talking [inaudible 00:30:42] with the internal view API's that Evan was having trouble getting devs... The big libraries were using these internal API's that nobody was really supposed to be using. So, they were having all these problems getting those libraries to upgrade. Yeah. That's an interesting point... Abuse isn't necessarily evil, it's just devs feeling the need to reach into the internals of something and use it in some way that wasn't necessarily prescribed or the intent of the API.

Evyatar Alush:
Exactly.

Noel:
Yeah. So, that's super interesting. To this point of all these things you have to keep in mind when setting out and writing an API, especially for an open source library, like you said. Everything's got to be pretty tight in V1. Say you're a new dev and you're interested in building tooling like this. How do you get over the fear of messing something up? How do you get to V1? That just seems so scary.

Evyatar Alush:
Yeah. It's really scary. I remember releasing my first version of Passable in 2016 or 17. And well, it sucked and it took me, I think... And just two days later I realized everything was garbage and I made a full major version change. And I actually did it to Passable seven times until I landed on a viable API. And this is what led me to actually understand the need of writing good API from the get go. But also, fear not because like everything in software development, API design as well, I think everything there is a trade off.

Evyatar Alush:
You don't always know the right solution and you don't always have the right answer. And when you don't, just leave stuff out, if you don't have the correct solution yet, it may be okay. It took me four years to add a simple function to Vest, which is, is valid. A validation framework that for four years didn't have the, is valid, function because I didn't land on the right solution from the get go and I didn't have the need for it yet.

Evyatar Alush:
So, if you don't add something, you will never regret for adding it. And it's always a trade off and you are the domain expert in whatever field that you are building the library for, and you have to balance it.

Noel:
Is it easy to maintain motivation for you? When you realize that you've made some big underlying mistake to the API. Because I think it's a pretty common pattern. Somebody's got a project, they're working on it, they realize they've done something fundamentally pretty wrong at a low level. And they're like, "I don't even want to keep working on this anymore because there's..." How do you overcome that feeling?

Evyatar Alush:
So, when you are small and people don't know about your library, well, there is no harm done. I mean, you can always fix it, bump another major version and that's okay, nobody uses it yet. When it's big and there are real implications and people are breaking because of your API decisions. It's a bit harder and there's not much to do other than offer support, update the documentation and try... Even if you have made some bad decisions in the past, try to fix them by adding alternative API's or other solutions to your library or to your tool so people have the choice. And add, I don't know, a deprecation notice in the documentation for whatever it is that you're doing.

Evyatar Alush:
And also, if it causes some errors, make sure these errors are very descriptive. So, for example, errors are a kind of documentation too. And each and every error, especially in a bad API or a badly designed API, should include at least some of the following: what went wrong, what happened, what could be the cause of it, maybe alternative solutions or possible solutions for that problem. And if possible, even a link to the documentations. And if all these exist inside your error message, then yeah, you've made bad API decisions in the past, but you are allowing your users to easily fix them.

Noel:
So, I see Vest is on 411 right now. That's master, I think. How do you decide when you have a flaw large enough to justify a major version number bump?

Evyatar Alush:
A major version is... Usually, I don't think about it as a bug fix, it has to be more strategic. When I want to add a major API change, I also want it to come with a bag of presents for my consumers. So, a lot of many new cool features that I want them to use and actually promote them to use the new version. So, I can't point the finger or put the finger on just a specific indicator that a major version should be bumped, but usually when I accumulated enough improvements and I've made a decision that some previous decisions that I've made are no longer good or do not satisfy the current needs of the library, then yeah. When all these are met, I'll just update the major version.

Noel:
Got you. Do you adhere to the SemVer practice of... In those major versions you can introduce breaking changes as long as they're well broadcast.

Evyatar Alush:
Yeah. I try to abide by SemVer.

Noel:
Yeah. Totally.

Evyatar Alush:
Yeah.

Noel:
I was just curious how you thought about that. I guess, more broadly, when it comes to maintaining an open source library with lots of eyes on it, how do you find that experience? Is it stressful? Does it energize you? What's that like?

Evyatar Alush:
I really enjoy it. I mean, it's much better than having nobody look at what you write. So, this is actually the hardest challenge. I mean, I remember when writing my first open source contribution, wherever it was, and writing my first library. I was like, "Okay, now everybody's going to laugh at my ugly code and my stupid code." And for, I don't know, a year and a half, nobody even cared, which was the biggest hurdle to overcome.

Evyatar Alush:
And now, when I actually see the star count going up and the user count going up and the downloads going up, actually energized by that. And when I get an issue, I get an issue either... Or even on Discord, somebody asking a question or saying there is a bug or something doesn't work correctly. I'm excited because, well, I'm doing something that's helping people and they care enough about it to actually come report back to me.

Noel:
Nice. It's interesting that you bring up Discord. How do you find managing and curating a community for an open source project via a Discord server?

Evyatar Alush:
I'm terrible at that.

Noel:
Yeah.

Evyatar Alush:
I'm terrible at that. I'm more of an engineer than a community leader, but I'm trying. I've set up different rooms and channels, whatever it's called on Discord, for the different purposes. I added the link to the documentation of Vest and sometimes I see new people dropping by, but I'm not really good at promoting it in the community.

Noel:
Got you. Yeah. I feel like I've found, just through personal experience and hanging out in other dev tooling communities, you end up with a lot more of the same question being repeated in those more chat-esque channels. I don't know if there's any interesting takeaways here, but yeah. I feel like there is much more of a community management piece happening in those more realtime communication platforms than something like GitHub where it's a little more form-like and you have issues, it's more curated. So, I was curious if you struggled with that at all. I'm glad that you find it exciting and it motivates you a little bit.

Evyatar Alush:
It does. Totally does.

Kate:
As you were talking, we just had Ash Jeffson... I think it was yesterday. He's the creator of Benthos. He was talking about maintaining open source and the importance of avoiding burnout. Just because with a lot of other projects, interests, there're physical limitations. With web development and open source projects, you don't really have... As long as you are awake and have internet, you can work on it. So, I guess, what are some strategies around avoiding burnout that you take?

Evyatar Alush:
Vest is not actually the only project I maintain. I have a few and Vest is not even the most popular one that I maintain. It is in terms of star count, but not in term of usages. I have a react components for an emoji picker that has thousands of uses in different apps. And I always, constantly get new issues and bugs because this is something people actually see on their webpage so it's much easier to detect bugs.

Evyatar Alush:
And I've decided that I'm unable to keep maintaining it because, if I would maintain both this library and Vest at the same time, I would, as you said, burnout. And what I decided to do is give it out to the community. So, I'm, at the moment, mentoring a couple of new developers into taking the project full time.

Evyatar Alush:
And this is the way I see, basically reducing the amount of responsibility and time you have to allocate to all of your projects and just focus on whatever it gives you the best energy and most motivation, which at the moment it's Vest.

Kate:
Awesome. Yeah. Very cool. Awesome. Yeah. Is there anything that you would like to plug or want to point our listeners to?

Evyatar Alush:
I'll just say that if you're interested in trying out Vest or even contributing to Vest in terms of documentation, code, examples. Because I didn't mention it, but Vest can be used with any framework out there, any UI framework. So, if you want to contribute to Vest in any way, feel free to drop in the GitHub or the Discord chat. I'm trying to be available there. And I really, really enjoy any traffic going in.

Kate:
Awesome. And we will include those links in our show notes as always. So, go check those out. Thank you so much for coming on and yeah, we'll see you around.

Evyatar Alush:
Thank you for having me.

Brian:
Thanks for listening to PodRocket. Find us at PodRocketPod on Twitter, or you could always email me even though that's not a popular option. It's Brian at LogRocket.