Noel Minchow:
Hello, welcome to PodRocket. I'm Noel. And with me today is Elena Bukareva, who is a software engineering manager at Meta, and Acy Watson, a software engineer for the Lexical core team. Did I get all that right?

Acy Watson:
You nailed it. Yep.

Noel Minchow:
Awesome. How are you guys doing today?

Acy Watson:
So far, so good.

Noel Minchow:
Glad to hear it. Cool. Well, let's just jump right in. So Lexical describes itself as an extensible text editor framework, maybe to start off with-

Elena Bukareva:
Yeah, sure.

Noel Minchow:
...what is a text editor framework?

Elena Bukareva:
So, how can I explain? I'll give it a shot. Everyone thinks that text editing is simple. And, it's just typing and that's it. But in reality, when you're building some web products, it's not that easy. You have to do copy/paste images and do what you do. And, we don't want everyone in the world to redo all those things or build them from scratch. So, text editing framework provides abilities for our software engineers just to use existing frameworks as a building blocks, to simplify their work. So, they are focused on the right thing versus trying to rebuild something that everyone needs.

Noel Minchow:
Yeah. Perfect. Very good. Concise explanation there. So, what kind of inspired Meta and your guys' teams to tackle this problem specifically? Like, why are you guys where you and what you're working on?

Elena Bukareva:
So, the problem is not new. So, we've been editing texts for years. And Meta has already an open source project, similar to Lexical, which was called Drafts. But Drafts got outdated. There were some problems that we were not able to address, React 18 was coming, and it wasn't compatible. And, the needs for Meta apps are growing. So, we decided that it's time to build something new, that would allow us to duplicate drive shares.

Noel Minchow:
Got it. So then, I guess that makes sense to me. Is it easiest to think of Lexical as a front-end library or a component that developers might reach for, if they need to have text editing capabilities on some web platform tool they are building?

Elena Bukareva:
Yes, and maybe Acy, you can talk about it.

Acy Watson:
Yeah. I'd say that's the right way to think about it. We've tried to build it in a way such as this very modular. So, you can go down to this core library that just handles, it doesn't even handle key input events. You have this very collaborative, just like a reconciler and editor state, and this idea of immutable state. And then like reconciliation to the DOM. And then you can go all the way down to that, and build a custom solution all the way up from that bare-bones framework. Or, you can do something like, use our Lexical React package, which has, as you mentioned, components that are built in. You can just drop the Lexical composer component into your webpage, your React app, and then, pull some plugins in and have a working text editor. So, it's like it runs the whole gamut. It's got that level of flexibility and sort of modularity.

Noel Minchow:
Got it. So, if I weren't using Reactor, I'm sure there's a view wrapper library that interfaces with that API as well. But, if I weren't using one of those, or Angular, or whatever, what would I need to do, to interface with the lower level pieces of Lexical?

Acy Watson:
Yeah. So, without going into too many specifics, basically, the only thing you really need is, you have to have the Lexical core library and a contenteditable. And then you attach an editor, to the contenteditable, and then you're going to start wiring up events. So, you'll have different events and Lexical has its own command system that you can also use to direct the editor. And it's take some inspiration from the, now deprecated execCommand API that was present in browsers for a while. And, other similar editors have command systems. So, that's basically what you need to get started. And, that's if you go all the way down to the bare bones. But, as you mentioned before, most people are going to want to use something like the Svelte bindings or the View bindings or the React bindings, to get started with their favorite editor framework. So, yeah.

Noel Minchow:
Got it. That makes sense. So, if most users are consuming Lexical as a React component or a View component or a set of bindings that they can integrate with their app, is there any concerns that they would need to have thinking about those internal workings of Lexical and how it, saves and presents data, or is it all pretty well abstracted when one's working at those higher levels?

Acy Watson:
Yeah. At the higher levels, we really try to... This is a big thing that Dominic, the original author Lexical took from his time on the React team, was this idea of taking, what we really tried to do here is, take things that are typically considered edge cases and make them part of the framework, so that you don't have to think about them. And, I'm talking about things like how we handle composition or IME, like, input for Chinese and Japanese characters, that's kind what I have in mind. And so, I would say generally speaking, we try to make that not something unique to think about. And, that goes for everything.

