trueadm

Sure thing. I actually wrote up a really detailed response to this on ProseMirror's discussion board:

https://discuss.prosemirror.net/t/differences-between-prosem...

Ultimately though, there are many similarities between the two – intentionally so. We were inspired by ProseMirror and some of its APIs and approaches. I think the biggest underlying differences are in how we tackle things from a DX perspective. We tried to bring a more composable API to making text editors work – from the plugin patterns, how updates and reads work, to how you listen for changes and react to them. Much of this was inspired by my prior work working on the React core team and from creating Inferno.

I'm the author of Lexical and one of the many engineers working on Lexical full-time at Meta. If you'd like to know anything, or ask any questions, please do!

For those of you looking for the sourcecode for the playground, you can find it here:

https://github.com/facebook/lexical/tree/main/packages/lexic...

We also have a Discord channel you can check out:

https://discord.gg/KmG4wQnnD9

I had to take a second pass on it. I thought I was maybe onto something when I wrote that originally. Is it a V8 perf hack? Nope, just my brain not functioning correctly at the time :P

Adam? You mean Dominic/trueadm? We have some ideas for supporting RN once we have iOS/Android versions of Lexical.

Yeah, I'd roll with Node/Deno and use Lexical that way. :)

Don't you need `slate-react`, `slate-history` and other plugins too?

Lexical's model might become a bottleneck at some point, but we haven't done any extensive testing on huge models (I mean really huge, we know large models are fine). There are so many things folks want to do with text editors – from small plain text editors to WYSIWYG, to full blown code editors. We're hoping the community can help us fill in the blanks on some of these areas, as we're only a small team.

We'll look into fixing this problem. Sorry for the confusion!

The EditorState is fully JSON serializable. You can use JSON.stringify in the browser, or an alternative on other platforms. You can then pass the stringified values around and parse them using `editor.parseEditorState()`

I don't think ProseMirror has taken a bad approach. I think we've just taken a different approach when it comes to the design of things. In Lexical, you rarely concern yourself with the DOM – and typically you deal with Lexical's node API directly and that's really all you touch.

Lexical also treat its own EditorState as the source of truth. We use DOM MutationObservers to ensure the DOM matches the EditorState at all times. We do allow external mutations from things like spellcheckers update Lexical – otherwise people wouldn't be able to use Grammarly and other tools with Lexical. However, that's really constrained so that they don't overreach.

Lexical also has the notion of double-buffering. When you update Lexical, or use a node transform, you're actually mutating the "work in progress" EditorState. Once Lexical feels that the EditorState is ready, it will commit it to the DOM, and that EditorState will become immutable and will reflect what you see on the page.

Good to see you too! I moved from the React core team about 2 years ago, and since then, I was fortunate to be able to build a team around Lexical!

Yep, I’m the same person still :p

Awesome! Thank you for this. Would you be able to upload a video or maybe add more context in a Github issue? It's really difficult getting Android right.

The combination between browser + keyboard + OS version + keyboard language, it just makes it so much harder than it should be for Android. So any additional context you can provide will be a MASSIVE help. :)

By the examples, do you mean the fact we are using Codesandbox embed to show code examples of the editor itself?

Lexical definitely has the foundational requirements capable of building a CodeMirror or Monaco editor, but that wasn't our initial target with this library. That doesn't mean that we don't expect the community to push it that way in the future, we fully expect that. Let's see how things go, competition is healthy! :)

Yep, we have full support with Yjs. https://github.com/facebook/lexical/tree/main/packages/lexic...

I completely understand. I can't guarantee anything, no on can in software. However, we do have a dedicated full-time team working on Lexical. DraftJS never had that, it only had a few part-time maintainers at Facebook.

It is in production at Facebook. We're slowly rolling out to more surfaces, replacing our existing DraftJS implementations as we go. We've noticed a big improvement internally from doing so, both in terms of less bugs but also performance and accessibility.

ProseMirror wasn't a good fit for us because it's integration (especially with React 18+) isn't quite there. Furthermore, we're also looking into building native ports of Lexical, and given's Lexical's API isn't DOM centric, it allows us to do that.

Lastly, we found ProseMirror was too heavy in terms of bytes for very minimal almost plain-text interfaces where we only wanted mentions + hashtags + custom emojis. Lexical comes in at around 22kb min+gzip, so it works really well for us.

Yeah, you could easily do that. We do the exactly that right now for Workplace.

You could also roll with a `<textarea>` but that can be limiting if you want additional functionality further on down the line – such as mentions or inline markdown shortcuts.

It's used on Facebook, Messenger, Workplace, Instagram and soon will be rolled out for WhatsApp web.

I've responded to the same question https://news.ycombinator.com/item?id=31022152. :)

Internally, we've been replacing Draft.js with Lexical. To be clear though, they're different projects with little API compatibility. We hope to add some docs explaining how we've approached our upgrade path in the future.

