00:00 Hey, everybody. I'm so excited to be joined by my friend. Actually, I forgot to ask you how to pronounce your name, so I'm going to just try it here. It's Akancha? Yes. All right. Yes. So, Akancha and I, we met in person first in Israel a couple of years

00:16 ago. My wife came with me, and that was awesome. And we were both speaking at, oh, what is it called? React Next, is what that was called. Wonderful conference, wonderful area. I don't think that there was, one of the things I'll never forget about Israel was that I didn't

00:33 eat a single thing that wasn't delicious. All of the food there was so good. I had a great time there in Israel. And yeah, so we've known each other for a couple of years now, and it's just, I'm looking forward to being able to meet you again at React India later

00:51 this year. So, super cool. You clearly are traveling quite a bit for what you do. Let's get an intro to you. What is it that you do? So I'm Akancha. I'm a open source developer. I'm one of the core maintainers of Excalidraw,

01:07 Reactives, Momento, Excalidraw, a couple of more libraries. I love doing open source, and I love speaking at conferences. That's how I met Kent, you as well, and I'm very fortunate that we could meet in person because I think my front-end journey started with

01:24 your blogs, your videos. That's how actually I got into React. So meeting you in person was something which I wanted. It was one of the goals in my mind, and fortunately it happened in Israel where I gave my first live talk as well. So yeah, it has been a lot of connections

01:41 and a lot of memories with that conference for me as well. And I look forward to meet you at React India. Yeah, that is so nice of you. Thank you. I'm so glad to hear that I had a small part in your story in getting into React and everything. And I want to mention also, I really appreciate

02:00 your contributions on Excalidraw. I use that on a regular basis, and in fact, in Epic React, some of the workshops I use Excalidraw for some illustrations that people are going to be looking at as they go through the workshops too. So thank you for working on that. What

02:18 are some of the things that you have worked on with Excalidraw that have been the most interesting things that you enjoyed? Yeah, so I think that's what I talk about as well because I love talking about those

02:33 things where the implementation comes into the picture. So a few features which I really love is the text containers where you basically draw some shapes and write some text into

02:43 it. Then you draw an arrow, add some text into it. Those kind of features are like quite challenging to build. And that's where I learned a lot as well. And that is one of the reasons

02:59 also I love speaking at conferences because when I speak at conferences, I myself have to go through again all of those things and explain in a way that people can actually understand it. Because implementing it myself is a different thing, but making people understand

03:14 the implementation is a different thing. So that's where I like talking about whatever stuff I have been involved with. But yeah, these are two of my favorite features in Excalidraw where I was involved.

03:29 That is super cool. I use that every time I use Excalidraw. So thank you for that. And I like that you pointed out that you like to both do the implementation and then also talk about it and teach people about it. Those are two separate skills and they each take

03:48 individual levels of practice and everything. And it's cool when you share those or have both of those skills because then you can really help other people be able to start

03:59 contributing as well. And as such a prolific contributor to open source, I think you know as well as anybody that getting more people involved in open source is a really important thing to be doing. Yeah, sure.

04:18 So what are some of the things that you do as part of your open source work to help enable people to contribute to open source or maybe even to step it back a little further like why do you think it's so important to contribute to open source?

04:35 I think one of the most important things which people might have a misconception about is I think it's not necessary to contribute to open source. It is important if you are really

04:51 fixing something that makes a meaningful contribution. So that's how I look at open source like people have this misconception that open source is so cool. I want to contribute to open source. How do I get started with it? And my answer to that would be don't have that pressure on your

05:10 mind that you need to contribute to open source. Whatever libraries you use at your work, go through that and if you want to improve something, do it. Check and you will find some bug or some improvement into it and that's how you can contribute to open source. Try to fix something and that's a contribution. That's a meaningful contribution and then it will get

05:28 better, go on and on. That's how I also started my open source journey by fixing some bugs at work with smaller libraries. Even when I started doing Excalidraw, it was more of fixing something and I wanted to make an NPM package out of it so that I can use that work and that's how I started

05:45 getting more and more involved. So I think when you are fixing something, especially which you are using at your work or your daily life, that way it also helps you to not be distracted and do something just because you want to make contributions to open source. But because you