Acy Watson:
And we have created a set of plugins and a plugin system for React specifically, that we use internally as well. But that is something that's supposed to be just very much like plug and play. Here's your Lexical composer. If you want to add, code highlighting functionality, then drop this plugin in there it's declarative. You have Lexical composer and then the Lexical code highlighting plugin, and you're good to go. Of course, the more specific and complex your needs and use cases are, the more you might have to dive down through the layers. But, that's to be expected.

Noel Minchow:
Got it. So, is the target demographic then...? I mean, ostensibly the end user of Lexical, is anyone who would be on the web using a text editor on some website. But, the audience of Lexical is developers who are in the middle somewhere where they've got an editor, but they want it to be a little bit more, feature-rich maybe than just like some simple component they'd pull off the shelf. Do you guys find Lexical being worked on and picked apart and talked about mainly by devs who are working at some abstraction layer in the middle, they're working on a component library or a CMS or something like that, or is it mainly people who have some specific bespoke use case on a given website? And those are the consumers that end up working with you in the repos and in those discussions?

Acy Watson:
Yeah. I would say, anecdotally, we have a Discord channel that I'm pretty active in, most of the engagement that we see on there is from people that are trying to build some sort of specific type of text editing experience, for end users on a website as opposed to like, [inaudible]. We actually did have someone recently, that did create a component library or some sort of abstraction over our, I think our, we have a playground. And it's just a fully-fledged editor in the playground, and someone took that and packaged it up and re-exposed that as an out of the box editor experience. And, we were like, "Cool, if you want to do that, go for it."

Acy Watson:
We don't want to maintain that, particularly right now. That's our playground, just where we show up things. So, we do have people doing kind of, make a drag and drop component or a drop-in component. But, the bulk of what I've seen is people that are trying to build some unique editor experience or just one that has slightly different, nuances to it than might come with an out of the box editor.

Noel Minchow:
Got it. Yeah. That makes sense to me. Let's say I'm using Lexical directly or using some library that is implementing it in some manner. How can I style and make Lexical, even if the functionality is all working there, like with plugins that are already written, and I don't have to do anything too crazy, but just like styling and formatting and making stuff look the way I want it to. How do I do that as a developer?

Acy Watson:
Yeah, totally. For styling, there's this concept of editor configuration. So, when you initially create an editor, or when you use one of the abstractions, there's a prop, I think for Lexical composer. We have this thing called editor theme classes or something. And that just basically is giving you a place to add your own CSS classes. And we'll slap those onto the actual DOM that Lexical ends up creating.

Acy Watson:
And so, you can really have pretty low level control, over the components or how the user's composition is visually represented through that styling. You can even go to a lower level as well, if for whatever reason that's not meeting your needs, let's say you want to change how a paragraph looked, you can actually extend the paragraph node. We use an inheritance pattern for that, make my cool paragraph node, and have that render whatever DOM you want. Whatever HTML you want.

Noel Minchow:
Nice. Yeah. That makes sense to me. Can we talk about real world examples or cool implementations that you guys have seen that you've been proud of? I'm just curious if there's any websites that listeners would be using all the time where they may have been using Lexical and they didn't know about it, or even just again, really cool use cases that you guys have seen in the past.

Acy Watson:
Yeah. So, it's early days still. I think for us, we've worked with a lot of individual companies who are interested in using Lexical for different things. I would say we have seen some wins, in terms of people saying like, "Hey, I use Lexical to replace the current editor at my company, and I saved this many thousands of lines of code. And, I got rid of a bunch of custom code." I'm not thinking of a specific example right now, obviously. I don't want to name drop anyone, but-

Noel Minchow:
No, that's okay.

Acy Watson:
...But yeah, we have seen that type of thing. And so, we've seen some wins around like, "Hey, I took my existing editor and replaced it with Lexical and turns out that I was able to save a lot of codes and simplify things a lot that way." I think in internally, we've been able to do a lot of interesting things with Lexical in terms of embedding rich things. I'm trying not to give too much detail or be too specific here. But, being able to embed a lot of rich content in places that's really helpful for our employees that we weren't able to do before. And so that's been interesting to see as well.

Elena Bukareva:
Yes. So, some applications that I bet you are using daily, like Facebook, WhatsApp messenger, they all use Lexical. So, when you use those, you are using Lexical.

Noel Minchow:
Yeah. That was going to be my next question. Like Facebook properties, surely we're using Lexical. Sorry, Meta properties, surely we're using Lexical.

Acy Watson:
Yeah. That's exactly right. I mean, that's all those things. When you say interesting, my mind immediately went to the open source community, but of course, yeah, we have so much going on internally. And so many surfaces where composition's so incredibly important and impactful. And Lexical been really good for us across all those so far.