To expand on this further, I'll pull this from another HN thread:

Draft.js was built a long time ago when many of the concerns around making contentEditable work stemmed from patching browser-support. Today, it's nowhere near as bad. We can leverage modern events and we can try and tackle things from a different point of view. One of the core things we've tried to do is make the developer experience and performance better. DraftJS pulled in a lot of JavaScript and much of it was hard to reason with because of the lack of types. ImmutableJS just didn't scale how we would have liked it to, and from our experience, developers didn't really like using it all that much. DraftJS also had a block based approach, which quickly fell apart when you wanted to do something more complex. Not to mention compatibility with React 18+ and the countless issues with having to depend on ReactDOM for rendering when fighting with browser extensions that want to take over control of the DOM from Draft.

With these things in mind, we looked at how we could keep the good ideas from Draft, Slate, ProseMirror and also invent some new ideas of our own. Lexical doesn't have any dependencies, so you can use it with Svelte or Solid (once their bindings have been created), or any other framework of your choice. Lexical also doesn't need ImmutableJS, which means the APIs are fully typed in Flow and TypeScript, reducing issues. Lexical is also around 22kb gzip+min, so it's far smaller than Draft. Typing performance in our testing is around 30-70% faster compared to Draft.

Yeah, we're still working on our docs. Watch this space! :)

You could definitely build a code editor with Lexical. There's already a lot of interest in the community to add plugins around Lexical to match that of ProseMirror. It might not be there right now, but the foundations that make it possible aren't missing.

You don't need React. Lexical has no dependencies, so you can build bindings for your framework/library of choice. There are folks working on a SolidJS implementation right now. You could also do it with VanillaJS if you wanted too.

The reason we have React bindings from the start, is because we needed these internally at Meta.

They are intentionally similar, ProseMirror has some great ideas. We tried to tackle those ideas from an extensible angle where nodes themselves, which form part of a tree, are the core to everything in Lexical. There are no "marks", instead you just use properties on the given nodes and treat them in an immutable sense. Nodes also present a set of createDOM/updateDOM methods, that allow you to define you DOM element, and its properties, to be passed back to Lexical's DOM reconciler.

You can imagine the EditorState in Lexical as not only the source-of-truth for your editor's data, but also the virtual DOM for your view. Lexical diff's both and applies delta based on dirty node logic to improve performance. Furthermore, any mutations to the DOM outside of Lexical and reverted back to Lexical's EditorState – to preserver source of truth.

Lexical also promotes different types of "text" properties on the TextNode class. Such as if the node is segmented, tokenized etc. This is a far better accessibility experience, as it ensures you can build rich text nodes – like custom emojis, or hashtags, or mentions without bailing out to contentEditable="false" which is what almost every other editor promotes. Which is also a major hinderance in terms of the ability to properly utilizie NVDA, Jaws and VoiceOver to move selection through the characters (in most cases, they skip non contenteditable elements entirely, which is terrible).

It does. If you get the chance to try Lexical out, please do let us know of any issues you face when using Android, as I'm sure there are some we've yet to find yet.

Draft.js was built a long time ago when many of the concerns around making contentEditable work stemmed from patching browser-support. Today, it's nowhere near as bad. We can leverage modern events and we can try and tackle things from a different point of view.

One of the core things we've tried to do is make the developer experience and performance better. DraftJS pulled in a lot of JavaScript and much of it was hard to reason with because of the lack of types. ImmutableJS just didn't scale how we would have liked it to, and from our experience, developers didn't really like using it all that much. DraftJS also had a block based approach, which quickly fell apart when you wanted to do something more complex. Not to mention compatibility with React 18+ and the countless issues with having to depend on ReactDOM for rendering when fighting with browser extensions that want to take over control of the DOM from Draft.

With these things in mind, we looked at how we could keep the good ideas from Draft, Slate, ProseMirror and also invent some new ideas of our own. Lexical doesn't have any dependencies, so you can use it with Svelte or Solid (once their bindings have been created), or any other framework of your choice. Lexical also doesn't need ImmutableJS, which means the APIs are fully typed in Flow and TypeScript, reducing issues. Lexical is also around 22kb gzip+min, so it's far smaller than Draft. Typing performance in our testing is around 30-70% faster compared to Draft.

I'd recommend checking out the playground and its sourcecode and seeing what you can build yourself with Lexical. We really think we're on to something here :)

We don't have any examples right now, but you could easily do this with a DecoratorNode. See how we create the EquationNode on our Lexical Playground repository. We also have our own code block too, which, with a bit of TLC could be something that could rival Monaco/CodeMirror. We plan on adding virtualization and a bunch of other things in the coming months.

Lexical is a different take compared to ProseMirror and CodeMirror. We took a lot of inspiration from them, but we felt that having a source-of-truth that wasn't the DOM was a better approach. We also looked to improve on code-size, performance and accessibility, which are often forced on the user to implement in those editors.