Excalidraw with Aakansha Doshi

[MUSIC PLAYING] Hi, everyone, and welcome to the Developer's bakery, a podcast about open-source projects, tools, and libraries for software developers. My name is Nikola Corti, and I'll be your host for this show. Make sure you subscribe to the podcast on either Spotify, Apple Podcasts, Google Podcasts, or directly on the website, the bakery.dev. Thank you for listening and enjoy the show. [MUSIC PLAYING] Hi, everyone, and welcome to another episode of the Developer's bakery. Today, I have another amazing guest on stage. So please welcome Akansha Doshi, maintainer of Excalibur. Hey, hi, Nikola. Thank you so much for inviting me. I'm really excited for this podcast and whatever discussions we dive into today. So yeah, really looking forward to it. Amazing, Akansha. So as I do with everyone, I want to give a little bit of time to introduce yourself. So tell us where you base, where do you work, what's your background, and so on. I'm based off India. I'm an independent open source maintainer, one of the-- sphere of the projects, which I maintain-- Excalibur, which has been there for a long time maintainer for Excalibur, then there is ReactX, Fasify, and a couple of more libraries. So yeah, I love open source. I'm really passionate about open source. I love speaking at conferences as well. That's another thing which I'm really passionate about. And yeah, that's pretty much a quick introduction about me. And yeah, I'm excited to see about the conversations we dive into in this podcast today. Awesome. I'm really super excited to have you on stage, because I really love to have open source enthusiasts as you sort of define yourself. And so yeah, today we're going to dive into one of your projects, but also hear your stories around open source. So the project we want to talk about is Excalibur, which I believe a lot of people know. But if there are people in the audience which are not familiar with it, I guess now it's the time to give us a spotlight, like an elevator pitch of what is Excalibur? Excalibur is in short and simple words. It's a virtual wide mode for sketching hand-run like diagrams. You basically, when you can just go to Excalibur.com and start drawing no longer sound required. So it's very easy to use, very simple to use. And your drawings are also into an encrypted, so you don't have to worry about someone watching your data while you draw. And you get this hand-run feeling, which makes Excalibur unique from other wide boats. It's not like those regular forms. It's basically a handwritten style, which makes you feel like you are actually drawing on a paper. So yeah, and it's open source. So it's basically build with the community. And yeah, if you have not haven't checked it out, do check it out and let us know how you think about it. And if you have any feedback. Awesome. So like you talked about this and drawn a feature of Excalibur, which actually I'm curious, like I'm really curious about. I'm sure everyone in one way or another at some point in their life, so an Excalibur diagram, like there are like mailing lists using them as part of their graphics and diagrams. So and the style is really nice. Like I really like it. And I used it for work a number of times. So I'm curious to hear like, what is the secret to like sort of achieving this and written style? So from the start Excalibur has been using a phone called Virgil, which is the handwritten phone. And there was, there had been few issues. Like Virgil is really a good phone, very popular. And people have been loving it. But on the other side, there has been some issues with the readability when it comes to using the Virgil font. Basically, if you have noticed the R, when you write something, this R actually doesn't look really like an R. So those kind of legality issues were there. So we wanted to improve that as well. And recently there was a release, which was basically an improved version of Virgil font, which is Excalibur. So it's basically an improved version of the existing Virgil font making more readable and more legibility wise also very clear and good to use. So recently we have deprecated Virgil, but it is still there. People who have the old drawings will stay in Virgil, but you can switch to Excalibur, which is more readable and more nice to use. And apart from that, we had been getting requests to add a couple of other fronts as well. So we have, I think I did a comic sense and also an O'Neill to font, which you can use as well. So yeah. So there are like a couple of now, I can see two four fonts which we are supporting. And the other fonts are also there, which slowly will get deprecated. So it's recommended to use the newer fonts. - Got it, but it's not just writing, right? Like also the lines when you make R. - Yes. - So that is, that comes from rough JS, which is by Prith, it's a library, which helps us to give this hand round feeling to the drawings, those curvy things, those roughness, those slow penance, which you can adjust from, you know, when you are drawing the shapes, those actually comes from the rough JS library. So yeah, that credit goes to Prith, it's a library by Prith. - Got it, got it. Okay, so let's still keep on talking about features of Excalibur, there is another one that I'm really curious about and it's like, where are the graphs stored? Because you set their end to end encrypted. And also, like you said there is no login. So where are they, like, can you tell us a little bit like how do you save, how do you share a diagram, where is it stored in which format is it stored and so on? - Okay, so there is no login or signup process to keep things simple, whatever you are actually drawing in Excalibur.com, they get saved to your local storage, the browser local storage, but that is fine as far as you are just using it on the client. Now, when it comes to sharing, we need to save it on the server or when it comes to collaboration also, we need to save it on the server so that the sessions are persistent. Now, in that case, what we do is we actually, we don't just store the drawings in the raw format, we basically encrypt those drawings in the browser and store that encrypted blob on the server. And when you fetch it, you basically decrypt it on the client again. We use the webcrypt to APIs to do this into an encryption. So we don't have to, server is basically just storing that encrypted blob, not really, doesn't have any information on how to decrypt the data. All the information are stored on the client. Now, if you are wondering how the keys being exchanged when let's see, I have a drawing and I want to share it with you, then in that case, the URL is what actually helps you to store it. So if you look at the URL when you actually share the drawing, you will notice that there is this half in the URL and whatever data is stored after the hash, that never reaches the server, that's the browser default behavior. So that is where we actually store the encryption key right after the hash. So it's securely exchanged within between the clients and it's never saved on the server as well. So you basically achieve the secure encryption as well. - Got it, got it, got it, got it, got it, got it. So basically, just to summarize for the average user, which might not be familiar with it, I go to xcalidrow.com and I start drawing and then I click share and I have a URL and that URL sort of contains a reference to the graph, which is actually stored on xcalidrow.com, but is securely encrypted. So folks, no one can see that unless you have the URL, obviously, like you share it, got it, got it. Okay, so we talked about xcalidrow.com, but you also said that xcalidrow is open-source. So, as xcalidrow.com, just running the open-source version of its calidrow or there is a little bit more, like there are differences. - Yeah, xcalidrow.com is your early open source. That's what you see in the GitHub record. That's what is hosted on xcalidrow.com. So it's completely open source and all this horse code is available on the GitHub record itself. But yeah, there is a paid version of xcalidrow, which is xcalidrow plus, which you can export your drawings. If you want to use the paid version, you can export it from the dropdown. and save it to Excalderopolis. But yeah, Excalderopolis on the video opensource. - Got it. We haven't talked about which language is it written? And you mentioned, there is, no, you haven't mentioned that, but there is an MPM package for sure, right? I saw it online. So I suppose it's some like JavaScript or. - Yeah, it's purely JavaScript and TypeScript. And React, we use for the UX part, we are using React. And for the canvas and there are a lot of browser APIs which we are using, but in like to summarize, it's JavaScript plus TypeScript project, React with the UX and we use a node as well and for the server and then we use Meet for the build, setup and everything, versus, and there are a lot of these things that we are using, but the stack is now also JavaScript. - Got it. Okay. So I'm curious to know like now how like you became a maintainer, because correct me if I'm wrong, you are not one of the regional author, like you sort of joined the project after. So I'm curious to know like, what's your story with Excalderop? Like how you got involved? - Yeah, so that's an interesting story. I was working at Hackerang in like that is my first company. So I was working at Hackerang and in 2020, this COVID hit the entire world and everything was virtual. And that's the time where Excalderop was also launched in January 2020, Excalderop was launched and VGee from Meta was doing a side project. And he basically shared it on Twitter that year, oh, he's building something, just doing prototype on code sandbox and everyone got pretty excited about it. And then in I think around May, April or May, we were basically at Hackerang, we were looking for a whiteboard to integrate. For the Bheakark, it's basically internal based product. So we were basically want to integrate a whiteboard because everything was going virtual and we saw a lot of whiteboards and financial Excalderop because of the simplicity, mean one of the main reasons. And then I wanted to integrate it into the Hackerang, which is a third party. And I wanted to create a build and NPM package all of it because right now it was basically build as a standalone application. So I wanted to make an NPM package all of it so that any third party can actually just integrate, it's skydroid to their apps. So that's where I came up with a proposal that, hey, I reached out to the code team, the people who actually started getting involved from day one. I started, really started them that, hey, let's can we create an NPM package out of this? It will help other applications to just integrate it and we can have super powerful APIs and it will help a lot of companies and any third party who wants FadeGrid to Excalderoy to their apps. So that time Excalderop was at a very early stage, they were shipping the features very frequently and it was at a very early stage. And this NPM package will needed a lot of you change in the code base, which was, which was like that's the reason the team was not ready for it because they were busy doing the other stuff. And I still wanted to push for it. So I kept on convincing the team. I also, I liked the product as well. So I started contributing buildings for smaller features. I think I started with building the Zen mode. That was my first full request to the Excalderop. And then I was also pitching them for this NPM package and then I had to, I also, I think, ended up building, you know, docs, presentations that we know in future do this and, you know, how it will be helping and it took me around 68 months to convince them. And then later towards the end of the year, we were able to ship the NPM package officially. Till then I was basically, I had a fork, which I was using in hacker rank and, you know, managing it, whatever updates the, with the Excalderum mean upstream, but that's how I basically started, you know, building this NPM package and maintaining it. And that's how became a maintainer of Excaldera as well. And that's how since then I have been continuing as a maintainer. So yeah, that's how my generally started with Excaldera. It's super interesting. I'm wondering like how many other maintainers for Excaldera are there? - Okay. So when I was, I started as an interviewer there were, I think around eight to 10 folks who were actively, you know, me, David, Lippes, Vijoba, also there, Thomas, was also there. There were a couple of other folks. So 10 people I guess there were. After that Excaldera started, you know, planning for a company, like let's build a company all of it. And that's where I switched from hacker rank to Excaldera as well full time. So I joined the company as well. And I was there with the company for two and a half years. And then now I'm an independent maintainer. So I am not full time into the company, but I'm still maintaining Excaldera. And a couple of other projects. But yeah, there were, I think from start till now, I think there are two people probably me and David who have been still maintaining Excaldera from the early folks who started it. But yeah. - Super really fascinating. Like how you just, you got involved and then you got inside a company and then you're still involved as independent. Like, yeah, like crazy stories. Like I want to ask you a little bit of a broader question at this point because I personally get asked this question a lot as well. But I want to hear your thoughts. It's like what will be your suggestions for folks to get started in open source? Like was even Excaldera your first open source engagement or you were already experienced? - Excaldera was not my first engagement, but yeah, it was definitely one of the bigger projects. - Yeah, absolutely. - As a maintainer, yeah. But I think my first suggestion to all the people out there who are really looking to contribute to open source is, I feel you don't really need to look for projects to contribute. That's my experience. How I have been contributing to open source is even when I was in Hacker Rank. I had my first contribution was to a small library called ReactTax, which we were using at work. It's basically a tagging library. And there were a couple of issues in that library which I wanted to fix. So I just went ahead and fixed them myself and ended up being mentioned in other library. So I think that's the best way to contribute to open source. Just improve the things which you are already using. That helps you to maintain it for a longer time. I also keep, keeps up your motivation to keep moving things forward and improving, at the end, you are actually improving your work because you are making things easy for yourself and wherever whatever you are working with. Instead of looking for a project and then finding some issues and then contributing to it, that's kind of an extra effort you are doing and that might not be scalable as well because since you are not using that project, you might not be able to contribute for a longer time. And then it just goes off. So I think that's the best solution I would say that just look for the issues in whatever libraries or whatever projects you are already using at your work or in your side projects. Somehow you need to be using those libraries because you are the best person to improve it because you are using it as a user. So I think that's the best advice I would say because people often get distracted that I want to contribute to this repo because it's a very popular repo. So I will have some contributions in that. I would say, don't go for that, don't go for that tagging thing, just look for whatever libraries you are using in your day to day job and try to improve them. And then you will get to a good stage and you will yourself become an open source maintainer of, one library or couple of libraries. So yeah. - Absolutely, I can totally relate to that. I got asked the same question. My answer is generally the same. Like get a tool that you use and try to improve it. Talking about improving tools, how can folks be involved in X-Cydrone as contributors? - I think X-Cydrone as a contributor, I would say documentation is something that we really want to improve a lot because as a, I mean documentation for the code base as well because it's very helpful to onboard the new contributors. If you have a good starting code base, we have a code base I think for a couple of scenarios like Mermaid to X-calibrate is one of the packages I maintain. So basically where you have the Mermaid diagrams and you get the X-calibrate output of it using the Mermaid syntax. So, So we have some documentation for that. We have some documentation for the how things work under the hood. But still, I think we really need, like, people get stuck a lot and, you know, using the end-to-end package at where at times. So I think that is also a good place to improve the documentation where people are getting stuck. So I think documentation is one step, one area where we really need help. I think second would be probability. I think adding tests is also one great contribution to any open source repo, because that helps the maintainers to get an idea of what things are working and what is not working. Plus adding a failure test case anyways makes your entire, you know, the post stronger because you are having more test cases. And apart from that, I would say, probably we do tag some good first issues. So if a man is interested in picking up those and it's not just a scaler or a repo, it's like couple of other repos where people can contribute as well, like, momatic scaler or the libraries or, you know, there are a couple of other, independent libraries which we have, which we use in scaler itself. So those libraries are also a good place to start with if a scaler looks like a huge code base to you. So you can always start with something smaller. God, I'm like, let's say one question that I have at top of my mind is like, is an ex-cardiode finished? Like, I mean, I'm sure there are some bugs to fix, but it looks like a finished product, no? Like, it looks like all the features are there. And I mentioned like, you're contributing with the commentations, which is really valuable. But I'm wondering if there are like, what's left to done or if there are still like some, you know, most requested feature that folks are asking for, which are still missing for X-cardiode. Yeah, I think I can name a few which are highly requested features. One of them is tables. The tables is one of the most highly requested features. Yeah, sure. And that's recreat Excel, basically. And then we have this, the Wisswig editor basically bold italics. You can style your text. That feature is something which is also requested because, I use X-calerol a lot in my presentations. But I miss that feature of, you know, bolding some part of the text or highlighting some part of the text when I'm using a presentation. So I think that's and that's also one of the most requested features as well. So these two like big features wise, these are the two most requested features, which we have often been requested on GitHub or socials everywhere. And performance, I think there is a huge scope of improvement when it comes to performance, because when you have like huge number of drawings, there is still still, we have in the pipeline that we really want to improve performance further. It's not like a bottleneck because it might, it will happen when you have like a very huge number of drawings. But still, there is a scope of improvement when it comes to like improving the performance in canvas, because X-calerol is a canvas based editor. So there is still some good scope of improvement there as well. And definitely one of the biggest things which we really need to spend time on is decoupling the code base. The code base I feel is is not structured in the best way. We are using React. We are using React. We are using canvas. These two things are right now coupled into each other, which doesn't really need to be because X-calidraw when it comes to the internals doesn't really need React. React is just for UX. So these two things can actually be decoupled from each other. So at the end of the day, then we can have the React component that will still stay. But X-calidraw as a whole is right now depending on React, which can be completely decoupled. And we can actually hit the advantage of it. And the code base will also be decoupled in a very modular way. And thus we will be able to use React the right way, which right now the canvas is, canvas doesn't need React, but we are using React. So we need to decouple those stuff as well. And a lot of improvement in the Package APIs is also there. We can make the Package and Pay Package API lock more powerful than what it is right now. So yeah, I think there are a lot of stuff. Like this is just a few things which I mentioned. But apart from this also, there are a lot of things which are there, which needs a lot of work to do. So yeah. Since you're talking about it, I'm actually like you talked about code base. I'm actually wondering like do you have tasks for X-calidraw? And if yes, how they look like, just create a graph and verify that it's there on screen? So we have tests. Yes. It depends on if you are really testing just the, let's say you're at a unit test, then maybe like we store it in the JSON format. So you can just always compare the JSON and take a snapshot. But at times you need to mark the canvas as well. So for that we use the latest camera small library. So, but yeah, again, the test is again something where we can improve a lot because we don't really have the integration test yet. And in few features or in few places, you really need the integration tests, very well-written integration tests. So maybe that is something maybe play right or some some library we might want to try out to you know, add those kind of tests as well in future. Got it. Okay. So since we talked about this and like you know managing code basis and and writing tests a little, I'm actually curious what if what you feel is the biggest challenge when maintaining X-calidraw? Like what is the hardest bit? Like the core of the complexity here? What is it? So are you asking in terms of the code, maintaining the code as in that's the question? Yeah, like I mean, let's talk about the code base, but maybe the complexity can even be like, we receive too many bug reports, we can't handle it. Or we got too many contributions, we don't know how to make reviews. Like I'm just trying to understand where are the biggest challenges you folks face? When managing this project as a whole? I think I would say we do have a lot of full requests, but not many hands to review, because that's I think one of the so what happens at times is the full request, it's there for a lot of time, a long time and sometimes it might take time to merge, sometimes it might also happen that we are not able to merge because it's not currently in the roadmap or it's not aligning with the roadmap which we are looking into. So that's the sad part where we do have full request, but we are so one of those full requests if I remind if it reminds me is the magic so integration and that we are setting unfortunately for a long time, but due to some few of the reasons of you know, making it heavy on a Scalid draw and things like that, we have few concerns, we haven't been able to merge it yet. So I think these kind of full requests is one of the hardest challenges where we really want to push the features, but we haven't yet thought of the right way, should it go as a plug-in, should it go into the core, should it, how can we improve the bundle size so that you know, Scalid draw doesn't become heavy for the users. So those kind of things are challenges when it comes to bigger feature requests which are good to have which are requested, but unfortunately we still haven't been able to and sometimes also bandwidth of course, bandwidth is I think one of the main reasons where we might not have enough bandwidth to review and merge the full request as soon as they are raised so that might also take some time. And I think that this is something which happens in all the open source projects out there. OPEC says is about, you know, so I think the way it can be made better is first create an issue and discuss with the maintenance that you know you are planning to build this feature, what the maintenance think about it and how can we go about it and then actually start on the implementation because this if there's a full request which is really useful to you, you really want that feature, but in case it doesn't align with the project then it appears might just sit there for a longer time. Of course, the last solution is to fork that what keep using it that is definitely the one solution so that you are not blocked on the main project, but I think this is one sad part which can happen in any open source for other south there when it doesn't align it might maybe sit there for a long time as well. Even the imping package I was talking about as I mentioned it took me around six to eight months to convince. So it's definitely one of the challenges in every open source repo you know for every maintainer out there who are maintaining the repository is so yeah. It is it is absolutely like you know merging PRs and the amount of traffic especially popular repository you have sometimes it's just unbearable but we haven't talked about complexities in the code base so I'm curious to understand like what is the complex bit of Excalitro from the code point of view. I think from the code point of view I feel looking at the current code base as I mentioned we really need to work on refactoring part so that right now the code base is not in a stage I would say an absolutely happy with or as a team we are really happy with it. So yeah there is there is a huge refactoring needed on the code base. We also have files I don't know which has I don't know maybe five thousand let's go so those needs those needs to be refactored in a way which is more readable more manageable and it will ultimately it will also impact the bundle size you'll use the bundle size as well over also. I think that's one of the that's one of the complexities in the code which we need to solve for sure and it's just about the time when we get the chance to solve but this is something in priority which we really need to work on. So this will definitely make it easy for the new onboarding people to contribute as well. Got it got it okay so I want to ask you like we talked about missing features now you mentioned about the tables you mentioned about the formatting and I also talked a lot about like refactoring I'm actually curious like what's next for Excalibur. Are those things very folks are working on that are like coming in the immediate future or are you working on something else that you haven't mentioned that you feel like hey the next big thing will be this. I think so tables are something which we did start it's just that I need to get back on the implementation part there is an RFC which is open there apart from that I think there is a lot of features which are coming up and which have been released recently as well one of them was the canvas search which recently was released basically you can search for any particular text on the whole on the whole infinite canvas. That was one of the nice features to have and NPM Package is something which we want to improve the API zone that is something that is a parallel thing which I think will go on for a long time it's not like it will be completed in a short period of time and yeah I think features wise I think there are a couple of like there are smaller features small improvement features also being released frequently to improve the user experience but the bigger ones I think is something where we really need to spend a lot of focused time which will take some more time for us as well to do but yeah I think updates as in updates wise yeah undo redo was one of the biggest releases recently where it all every collaboration also it works so until from the beginning we didn't never had the undo redo when it comes to collaboration but now with the recent updates every collaborator has their own undo redo stack so that was really a nice feature so yeah I think we will keep releasing on you which Elbow arrows was one of the most recent feature wise where you can have should we have those Elbow arrows and one of the features which I like is you can actually create flowcharts with command and arrow keys that's interesting so these kind of things will keep coming on but yeah probably the next big feature which we really want to push is tables but that will take some time it's again our complex feature to work on and but yeah I think there are a couple of other things which are there the road map part of this as well which we will be pushing out slowly got it so talking about yeah features that we folks added and so on I I checked the xkydrow.com UI and it seems like you added AI support also I who process or product doesn't have it those days and I'm Chris to hear a little bit about it like what is that thing is that what is it doing yeah so my main so basically it started so without AI it was my matrix calidrow and that also reminds me we need to add more diagrams support in mormade so that's again a good way to contribute as well if you if you are using mormade to a scale of feature and you feel there is this particular diagram type missing please so you know you can always contribute to my matrix calidrow repo just so it started with mormade to xkydrow and then we added the support for text to diagram where you basically describe your diagram and and and it basically uses the open AI to convert it to mormade and then from mormade we already have the convertible and apart from that there is diagram to code feature as well where you basically draw the diagram and it gives you the UI and with the like we also have the code embedded into it so you basically get the code from the diagram so yeah these are the two AI features which were pushed the AI part is is closed source it's not open source yet but probably in future we might make it open but that is something under the description got it got it okay so as we slowly move towards the end of the episode I want to ask you if you have like more resources like blog posts videos or other talks that you gave or other people gave about xkydrow that people can watch if they're interested in learning more i work under the hood how to use it and like just relevant resources that you feel it's valuable for folks to look into if they want to learn more yeah so I think first definitely I would say you can like if you want to read about the features the hidden features one of the hidden features is you can actually paste the charts into its calidrow and it will create the charts like you just paste the data from your spreadsheet and it will create a nice looking chart this is again one of the hidden features it's not really visible in the UI but it's kind of an interesting features so yeah you can go to [email protected] and you can actually read about them I personally give a lot of talks at conferences and a lot of them are ready to escalate draw so like how the encryption works or how the text containers features work or how the label arrow works internally these are like deep dive talks how things and work under the hood in canvas so if you are interested you can actually you know check them out as well and yeah I think there are a lot of there are some kind of I guess blog posts as well which we do and we do themselves also writes at times and you can you'll find them on the [email protected] so yeah definitely you can check the check the sessions check the talks the GitHub repository is there the docs fermentation is there and I think yeah if you have any questions you can always raise an issue on GitHub or we also have a discord channel which you can join as well so there are a lot of these resources whichever you feel you are most comfortable with you're welcome and you know discuss with us absolutely and then last question is where people can find you online if they want to reach out to you ask you further questions about excalidrow or a data project you're maintaining so I am on Twitter a cancha 1216 is my handle and I'm on LinkedIn as well and GitHub anyway so discord as well I'm there so mostly you I'm active on Twitter mostly so you can always DM me on twitter or LinkedIn and if you have any questions you can always reach out to me so yeah I would be happy to help and we can discuss on you know and or the other projects this which I meant to get a really fun one. I won't get up because it's a open source. So yeah. And then we can collaborate from there. Absolutely. Okay. And with this, Akhansha, I want to thank you very much for being with us on stage today. Thank you so much Nikola for having me and happy that after so many issues, we were finally able to do the podcast today. So yeah. Thank you so much for having me. I had a great time discussing all the stuff. Same, same, same. We're in so much about Xalidro and I also want to thank everyone for listening. And I'll see you all in the next episode. [MUSIC]