06:03 are making your daily work better, it also motivates you to keep continuing contributing to open source. So I think that's more important to understand that you need to solve something, make something better and that's how you can start contributing to open source.

06:22 Absolutely. I think contributing to the things that you actively are using makes you a better contributor to those things than if you were to just throw a dart at the GitHub page and just choose something at random. So that's something that I've recommended to people as

06:39 well. And just recently, I was using a testing library that I put together and I noticed that we didn't have any documentation on the methods. So like the little pop-up that shows up when you're

06:58 working in your editor that didn't show any sort of documentation on what this method is or what it does or anything. And I just thought, oh man, what a great contribution opportunity for somebody. Now, of course, it maybe seems kind of funny coming from me because I made it. Maybe I should

07:16 have just done it right the first time. But my first contribution to open source was fixing a typo in Javadoc. This is for the play framework. And so that's the sort of thing

07:33 that is so easy to do for anybody. Writing code comments and stuff like that is pretty straightforward for most people, I think, relative to other things that you can be doing. But also,

07:47 at the same time, it makes a massive impact on the experience of using the library. And so it's stuff like that when you're working in your editor, you're working with this library, and you find something about it that is not great, that you are the perfect person to solve that problem because

08:05 you just have the pain. Also, I would like to add one more point here that if in case, let's say you don't want to solve the problem, you just want to create an issue and let the maintainers know, that's also fine. That's also a contribution. And if you don't know how to fix the issue,

08:23 also adding a failing test, that's also a good contribution because adding tests is something where we as maintainers also, it's hard for us to keep the tests up to the bar unless and until

08:38 things are in place. So I think that's also a very good contribution when someone comes and contributes a test and says, hey, this is a failing test and we need to fix this. So that's also a good contribution. Yeah, tests are actually really valuable. And part of any open source project,

08:55 like making sure that the maintainers aren't breaking anything. And in fact, I recently found out that SQLite is open source. It's not open contribution. So there's only three maintainers. But what's interesting is the way that they maintain, I guess, a competitive advantage

09:14 against any forks is that their tests are not open source. They use that as like, and they have like an outrageous number of tests. It's a very, very solid database. And so whenever anyone tries to

09:31 fork SQLite, people are like, well, that's great, but you don't have any of the tests. And those are like so, so valuable to make sure you don't bust something. So anyway, that just made me think of that as kind of interesting aspect to all this. But yeah, so there was something else I kind of

09:49 wanted to mention about open source. Oh, yes. So one of the other really cool things that I found with open source is that it's a really great way for you as a developer to acquire natural mentors.

10:03 So like, it's not a formal mentorship thing, relationship necessarily. But if you start becoming a participant in the community, and you just keep on showing like, the maintainers keep seeing your avatar and associating positive vibes, because like, oh, look, this person just

10:21 answered somebody's question. Thank you. This person just added some useful context, or this person, they made a documentation pull request, or whatever. The more that they see your face and have positive vibes with it, the better it's going to be for you. And now you can start making

10:36 code contributions, and they're going to spend some time helping guide you in that process too. So it's a really great way to get some level of mentorship from the people that are maintaining the project. Yeah, I absolutely agree. I think once you get into this open source

10:56 world, a lot of exposure is there, because you get to work with, you know, I mean, it's just that there is a hesitation. Earlier, I also had the same, like when I had to give my first pull request or second pull request, I was like, I'm writing shitty code, will someone judge me? And

11:15 then I see, okay, it's not one, three reviewers are reviewing my pull request. So now, you know, it's kind of this thing that, will I be able to merge the PR? Do you know, my pull request will go, will be approved or not, those kind of things. But when you actually start doing it, you get to

11:34 know that, okay, those people are also like you, they think like you, they are out there to help you. It's basically this hesitation, which I had myself, I have seen people also having the same hesitation that, because some unknown person whom you actually haven't met, or whom you

11:50 really don't know in person is going to, you're going to work with them, that kind of adds that black box, that okay, you know, well, should I code? Should I write? Will I, you know, will someone judge me based on that, those kind of things. But when it gets started, when you merge your first