Noel Minchow:
Yeah. This is kind of a tangential question, I guess, have you guys noticed any benefits from working on an open source tool like this, but having a large, entity that is using this open source project, very heavily in production with thousands of users every day, has that avenue for feedback, been beneficial in development and iteration?

Elena Bukareva:
That's been really great avenue for feedback. And people are providing feedback much faster than our small team. We're just seven engineers. And, it is really beneficial for us to get feedback much faster than we can find things. And of course, getting feedback for things that we sometimes didn't anticipate it even, like to test. That's really awesome.

Acy Watson:
The open source community has been such a huge blessing and just finding all these, issues that we never would've thought. Because, the implementations that we have internally, they're just different than what other... Once you release something into the wild, people start doing all kinds of crazy stuff with it. And you start finding all these things that you, never would've even considered, had you just use it internally. And so, it's been just really a huge win for us to release it into open source.

Noel Minchow:
Nice. Yeah. That's kind of the open source stream. It's like everyone iterating on the thing makes it better, and you find all the edge cases and it's all there and it's great. That's super cool to hear. Awesome. So, just going to pivot us back a little bit. Now talking about features specifically, Elena, you touched on accessibility a little bit. And how there's a bunch of tricky problems in text editing that people wouldn't really think about if they just set out to do it all themselves. What are some of those problems and pitfalls that devs might fall into if they just try to spin up their own text editor from scratch?

Elena Bukareva:
So, we spent a lot of time and we partnered with multiple vendors, just to provide audience for accessibility as Meta is really driving accessibility. And we, being part of enterprise engineering, this is really something that's we're passionate about. We were looking at all the corner cases and all the accessibility features that we need to support like, speech-to-text support for Dragon. This is the most popular speech-to-text software, as you probably know. Accessibility type heads, semantic markup, keyboard shortcuts. And Acy can talk a little bit about technical, part of the problem. I'm mostly around business.

Noel Minchow:
Sure.

Acy Watson:
Yeah, totally. Elena is right about all that. There were gaps in our internal solution at Meta Draft.js. There were a lot of gaps in accessibility there. And so, when we set out to redo this, it was something that we really wanted to do. We wanted to get it right. And so, we worked with a third party vendor on this, we had a dedicated resource internally helping us with it. It turns out that the public specifications, like WCAG, doesn't really have a lot of specifics on how text editors should work from a accessibility standpoint. So, we ended up doing a lot of user testing. A lot of working with these vendors to figure out what behaviors do people actually expect.

Acy Watson:
And what is actually going to be easy for them to use. And, we found is that a lot of the tech setting experiences out there were falling short on things like, even internationalization, like IME, I think I mentioned it earlier, like the keyboard. The Chinese and Japanese characters, JAWS, screen readers, HugeThing. Even attachments, like Grammarly, we found out that a lot of people that have English as a second language, use Grammarly to help them communicate better with their coworkers. But, a lot of text editors just don't handle Grammarly input as well. Grammarly is an extension, I guess that helps correct grammar when you're composing text. And so, all these things we considered and looked at them and said, "How can we make something that's going to work with all of this out of the box?" Basically, we want to enable people to make accessibility first tech setting experiences, like things that are inclusive by default. It's kind of been the catch phrase that we've used and so.

Noel Minchow:
Awesome. Awesome.

Emily:
Hey, this is Emily. One of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you, there would be no podcast. And because of that, it would really help if you could follow us on apple podcasts, so we can continue to bring you conversations with great devs like Evan You and Rich Harris. In return, we'll send you some awesome PodRocket stickers. So check out the show notes on this episode, and follow the link to claim your stickers as a small thanks for following us on Apple podcasts. All right. Back to the show.

Noel Minchow:
That leads me to an interesting philosophical question that again, I understand it can be a little bit hairy in here. But I'm curious then, it sounds like Lexical is trying to solve a lot of problems that it feels like almost everyone would have. Anyone that wants text input of some kind, especially complex text input, would want a set of tools or the baseline to be pretty strong and accessible and easy to use. Is there a reason that you guys can think of that a lot of this work that you're doing wouldn't make sense to put into the specs and the standards for HTML? So, for example, if I ask for a text area that's editable, to get something flexible, just natively that the browser gives me. Is that a reasonable question?