12:05 pull request, it's like that aha moment, that okay, you know, I did it, I merged my first pull request, and now I want to do more and more and more, and that kind of gets an addiction, like that's what I started having, that, you know, I want to still, I want to contribute. If I had, when I had, like, I was working in a company, I want to still, after office hours, I still want to contribute, I still

12:24 want to, you know, make changes. So I think that's a very fun journey. Once you get started with it, it's just that that first step might look harder for some of us who are not really comfortable and who might have this, you know, hesitations. But yeah, otherwise, I think it's wonderful,

12:42 it gives you a lot of exposure, be it conferences also, I think, from, due to open source also, I have got a lot of those kind of opportunities where I got to work with the maintainers, and also, like, speaking at conferences, I think that's also something which is related to my open

13:00 source contributions. So I think, yeah, it's a wonderful thing that people actually start recognizing your work. And, you know, it's a good feeling that, okay, you know, I did this, I made this feature, and they are using it. So it kind of adds that excitement also, when someone says that, hey, you know, I use this feature, or I use this product,

13:18 and I know you contributed. Yeah, I did it. So yeah. Yeah, that's, it is super cool. Like, it's very rewarding to know that your work is helping other people. That's one of the cool things about programming in general is that, like, I can write this line of code, and I can run it once, and it can benefit me.

13:36 But then it's, it's just so easy to share that with other people. And now they can run it. And now it now look, they're running it a million times, and it's helping them accomplish whatever it is. It's super, super cool. Well, so you mentioned that, like, it can be hard for people

13:53 getting into open source and, and like, just challenging because anxieties or whatever. What are some things that open source maintainers can do to, to make that easier for people? And maybe even like before that, why should open source maintainers care about making it easier

14:13 for people to contribute to their projects? I think it's very important for the maintainers to make it easy for people to contribute. Because since it's open source, it's going to be maintained by the community. That's very important. Let's say if I start some open source project,

14:32 I cannot 100% commit that I will be maintaining it forever. And that's why I'm making it open source so that we as a community can actually maintain it. And when I want other people to collaborate with me, I need to make things easier for them to onboard them, right. So that's where

14:46 I think it should be very welcoming. Even like even for tiny pull requests, or, you know, tiny issues or whatever people are contributing, we as maintainers should always be welcoming. And

15:01 if you're not able to accept something, let's say some, some feature request, we have to reject it, or we are not able to accept some pull requests as well. We have to deny them in a humble manner, because we know that there was a lot of effort made into that. It's unfortunate that we are not

15:18 able to merge it. And at the same time, we never want that to happen. Like, if there is some issue, like we always will recommend in the you know, in the there should be clear documentation around this that if you want to build something, you know, let's first open an issue and discuss so

15:33 that the effort doesn't go into waste. And then we can collaborate. So those things should be clear upfront so that someone doesn't spend time, unnecessary time. And then then they come to know that, hey, this is not in the roadmap, and my effort goes in waste. And then you know that

15:47 that hasn't can happen, which definitely we want to avoid because we want to we want people to collaborate with us. And that's how the it can be maintainable in the long long run. So even the core maintainers are not there. There are other people who are going to maintain it in the future, and

16:04 then they become the maintainers. So that's how like, if you talk about Excalibur also, it was started by Viju from Meta. He started as a side project. And then and then there are a couple of people who actually started like I also started maintaining it at a very early stage. And then

16:19 there were other few few other people, there was like, I think, 10 to 11 people. And now a lot of us are there, not there, but still few of us are there and then new people are joining in. So that's how it's, you know, continuing. So I think that's very important. Like, if it's open source, it has

16:34 to be community friendly. Yeah, yeah. I have personal experience with this too, of making the mistake like doing it wrong. Where one of the libraries that I worked on early, or I suppose, a relatively early library I worked on that was pretty popular is called Angular Formly.

16:54 It was a library for building forms for AngularJS. And I actually, I didn't build it, I took it over because I started contributing and the maintainer said, why don't you just take it from me? I don't need it anymore. And so I made the mistake as the maintainer of just being the one who did

17:12 everything. So like people would open issues, and then I would just do it myself. And I kind of turned it into a game, like, I'll get this done in five minutes. And I would like immediately after they opened the issue, and people were like, wow, Kent, you're amazing. Good job. And I felt really