Acy Watson:
I think it's a reasonable question. It's one that I've ruminated on a bit recently. I think that it's been tried. Well, at least the idea of implementing something like this has been tried. That's what contenteditable is. I think the vision for contenteditable and the vision for the execCommand API and the surrounding tech was to be able to have a lot of these things built in. But, I think the failure came in around alignment, getting these things to all work the right way across all browser vendors, turned out to be a big challenge. And so, I would like to ultimately see it happen, but I think in order to get that to happen, is a long road ahead. And it's, like I said, been tried before. And so right now it's left with the community to get this right. And so, we'll see how it goes.

Noel Minchow:
Yeah. I feel like having an open source tool there doing it and pushing it forward in this way is a pretty good medium, for now, until the standards can give us some of the stuff out of the box. Do you think, I guess, then, a layer up? Say standards are evolving over time and we get a little bit healthier of a native text editing experience. Do you think Lexical will be adaptable to use the browsers as much as we can, but then put the pieces on top of it to make the dev experience really nice. Make it really accessible for all of our users, and also extensible for people that are doing more complex stuff?

Acy Watson:
Yeah. I would say totally. To the extent that they still necessary to have something like Lexical as the standards evolve. I would say I think I see a place for it, but just depending on how things work out, if and when a standard's created and if, and when browsers try implementing this tech. The whole point of Lexical in a way, is to create this like simple API surface that allows you to do all these things and it works across browsers, across platforms. And you interact with one simple API. And so, to the extent the browser is providing that for you, then Lexical becomes thinner and thinner. And so, it could still be an abstraction of, I think some of the abstractions and more sophisticated functionality we've built could still be useful, but maybe the core library just becomes thinner and thinner, I don't know.

Noel Minchow:
Yeah. I think regardless, again, having people doing the work and discussing it and talking about it and finding issues and bugs and getting all of this captured and worked on, iterate on, is a net benefit for everyone, almost inarguably. So, yeah, I was just curious, because I was kind of having this discussion with one of my colleagues the other day, and we were talking about component libraries and the necessity of them over time. And I was arguing in favor of using component libraries because they're still doing a lot of heavy lifting in terms of accessibility and stuff for me. So I don't have to worry about that stuff, like I can assume that my table layout will look good and varying widths and people with screen readers and all that stuff, like all these problems that are kind of tricky for me to solve. Anyway, so that led me to this line of questioning and yeah, it's just a very interesting space.

Acy Watson:
That's something we see as a huge contribution of Lexical. When you think about other text editors, there're already great text editing frameworks out there. There are great ones out there and ones that have had a lot of time and effort and thought put into their designs. I think one thing Lexical did is it just moves the community forward in the sense that it says, "Well, here are some concerns that we see that weren't totally addressed. Here's how we address them. And made a framework that holistically takes care of that stuff for you." And that's one step forward in the direction of making a holistic solution to that problem across the web.

Noel Minchow:
Nice.

Acy Watson:
Hopefully we did some good.

Noel Minchow:
Yeah. I think so too. That segues me nicely. So, there are other text editor tools one can pull off the shelf as a developer to help with this stuff, and we've talked about that. When you guys in the early days, I guess, I don't know your timelines in respect to Lexical's timelines, but were there other tools that you were also evaluating? Other open source projects that you looked at or anything like, should we maybe piggyback on top of one of these other tools and start working on that there? Or, was it pretty clear from the onset that this was going to be a project that you guys wanted to maintain from the ground up?

Acy Watson:
Well, I can't speak to the very, very early days of, I joined the project about six months after it started. And so, I can't speak to Dominic's motivation or what he considered as far as other text editors when he was going through the process of saying, "I need a text editor, which one should I use or should I make my own?" I don't know how exactly that thought process went. What I can tell you is, as a large company with a lot of services, what a lot of times we really need to have low level control over the tools that we use. And so, while it can be a good idea to rely on third party, open source tech and we do that. It can also be a liability when you start to run into the limitations of that technology.

Acy Watson:
So that's one reason why we would choose to just do something ourselves, even something as complex and ridiculously hard as text editing. We also just had some specific things up front that we knew we needed to address like React 18 support. Which React 18, I don't think was even formally released when this was started. And so, there were a lot of things that we just weren't comfortable.

Acy Watson:
So, I could guess some kind of conjecture, now we're speculating on why Dominic made the decision to create his own editor. Even though I said I wouldn't. But, those are kind of my thoughts on that. And I would say, throughout that process, and even to this day, we've still been heavily, heavily inspired by what's already out there, Pro SME slate, Quill. All these are, like I said, wonderful text editors and we've taken inspiration from a lot of what they've already done, and stood on the shoulders of giants, so to speak.

Noel Minchow:
Yeah. Awesome. Do you have anything you wanted to add, Elena?

Elena Bukareva:
Yeah. So, Lexical was created for Meta, for Meta specific needs. And, when we realized it, and this evolved over time. So, we started with just plain text editor. Then we saw an opportunity to expand it. And once we built it, we realized that we wanted to share it with the world, to get more feedback. That's why we open-sourced it. But it's really, it was built for Meta, and that's why we have some specific criteria and requirements.

Noel Minchow:
Gotcha. Yeah. I'm also curious if we can go back to features a little bit. Is there any native support for functionality beyond a form or an editor that someone's working on? I'm thinking collaboration or real time multi-user editing of data. Is that in Lexical's purview or is that kind of upstream?

Acy Watson:
Yeah. So, what we do on that front is we provide, bindings for yjs, which yjs is a CRDT. The exact expansion of that acronym is conflict-

Noel Minchow:
Conflict-free replicated data type, I believe. Yeah.

Acy Watson:
So, yeah. You obviously know about yjs. And so, we just provided some bindings for that. And Dominic was working closely with the creator of yjs who I think Kevin is his name, to make sure that we could do something that worked well with Lexical and with the data structures that we were using and things like that. And so, we've solved some problems on that front and made it more easy for people to create real time collaborative experiences with Lexical. And so, there's still some legwork to do if you want to do that. Obviously there's a little more to be done than just turn it on. But, it is possible and it's relatively simple, with the bindings for yYjs that we've exposed. So.

Noel Minchow:
Nice. Have you guys had to work on that code much or solve issues? I'm just thinking with CRDTs, the implementation of conflict-resolution is somewhat non-trivial in that, I think text editing there are use cases where you would want a true conflict. A user's offline for a long time, then two users are both editing a sentence. How do we then resolve this word or sentence that's been edited by both users once the data syncs. Because there is a conflict that needs to be considered or at least rules that need to be put in place to figure out what the desired end state is. Is that something you've had to work on?

Acy Watson:
I personally have not had to work on that. That's something that I wasn't personally involved in developing that part of it. So, I can't speak too deeply about the challenges there. But, my understanding was that yjs handles a lot of that. It's kind of we've offloaded a lot of that conflict-resolution to the yjs library. But, Elena might actually have a clearer picture than me having been working on collaboration a little bit recently.

Elena Bukareva:
Yeah. So yjs provides a lot of this out of the box. And, we are still in early stages for doing collaboration for Meta. So, we still have to run into multiple issues, I guess. So, maybe we are happy to return back and talk about cooperation in the future.

Noel Minchow:
Yeah. Maybe we'll have you guys on in a year or something and we can figure out, all the problems that you've solved. Yeah.

Acy Watson:
Totally. I'm sure we'll have some good war stories by then.

Noel Minchow:
Nice. It sounds like there is support for it and it's on your guys' radar. Are there users? I guess, is it in the wild anywhere, that you know like the real time text editing? I guess, maybe a better way to frame this question would like, if I were working on a project and I wanted to have collaborative editing, is it in a place where I could go pull Lexical off the shelf and use it and it would work in most cases?

Elena Bukareva:
For now, I guess it would work, but you still have to do some leg work as we mentioned. And, as we have not tested it in production ourselves, so that's why we cannot really speak how good or bad it would be.

Noel Minchow:
Yeah. That fair. So, would I need to bring my own, data store and stuff like that. What is Lexical opinionated about in that regard?

Acy Watson:
As far as the collaboration thing, it's sort of just a thin abstraction over yjs. You don't need your own data structure or anything that. You would be sending Lexical the editor state over the wire. But yeah, once again, I'm speaking out of my depth here, because I haven't done a lot of work on this. My understanding is we have this JSON data structure. It's a tree structure, that the way you represent the composition, all the nodes in the tree. And then, when we send that over the wire with yjs, it's flattened into some kind of flattened tree structure. And then that is where the conflict-resolution takes place in that format. And which I guess doesn't really answer your question at all, but these are the things I know about collaboration and how it works so far, so yeah.