17:26 good about myself. And then I stopped using Angular. And I went on to React. And guess what happened to Angular Formly? Nobody took it. It died. Now, it's in a working state, and there are

17:40 still people who use it, but it's not maintained. The repository is archived. And yeah, there was no community behind that because I was selfish with the work. I didn't do anything to onboard

17:55 people. Now, contrast that with testing library, a few years later, I realized what a mistake I had made. And so I started onboarding people quickly. And in Node.js, at least for a while, if you made

18:09 some sort of non-trivial change to the repository, they would add you as a committer on the GitHub repo. And I thought, that sounds interesting. So I started doing that with testing library. And lots of the people, they didn't really do anything with that. But there were still quite

18:28 a few people who really stood up and were like, yeah, wow, OK, this is cool. This is exciting. I'm going to start doing more. And then I was able to move on from testing library. I still actively use it all the time, but I don't have time to maintain it. And there's a really great

18:44 crew of maintainers keeping that project going. And so for me, what you said just really resonates because that was definitely my experience in strong contrast with Angular Formly and testing library. Although I use the testing library in a lot of projects, and that's the first

19:03 library I will go with when it comes to testing. It cannot happen without testing library. I'm glad to hear that. Yeah, that library really worked out. I'm really happy. Again, other people are running my code and getting value out of it. That's the beauty of open source. And that gives you a very good feeling, right? Now you are not actively maintaining it,

19:23 but there are people who actually have taken the ownership to maintain it. Ownership is really important when it comes to open source. So I think that that also makes you proud that, OK, I'm not there, but people are there behind you who are actually taking care of maintaining the

19:38 library, which is great. Yeah, absolutely. So let's shift gears over to the open source project that is React a little bit. React has evolved over the years, and we're going to be getting

19:54 a really exciting new version of React very soon, React 19. In fact, by the time people watch this, many of them will be watching it after React 19 is stable. So what are some of the things that you're really looking forward to using? What are some of the things you're

20:11 excited about with React 19? I think React 19 in itself is like, basically, when it's going to be stable or even the RC version, if I want to try it out, it feels like it will be a new way to write

20:30 the React code because there are so many new things introduced, making a lot of things easier, which earlier was not supported. And if I compare it with React 18, React 18 was more like an implementation change, like let's say suspense, selective hydration and those kind of stuff,

20:45 concurrent rendering. But React 19 is like, absolutely feels like a new way to think and approach the code. Let's talk about forms, you know, with the use action state, use form status,

21:01 a lot of those new APIs. It will be a new way to write the forms or handle the forms. You don't have to handle the error states, the pending states, those kind of inbuilt, like I think we had the forming library, if I remember correctly, which I have used in the past to handle forms,

21:21 so that I don't need to handle those states separately. But now these things will be handled by that in addition to the optimizations as well. Additionally, I think compiler is a very interesting feature. It's kind of going in a direction where we as developers

21:41 stop thinking about which thing I need to optimize and I just focus on the app logic. It's kind of going in that direction that, you know, you don't need to memorize this part, you don't need to worry about it, we'll take care of it. Now, it's again an experimental thing,

21:58 so it depends, since they have already, I think, run in the metacode base, which is a very huge code base. So the results are pretty interesting, which they have been sharing. And I think at the

22:15 same time, when we will be running it in our huge application level projects, we'll get to know how, like, I think there was this interesting example shown in the React font where so many lines

22:30 of the code were removed because of the, like when comparing the, you know, with this compiler and without. So that really removes so many, what do you say, so many hassles maybe from our mind

22:50 that I don't have to think about it. So I think that's really interesting. And I think things like I think now that we can actually control the stylesheets, that's an interesting

23:06 feature. I don't know if this is related to React 19, but long back, a couple of years back, we had this bug when I was working at HackerRank that the stylesheets, we were using Webpack,

23:20 I think, that time for bundling. And there was this bug where due to the order of stylesheets being loaded, the production was getting messed up because some CSS was overriding some CSS. With this, it makes me feel that now we can control the precedence of which stylesheets

23:40 should be, you know, given more importance and should be loaded first. So probably, like, this is something which just hit my mind when I was reading about what are the new updates. And this is the incident which came into my mind that, okay, maybe this is something which we had a couple of years back, and those things will be now removed. Like, we don't have to

24:01 think about it because it's basically giving you more control on how things are being loaded on the DOM, on which order. So I think that's really interesting. It's like I can go on and on because there are so many new things. Ref, oh my God, that is something which I am so much, it is like a very tiny thing,

24:25 but a very important thing. Because this ref thing has been bugging me for a long time as well because I have to use those, use forward ref and those stuff just to, you know, get the reference. So I think ref, making it a prop, simplifies so many things, like, especially for

24:44 the package API. Like, if I talk about the Excalibur NPM package, we have the ref as well. So I really wait for the day when I'm able to, you know, just pass ref as a prop and we say, hey, now ref is a prop. You know, no more of these forward ref and those stuff. So I think

25:00 these are so much the quality, you know, quality of life improvement kind of things, which might not be that big, but really affects the developer way of coding. So I think

25:17 these things are really important and I'm really excited for the React 19 release because it's it's going to impact the way actually we approach the problems compared to how we were doing it earlier, I feel. And the interesting part, again, is the way React team releases it.

25:38 I think in React 18 also they took care of that. When you migrate from 17 to 18, it's not, it's kind of a, they shipped a patch. Like, they did ship, like, with some, with some flag or something, which, yeah, not the code mod. Like, even if you move to React 18,

25:56 you can still use the older APIs to render it on the DOM. So that was like, you know, you can, it's not like your app is just suddenly using the concurrent features. So in React 19 also, they are trying to do that. They have released, I think, the React 18.3, where you can get the

26:10 warnings, which, so that if your app is, there are things which needs to be changed in your app, you can actually start doing it right now instead of waiting for the 19 version. I really like that flow that suddenly tomorrow they release the React 19, and we have to

26:26 go through all the documentation and take care of the breaking changes. That's not the way. Like, they are doing it gradually so that we are prepared for the React 19 release. And that's really a good and a smooth way to upgrade for us developers so that, you know, we can upgrade it

26:41 smoothly. So I think that's a really, I really like that path which the community takes to onboard the people to React 19. Boy, there's so much that's coming in React 19. And it feels

26:56 like, in some ways, we haven't really talked about much more than, like, React server components coming, and maybe form actions are, like, the highlights. But there is so much more that we'll be getting out of React 19, and it's really an exciting thing. And like you said at the very

27:16 start, it's a new way to write React. And in true React fashion, it's a way that we can iteratively get to and migrate over time. Like you were just saying, like, we don't have to throw away our old

27:32 codebase and start writing a new one. So I'm really looking forward to that. And React server components will be a pretty interesting and exciting change coming as well. And also, like

27:49 you said, the compiler, that will be interesting. I really hope that React remains a thing that you can use without a compiler, and that you just continue. Because once you throw in a compiler,

28:04 then things can start to get a little confusing. So I like the compiler as an optimization, kind of like minification and stuff. And I hope that that remains to be the case. But yeah, not having to think about optimizations and memoization and stuff, that'll be pretty nice.

28:25 Yeah, it's like, it should be like an opt-in thing. Because again, if you have a huge codebase, you will not be ready to just, you know, move to React compiler. That's a scary decision, to be honest. Because you need to run experiments and, you know, do some checks and testing and everything. And then maybe one day you can move. But yeah, for the new code,

28:47 definitely, you can try out the compiler thing. But yeah, for the migrating the old code, we need to be cautious, even though the documentation says that it's going to be fine to use and run your code. But I think the React community will also suggest the same,

29:06 that try it out in your codebase and see what are the optimizations you are, what is the change when you run the compiler. I think the team will also suggest the same as well. So yeah, it's an interesting thing to try out, definitely to try out in a huge codebase,

29:25 where we can see the visible differences that this was my older code with so many optimizations. And this is the new code, which is even better and should be faster as well. So that's something exciting observation to look at.

29:42 Yeah, exactly. Well, do you have any other things that you were hoping that we could talk about that we haven't gotten to in our conversation yet? Okay, I think there is this interest,