Noel Minchow:
Yeah. No, that's perfect. I think I'm curious about, how do I wire clients together and figure out which entities should be resolving against which other entities? And how do I get the data in and out and figure out what should be resolving against what? Is the piece that I'm curious about. And again, I'm sure we can go look at the docs and figure it out.

Elena Bukareva:
Yeah. So it's been resolved on a client level. So, yjs would be resolving and the awesomeness of yjs is that each client will know and is guaranteed that the document will be in the same state.

Noel Minchow:
Yeah. Gotcha. So, when I've done yjs work in the past, I still have had to, in my web app, I've got to build the logic to say, "These two users are in a shared pool, editing the same document." How do I tell Lexical, which entities are editing the same field? Does that make sense?

Acy Watson:
Yeah, I think, once again, I haven't looked at this tech that closely. But, I think that we have an ID that you assign or something like that, that share things like maybe a name space. I can't recall-

Noel Minchow:
An app identifier or something.

Acy Watson:
...exactly. Yeah. I can't recall exactly how all that works, off the top of my head, but-

Noel Minchow:
No, worries. Again, I was just curious. Because, that seems a really cool feature, that is not really easily implemented anywhere yet. That kind of collaborative editing, is still non-trivial for most devs to implement. And that's why I'm curious about it. Because I think that there's a lot of people that will be like, "If I can pull collaborative text editing off the shelf and it's really easy to just get working, that would be pretty sweet."

Acy Watson:
Yeah. Like I said, I wish I could go deeper with you on that but I would be doing you a disservice and your listeners, because I just don't have the depth on that part of the code base, unfortunately.

Noel Minchow:
No worries. So that's okay. That actually segues me nicely into my last big question. What's next on the roadmap, what do you guys spending cycles on right now?

Elena Bukareva:
So, working on OneZero release, is a big milestone that's we anticipates in H2. Acy, maybe you will share some details.

Acy Watson:
Yeah, totally. So, a big thing for us, we've seen some good adoption. We've seen a lot of engagement with the community, a lot of contributions from external contributors. And, one of the things that we've started to see asked recently is, "Hey, I want to use Lexical for this project that I have at my company, but, when I pitch it, people are calling out that there isn't a stable release yet, you guys are at beta versioning," and that's true. We are not at V1 yet.

Acy Watson:
And so, a big thing, I think for us, to continue to get traction in the community and reinforce our position or the idea that this is Meta that you can depend on and that we're, we really need to solidify the API and just say like, more than that, probably produce a roadmap to say, "Here's where we're going to go, to get to V1. Here are the bridges we need to cross to get to V one. And here's our, our target for that. And just to give people a little more confidence. And so, I think that's a big thing for us moving forward is getting that figured out, like what do we want to do? And a rough timeline for it. Other than that, I think we have some interesting things going on. We can't go into too much detail yet on what those might be. But, we're very excited. I hope you guys will follow along and watch the space as we move forward and see where it goes.

Noel Minchow:
Nice. Yeah. I guess on, on that note, if listeners do want to keep tabs on Lexical and keep an ear to the ground, where should they be looking?

Acy Watson:
Yeah, definitely. You can follow us on Twitter. It's @lexicaljs. We try to keep that up to date. And then, really the most active place is our Discord channel. We set that up as a place to engage with the community. It's really grown massively and so we have a lot of activity in there and we end up making a lot of announcements in there and things like that as well. So, encourage people to join the discord. It's on the website, I think, which is lexical.dev. And there's a community page with the information for joining the Discord and Twitter and all that stuff. So.

Noel Minchow:
Nice. Yeah. We can try to get the Discord link as well as that link in the show notes so people can find it more easily. Anything else you guys want to leave us with?

Acy Watson:
Elena?

Elena Bukareva:
Not really. Just wanted to share that we are excited about Lexical project and we are really grateful for the feedback that people were providing, on open source community and on this Discord channel as Acy mentioned. So, we're hopeful about our future.

Noel Minchow:
Yeah. Awesome. Well, yeah. Thank you guys so much for joining me, Acy and Elena. It's been a pleasure chatting and nice to meet both of you. Hopefully. Yeah, we can be in touch soon and we'll get some more updates on what's going on with Lexical.

Acy Watson:
Awesome.

Elena Bukareva:
Thank you.

Acy Watson:
Thanks.

Kate:
Thanks for listening to PodRocket. You can find us @PodRocketpod, on Twitter. And don't forget to subscribe, rate and review on Apple Podcasts. Thanks.