29:58 like there is this question, which often comes to my mind, that since React is there, but there are so many frameworks now coming up, you know, Next.js is there, Remix is there, Redwood is there, then Solid.js is there. There are so many frameworks coming up.

30:16 So how does a person who actually, you know, starts getting into front-end, let's say, how do they decide what framework is right for them? There is no right answer for this, I feel,

30:30 to be honest. It's like, no framework is good or no framework is bad. Each of them have their pros and cons. And each of them have proved to work on a high-quality, big application.

30:47 So I think no decision is good or bad. But still, I think the new people, the new generation who is actually now going to jump into front-end development, they often have this confusion or have this thing going on in their mind that, you know, should I pick, if I have to even work

31:06 with React, which framework should I pick in? Or whether I should pick React, or should I pick Angular, or should I pick Vue, or what should I pick? So my answer is there is no right answer to it. You choose one, you stick with it, and, you know, get the expertise on it, because each

31:23 library and each framework has proved to be working. And if you look at any framework or any library, you will see a lot of large companies and organizations actually using it, and they're using it well. It's not like, I myself don't know about any organization which would have,

31:41 who would have said that, hey, you know, Vue is not working for me, so I had to move to React, or React is not working for me, so I moved to Angular. I don't know about it. So it's basically, you start with something and you stick with it, and you get the expertise on it, because

31:54 then you will be able to understand it in and out, you know, how efficiently you can use it. So what's your take on that? What do you think about it?

32:07 I agree completely. So I put together the Epic stack, which is a Remix-based framework, I suppose, and that connects all of the different things that you need for a typical application,

32:21 takes care of authentication, and testing, and database, and deployment, and everything. And the big premise of the Epic stack is that, like, this may not be 100% the perfect solution for what you're building, but you won't be able to find that anyway, and so may as well just go

32:39 with this. Like, there is no 100% perfect solution for what you're building, because there's trade-offs everywhere. And so given that it's impossible to find a perfect solution, then just use one that has been battle-tested and is good enough, and that's kind of what the Epic stack is all

33:00 about. So yeah, I completely agree. It's better for a team to just come to a consensus and make a decision than to just flounder around in analysis paralysis and not get any work done. Yeah, yeah, I think that's something, I think that's a really important message

33:19 for the people getting started to front-end development, so that they don't have the, what do you say, I don't remember, I don't find the right word of this, but I think it's,

33:34 they don't get into the zone of deciding which to pick, and that is not a zone which you should be in. Yeah, you know, I think what we're saying is the people, those of you watching right now, you made the right choice to go with React. But also, the people who aren't watching probably

33:55 made the right choice to go with whatever else they're going with too, and it's fine. I guess to put a finer point on it, there are more opportunities in the world working with React, and so if you're looking for work, then React is the best one to learn from that perspective. But if you have a job and you're using Vue or you're using Svelte or whatever,

34:17 and that's what your work is doing, then that's also great. And that's the cool thing about where we are at with the web and frameworks, is that so many good options are there that it's hard to make a wrong choice. Yeah, that's true.

34:35 Well, Akansha, thank you so much for chatting with me today. This is a lot of fun, and I hope people enjoyed our conversation about open source and React and picking a framework and everything. What is the best way for people to keep up with you and what you're doing?

34:52 I think definitely connecting in socials is one way so that we can connect. I'm on Twitter, I'm on LinkedIn. And yeah, I think collaborating in open source is another way.

35:06 That would be great if we can collaborate. But as I mentioned, look for problems to solve. Don't just pick up anything just because you want to contribute to open source. So think about where you want to improve and relate it with your daily work life so that you don't get distracted

35:27 and your motivation keeps going. That's a very important thing. Otherwise, what happens is you start contributing to open source and then maybe you'll keep doing it for one week, two weeks, and then it stops because it's not a part of your daily work. So I think that's something

35:44 very important. But yeah, if you want to connect with me or ask me about anything, just connect with me on socials, LinkedIn or Twitter. And yeah, I would be happy to connect and answer anything whenever I can. And I didn't realize that the 30 minutes actually got done with you.

36:06 We had a great time. It was a fun conversation. Thank you so much. This was super awesome. And we'll see you around. Looking forward to seeing you pretty soon. Yeah. Okay. Bye, everybody. Bye.