Facebook open sources Lexical, an extensible text editor library(lexical.dev)
lexical.dev
Facebook open sources Lexical, an extensible text editor library
https://lexical.dev/
140 comments
For 1. 2. see @trueadm's answer here - https://news.ycombinator.com/item?id=31022152
3. Lexical is not strictly tied to collaboration but its plugin system was built to be extensible enough to cater all developers needs. Collaboration is just another plugin (@lexical/yjs) and does listen and perform the conversion every time there's changes in the EditorState.
This model of independent plugins that can be plugged-and-played without further ado also simplifies devX as collaboration can be added later when the application is mature without the need to rethink any of the plugins that were originally created for non-collab plain/rich text.
4. Lexical Web is just the first of many. We want to port the API and fundamentals to various others platforms, including iOS for which we are already performing the initial set of testing. Cross-platform means the API, including Node's will look alike and EditorState and node's properties will be compatible even if behind the scenes the reconciler is constrained by the toolkit available on each platform (and doesn't render or behave 100% like Web's).
3. Lexical is not strictly tied to collaboration but its plugin system was built to be extensible enough to cater all developers needs. Collaboration is just another plugin (@lexical/yjs) and does listen and perform the conversion every time there's changes in the EditorState.
This model of independent plugins that can be plugged-and-played without further ado also simplifies devX as collaboration can be added later when the application is mature without the need to rethink any of the plugins that were originally created for non-collab plain/rich text.
4. Lexical Web is just the first of many. We want to port the API and fundamentals to various others platforms, including iOS for which we are already performing the initial set of testing. Cross-platform means the API, including Node's will look alike and EditorState and node's properties will be compatible even if behind the scenes the reconciler is constrained by the toolkit available on each platform (and doesn't render or behave 100% like Web's).
Thanks for the pointer. His comparison of Draft vs Lexical makes a lot of sense. I'm keener to understand the different between Prosemirror vs Lexical. He mentions that he pulled the best ideas from libs like Prosemirror.
I'm curious how Lexical is an improvement over Prosemirror's approach. As to my current knowledge,
1. Prosemirror considers state as the source of truth and syncs to subsequent states using deltas. The state keeps in sync with view allowing us to directly modify states to bring effect in the view. I hope this is the core of Lexical as well. One thing that isn't to my satisfaction is syncing ad-hoc view changes to reverse update the state. Is it better in Lexical? basically can plugins like Grammarly not screw-up Lexical's internal state?
2. ProseMirror does take a modular approach. It has zero dependencies and allows us to pull in only the necessary parts needed for our feature-set. How similar or different is Lexical in this aspect?
3. Prosemirror has a rich plugin system. Everything is a plugin - even the keyboard shortcuts. Very similar to Lexical I hope?
4. ProseMirror has a concept of Decorators i.e if you want to decorate your views without reflecting those decorations on the model. For example, if we want to underline spelling errors, but not include spelling error boundaries in the rich text's core data model. How is this dealt with in Lexical?
Essentially, I'm curious as to what areas Prosemirror could have taken a better approach!
I'm curious how Lexical is an improvement over Prosemirror's approach. As to my current knowledge,
1. Prosemirror considers state as the source of truth and syncs to subsequent states using deltas. The state keeps in sync with view allowing us to directly modify states to bring effect in the view. I hope this is the core of Lexical as well. One thing that isn't to my satisfaction is syncing ad-hoc view changes to reverse update the state. Is it better in Lexical? basically can plugins like Grammarly not screw-up Lexical's internal state?
2. ProseMirror does take a modular approach. It has zero dependencies and allows us to pull in only the necessary parts needed for our feature-set. How similar or different is Lexical in this aspect?
3. Prosemirror has a rich plugin system. Everything is a plugin - even the keyboard shortcuts. Very similar to Lexical I hope?
4. ProseMirror has a concept of Decorators i.e if you want to decorate your views without reflecting those decorations on the model. For example, if we want to underline spelling errors, but not include spelling error boundaries in the rich text's core data model. How is this dealt with in Lexical?
Essentially, I'm curious as to what areas Prosemirror could have taken a better approach!
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.
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.
quick question: I assume it ships(or supports a plugin) with a serializer to convert an editor state JSON to HTML. Does it depend on browser APIs to do so? Can it be somehow liberated out of native DOM APIs and language bindings for JSON-2-HTML in common languages like Java & Rust.
This could be a huge win for simple multi-platform rendering.
This could be a huge win for simple multi-platform rendering.
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()`
But, let's say I'd like to parse this stored state and send an email (as HTML) on the server?
My best guess is to use a NodeJS/V8 instance on the server to somehow transform JSON to HTML using Lexical's serializer (if something like that exists). Even this is tricky because it might depend on browser DOM apis for the conversion.
A better solution would be support language specific bindings to get HTML from JSON with zero dependecies.
Any chance you thought along these lines?
My best guess is to use a NodeJS/V8 instance on the server to somehow transform JSON to HTML using Lexical's serializer (if something like that exists). Even this is tricky because it might depend on browser DOM apis for the conversion.
A better solution would be support language specific bindings to get HTML from JSON with zero dependecies.
Any chance you thought along these lines?
FB essentially stopped supporting DraftJS. I think they don't use it much internally anymore. This seems to be the replacement.
One of the big frustrations with DraftJS is that Facebook moved on (which is understandable), but the core repo wasn’t given control to the community, so patches and updates couldn’t be pulled in. Obviously it’s open source and could be hard forked, but that’s not ideal.
I’d be curious if there are plans internally to make sure Lexical continues to be supported by Facebook and doesn’t end up with the same fate.
I’d be curious if there are plans internally to make sure Lexical continues to be supported by Facebook and doesn’t end up with the same fate.
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.
Agreed there’s no guarantees in software, but that’s helpful context that there’s a dedicated team working on Lexical. Thanks for sharing and also for giving back to the software community by open sourcing the code. Editors are tough and every thoughtful approach like this that’s publicly available to use helps push them forward.
Hey Dominic, good to see you :)
I take you moved from the React team to this dedicated Lexical team?
I take you moved from the React team to this dedicated Lexical team?
> I can't guarantee anything, no on can in software.
What does this mean?
What does this mean?
(1) People aren't often good at communicating their intent with language. It requires using public meanings (words) assembled in some order to reflect a private meaning which is non-linguistic.
(2) I think something like "At the moment it's funded, but I can't legally bind my org to that commitment. And in general, as software comes-and-goes, it's future utility and support is always hard to pin-down".
I mention (1) because I think (2) can be inferred from the comment, and I think we have some responsibility as readers/listeners to do that; rather than expect all communication will be clear to us.
(2) I think something like "At the moment it's funded, but I can't legally bind my org to that commitment. And in general, as software comes-and-goes, it's future utility and support is always hard to pin-down".
I mention (1) because I think (2) can be inferred from the comment, and I think we have some responsibility as readers/listeners to do that; rather than expect all communication will be clear to us.
I agree that people are sometimes accidentally unclear; that's why I asked a clarifying question.
The examples shown on the site are code editing. Which puts it in direct competition with the more established Monaco from Microsoft [1].
Competition is welcome, but the description sounds like this is more of a library than a finished product (which Monaco isn't), and if so, some examples showing how to take advantage of that would have been helpful.
[1] https://microsoft.github.io/monaco-editor/
Competition is welcome, but the description sounds like this is more of a library than a finished product (which Monaco isn't), and if so, some examples showing how to take advantage of that would have been helpful.
[1] https://microsoft.github.io/monaco-editor/
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! :)
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! :)
Having the live editor examples on the home page be live examples of a different editor (of a different kind) is more than a little confusing. I understood Lexical to be a code editor until I came here and saw your comment. The main page even describes Lexical as a "text editor", a term used for plain text like code. I suggest embedding the playground up the top of the main page and describing Lexical with a different term.
Totally agree. I assumed I was seeing an example of the editor!
My mistake... I thought the code editor was implemented using Lexical.
The real demo is here: https://lexical-playground.vercel.app/
(Edit) I think you should put this demo on the front page and the code sample on some other page. I was expecting to see the demo on the home page.
The real demo is here: https://lexical-playground.vercel.app/
(Edit) I think you should put this demo on the front page and the code sample on some other page. I was expecting to see the demo on the home page.
Is this in production on Facebook? I have not had the greatest experiences with their rich text editor, from not being able to remove styling on subsequent lines, to getting a nice little note saying that you can't edit rich text posts on mobile. Hoping lexical brings some improvements here.
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.
Related:
Lexical is now open-source (web text-editor) - https://news.ycombinator.com/item?id=31017943 - April 2022 (13 comments)
Lexical is now open-source (web text-editor) - https://news.ycombinator.com/item?id=31017943 - April 2022 (13 comments)
From a company that intentionally broke text editing on mobile to force people to install the Messenger app, I wouldn't use it even if it was great.
That’ll show em!
> a company that intentionally broke text editing
Of course inclined to believe you, but do you have a source to back this up?
Of course inclined to believe you, but do you have a source to back this up?
https://github.com/facebook/draft-js/issues/1077
_Perhaps_ it wasn't intentional, but it started happening around the time FB started forcing people to use Messenger and now you can't even access messages via the mobile website so who knows.
I haven't used FB for several years now so I'm a bit out of touch.
_Perhaps_ it wasn't intentional, but it started happening around the time FB started forcing people to use Messenger and now you can't even access messages via the mobile website so who knows.
I haven't used FB for several years now so I'm a bit out of touch.
Perhaps not intentionally broken but I still have issues with double texting on the Messenger mac/web app.
iMessages also has this issues as well... Telegram, Discord, WeChat, MSN Messenger, etc. all seem to have figured out how to prevent double texts from occurring.
iMessages also has this issues as well... Telegram, Discord, WeChat, MSN Messenger, etc. all seem to have figured out how to prevent double texts from occurring.
Excuse my ignorance, but what is a "double text"?
Probably the same text being sent twice.
That makes no sense. These two things have nothing to do with one another.
Updated list of rich/html text editors: https://gist.github.com/manigandham/65543a0bc2bf7006a487
It crashed after I created a code block, converted it to a quote block, and the hit ctrl+z to undo (something about a history node not being found, I think. Sorry, should have saved the output).
Thanks for trying it out! Mind drafting a quick issue here so that we can have a look? https://github.com/facebook/lexical/issues
Sure, just submitted a new issue. Included in the issue, but I think there might be a more general problem with how block conversion is handled (at least for quote and code block types). On firefox at least, it's pretty easy to crash this by messing with block type dropdown.
Here I was ready to be crabby about yet another web based rich text editor, but after reading so many comments about how it’s not a good code editor—which it’s not, it’s not one at all atm—I’m kind of just crabby about the discussion being completely about something other than the topic. Y’all, I know it’s a thing in software to curmudgeon everything but can we at least curmudgeon the actual thing it actually is? Or maybe just suspend curmudgeon-ness and see if the thing is deserving of that in the first place?
The code examples seem to not be working for me on Firefox 100.0b5 (64-bit) on Windows. I only see black rectangles.
I understand the API will change, but will the JSON representation in such a way that it's not safe to use currently? I don't mind a bug here and there, but it would be quite serious not to be able to use old content with a new version of the editor.
This has exactly the same maddening maladaptations that forced me to switch browsers for a reasonably adequate Facebook "experience". JavaScript that breaks in older or less popular browsers is not something I think needs to be promulgated even outside Facebook.
Disappointing.
Disappointing.
This feels half baked and confusing.
More than half docs page are blank:
- https://lexical.dev/docs/concepts/commands
- https://lexical.dev/docs/getting-started/quick-start
- https://lexical.dev/docs/concepts/extending-nodes
- https://lexical.dev/docs/concepts/editor-state
- https://lexical.dev/docs/api/lexical
- https://lexical.dev/docs/api/lexical-selection
- https://lexical.dev/docs/api/lexical-text
- https://lexical.dev/docs/api/lexical-offset
> An extensible text editor library
> Lexical is an extensible JavaScript web text-editor framework
The terminology is also confusing. In some places its called a library. In other places it's called a framework. Then other commenters mentioned that the demo gives the impression that it is a full package editor, but is just pegging onto CodeMirror. That's clarified here?
> It doesn't directly concern itself with UI components
> core of Lexical is ... a DOM reconciler that takes a set of editor states, diffs the changes, and updates the DOM according to their state.
> Lexical is designed for everyone. It follows best practices established in WCAG
These are weird and conflated set of buzzwords. Why should something that isn't concerned with UI components be concerned with accessibility best practices?
I'm building my own text editor and I thought VSCode was impressive enough. See this well written article about their text buffer reimplementation: https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r.... Then I realized Ace.js has some even crazy magic implementation that can handle millions of LoC files without lag. Can Lexical handle 100k+ LoC? Normally I'd benchmark myself, but in this case I don't see other compelling reasons too. The author mentioned the 22kB bundle size is less than Draft.js by Facebook, but Slate.js is 10kB and much more mature.
Some features that could make Lexical have "powerful features" as claimed: UNDO/REDO manager (without storing the entire state on the stack, which is just not scalable on memory), possibly implementing the Command pattern, then make easy consumption of collaborative editing such as with Operational Transform.
More than half docs page are blank:
- https://lexical.dev/docs/concepts/commands
- https://lexical.dev/docs/getting-started/quick-start
- https://lexical.dev/docs/concepts/extending-nodes
- https://lexical.dev/docs/concepts/editor-state
- https://lexical.dev/docs/api/lexical
- https://lexical.dev/docs/api/lexical-selection
- https://lexical.dev/docs/api/lexical-text
- https://lexical.dev/docs/api/lexical-offset
> An extensible text editor library
> Lexical is an extensible JavaScript web text-editor framework
The terminology is also confusing. In some places its called a library. In other places it's called a framework. Then other commenters mentioned that the demo gives the impression that it is a full package editor, but is just pegging onto CodeMirror. That's clarified here?
> It doesn't directly concern itself with UI components
> core of Lexical is ... a DOM reconciler that takes a set of editor states, diffs the changes, and updates the DOM according to their state.
> Lexical is designed for everyone. It follows best practices established in WCAG
These are weird and conflated set of buzzwords. Why should something that isn't concerned with UI components be concerned with accessibility best practices?
I'm building my own text editor and I thought VSCode was impressive enough. See this well written article about their text buffer reimplementation: https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r.... Then I realized Ace.js has some even crazy magic implementation that can handle millions of LoC files without lag. Can Lexical handle 100k+ LoC? Normally I'd benchmark myself, but in this case I don't see other compelling reasons too. The author mentioned the 22kB bundle size is less than Draft.js by Facebook, but Slate.js is 10kB and much more mature.
Some features that could make Lexical have "powerful features" as claimed: UNDO/REDO manager (without storing the entire state on the stack, which is just not scalable on memory), possibly implementing the Command pattern, then make easy consumption of collaborative editing such as with Operational Transform.
Always trips me out how even though a HN users know about software, they judge releases as though they are not software and that they are moment in time and wont get any better.
I'm all for criticism. It is great for everyone, but a library gets open sourced and you're complaining about empty docs? Seriously? Just hold off until it's more mature or open up a PR to add some stuff to the docs.
I'm all for criticism. It is great for everyone, but a library gets open sourced and you're complaining about empty docs? Seriously? Just hold off until it's more mature or open up a PR to add some stuff to the docs.
> and you're complaining about empty docs?
Then don't link to it if it's broken. You're wasting people's time.
> Just hold off until it's more mature
Sure, but indicate that it's an alpha product for public consumption instead of suggesting that it's ready for production use by other teams, just because Facebook uses it internally. You're wasting people's time.
> but a library gets open sourced and you're complaining about empty docs?
Should we not criticize the NPM ecosystem for half implementations that gets abandoned? It seems the team working on Lexical is derivative of Draft.js, which was open sourced by Facebook, and then abandoned. They don't even have the decency to label it is such. In a way, this seems to be a core re-write as Draft.js faced limits with ImmutableJS. Here, they are still leaning into functional programming concepts which may be an expensive abstraction that they will have to do another core re-write / abandon in the future. Seems like the marketing of these projects are for career self-serving purposes. Again, wasting people's time.
Then don't link to it if it's broken. You're wasting people's time.
> Just hold off until it's more mature
Sure, but indicate that it's an alpha product for public consumption instead of suggesting that it's ready for production use by other teams, just because Facebook uses it internally. You're wasting people's time.
> but a library gets open sourced and you're complaining about empty docs?
Should we not criticize the NPM ecosystem for half implementations that gets abandoned? It seems the team working on Lexical is derivative of Draft.js, which was open sourced by Facebook, and then abandoned. They don't even have the decency to label it is such. In a way, this seems to be a core re-write as Draft.js faced limits with ImmutableJS. Here, they are still leaning into functional programming concepts which may be an expensive abstraction that they will have to do another core re-write / abandon in the future. Seems like the marketing of these projects are for career self-serving purposes. Again, wasting people's time.
>Sure, but indicate that it's an alpha product
Do you mean something like the banner on the README?
https://github.com/facebook/lexical
>They don't even have the decency to label it is such
Do you mean something like the big banner on the README?
https://github.com/facebook/draft-js
Do you mean something like the banner on the README?
https://github.com/facebook/lexical
>They don't even have the decency to label it is such
Do you mean something like the big banner on the README?
https://github.com/facebook/draft-js
> Note: Lexical is currently in early development and APIs and packages are likely to change quite often
Why not mention it in the landing page or docs then?
From my understanding, Facebook lawyers require you peg such commentary in Github packages that are published. Google does this too but Google's definition of "early development" is usually closer to Beta, and their Beta is effectively GA.
Draft.js website doesn't give the impression that it's abandoned. True, people should inspect the source code of projects they consume, but many don't.
Why not mention it in the landing page or docs then?
From my understanding, Facebook lawyers require you peg such commentary in Github packages that are published. Google does this too but Google's definition of "early development" is usually closer to Beta, and their Beta is effectively GA.
Draft.js website doesn't give the impression that it's abandoned. True, people should inspect the source code of projects they consume, but many don't.
The criticism to me reads more like "do not reinvent the wheel" type of criticism, which sometimes we need more of.
> I'm building my own text editor and I thought VSCode was impressive enough. See this well written article about their text buffer reimplementation: https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r.... Then I realized Ace.js has some even crazy magic implementation that can handle millions of LoC files without lag. Can Lexical handle 100k+ LoC?
Also, to clear up any confusion, Lexical isn't a code editor - it could be used to build one, for sure, but some sort of virtualization would probably be required in order to support millions of lines of code.
Also, to clear up any confusion, Lexical isn't a code editor - it could be used to build one, for sure, but some sort of virtualization would probably be required in order to support millions of lines of code.
> but some sort of virtualization would probably be required in order to support millions of lines of code.
From my understanding, Lexical is a layer for the text document model and a pattern for transforming that text model. Updates to the model is where bottleneck comes about at VSCode / Ace scale.
From my understanding, Lexical is a layer for the text document model and a pattern for transforming that text model. Updates to the model is where bottleneck comes about at VSCode / Ace scale.
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.
Thank for the feedback - we're definitely still working on the docs.
> These are weird and conflated set of buzzwords. Why should something that isn't concerned with UI components be concerned with accessibility best practices?
Are they? Support for speech-to-text technologies and IME/composition input, for example, are independent of UI components.
> but Slate.js is 10kB and much more mature.
Is it?
https://bundlephobia.com/package/[email protected]
> These are weird and conflated set of buzzwords. Why should something that isn't concerned with UI components be concerned with accessibility best practices?
Are they? Support for speech-to-text technologies and IME/composition input, for example, are independent of UI components.
> but Slate.js is 10kB and much more mature.
Is it?
https://bundlephobia.com/package/[email protected]
> Support for speech-to-text technologies
So Lexical doesn't care about how the DOM is rendered? Or is speech-to-text derived independent of the DOM?
> but Slate.js is 10kB and much more mature.
The maturity bit, yes.
For the bundle size, Slate.js is still better. It's the same bundle size for something that's batteries included.
So Lexical doesn't care about how the DOM is rendered? Or is speech-to-text derived independent of the DOM?
> but Slate.js is 10kB and much more mature.
The maturity bit, yes.
For the bundle size, Slate.js is still better. It's the same bundle size for something that's batteries included.
> So Lexical doesn't care about how the DOM is rendered? Or is speech-to-text derived independent of the DOM?
I do now see your general point about the conflation there - the reality is Lexical also provides separate packages that implement a lot of common rich-text functionality. Within these, we do try to adhere to accessibility best practices. At the same time, the core library's accessibility claims are more based on support for various input methods, which I don't see as necessarily directly related to "UI components".
> For the bundle size, Slate.js is still better. It's the same bundle size for something that's batteries included.
Maturity is mostly a matter of time. I'm not sure what you mean by "batteries included"? AFAICT you need to install plugins on top of the core library with Slate to get a working text editor.
I do now see your general point about the conflation there - the reality is Lexical also provides separate packages that implement a lot of common rich-text functionality. Within these, we do try to adhere to accessibility best practices. At the same time, the core library's accessibility claims are more based on support for various input methods, which I don't see as necessarily directly related to "UI components".
> For the bundle size, Slate.js is still better. It's the same bundle size for something that's batteries included.
Maturity is mostly a matter of time. I'm not sure what you mean by "batteries included"? AFAICT you need to install plugins on top of the core library with Slate to get a working text editor.
How does this fit in with Draft.js? Is it a successor? Seems like it has to connect in some way...
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.
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.
> typing performance in our testing is around 30-70% faster compared to Draft.
At how many "Lines of Code" ? I am skeptical that scaling characteristics from 10k to 100k to 1 million is linear, so I'm curious what 30-70% actually means.
For example, VSCode tried a new text buffer and benchmarked at different source text sizes. There is a critical point where their PieceTree implementation scales , whereas the line-based text buffer approach does not scale.
At how many "Lines of Code" ? I am skeptical that scaling characteristics from 10k to 100k to 1 million is linear, so I'm curious what 30-70% actually means.
For example, VSCode tried a new text buffer and benchmarked at different source text sizes. There is a critical point where their PieceTree implementation scales , whereas the line-based text buffer approach does not scale.
Mostly referring to high-traffic surfaces here, like Facebook Feed or Messenger. The % varies depending on the environment and the previous Draft.js implementation (and their plugins) but overall it's been very positive, especially with low-end devices that went way over 16ms response time per keypress.
This is my point. Facebook surfaces include stuff like editing a post, sending a message. All of these have relatively small character limits versus a text editor that handles millions of lines with tens of millions of characters.
In the case of text editors, 1 object node per line implementations work fine for small files. They'll even edge out the overhead of more esoteric implementations requiring trees. Lookups are O(1) versus O(log n) in the depth of trees, but insertions get slow as you have to shift all the array elements. Again for few number of lines, that's fine. For small data ( tens of thousands of characters), even a giant string will do fine and within tens of milliseconds, too.
Facebook Blog / Article posts may get relatively long, but still not in the Megabytes ( metadata, not images ).
My point of contention is the claim and marketing that the library is suitable as a high performance text editor implementation. Depends on what the constraints and use case is. For Facebook posts and small editor widgets, I'll believe that. There is a hint that it can serve as the foundation for an IDE, but likely only a small snippet editor or a toy IDE implementation. The devil is in the details for a "serious" IDE / text editor like VSCode / Ace. It's an apple to bananas performance claim.
> low-end devices that went way over 16ms response time per keypress
Shaving milliseconds of keypresses for users on low end devices is msotly a Facebook and FANG concern. This performance concern is invisible and not important for someone looking to build an IDE where the users are accessing from a powerful device. For people editing huge files, the bottleneck are caused by data structures choices which I don't think will be mitigated by having a high level and convenient programming paradigm in the case of Lexical.
In the case of text editors, 1 object node per line implementations work fine for small files. They'll even edge out the overhead of more esoteric implementations requiring trees. Lookups are O(1) versus O(log n) in the depth of trees, but insertions get slow as you have to shift all the array elements. Again for few number of lines, that's fine. For small data ( tens of thousands of characters), even a giant string will do fine and within tens of milliseconds, too.
Facebook Blog / Article posts may get relatively long, but still not in the Megabytes ( metadata, not images ).
My point of contention is the claim and marketing that the library is suitable as a high performance text editor implementation. Depends on what the constraints and use case is. For Facebook posts and small editor widgets, I'll believe that. There is a hint that it can serve as the foundation for an IDE, but likely only a small snippet editor or a toy IDE implementation. The devil is in the details for a "serious" IDE / text editor like VSCode / Ace. It's an apple to bananas performance claim.
> low-end devices that went way over 16ms response time per keypress
Shaving milliseconds of keypresses for users on low end devices is msotly a Facebook and FANG concern. This performance concern is invisible and not important for someone looking to build an IDE where the users are accessing from a powerful device. For people editing huge files, the bottleneck are caused by data structures choices which I don't think will be mitigated by having a high level and convenient programming paradigm in the case of Lexical.
[deleted]
What's a high traffic surface? Isn't this rendering on the client anyway? What's high traffic?
I think it would be helpful to explicitly say that draft.js is deprecated here [1]. I was recently caught out by this, and started using draft.js without realising it’s been abandoned.
1. https://draftjs.org/
1. https://draftjs.org/
FWIW, we updated the README to reflect the status of DraftJS today.
https://github.com/facebook/draft-js
Point taken about updating the site, though.
https://github.com/facebook/draft-js
Point taken about updating the site, though.
Great news to hear Lexical replacing Draft. Also great that you're handling `beforeinput` (like Slate).
I work on a text expander browser extension and supporting Draft is a pain[1].
Are there any plans to make inserting text from the "outside" easier on Lexical? Maybe exposing the Lexical instance on the dom node (like CKEditor does)? Right now we're using `execCommand` to support Lexical.
[1] https://github.com/Briskine/briskine/blob/master/src/content...
Are there any plans to make inserting text from the "outside" easier on Lexical? Maybe exposing the Lexical instance on the dom node (like CKEditor does)? Right now we're using `execCommand` to support Lexical.
[1] https://github.com/Briskine/briskine/blob/master/src/content...
How hard it’ll be to build a notion like UX using lexical ? Have been using editorjs for same
I'd like to hear anyone else's experience of building a Notion like editor (or any other block based/full page editor)
Something guides never cover and I am stuck on is how to let users drop "widgets" into these RTEs. Think photos and galleries, where what is displayed in the editor is not what is present in the output (the real output could be 1+ React tags with attributes set) ; tables where the edit view is a spreadsheet & so on.
When I try to build these I get stuck between the representation in the RTE, the final output, and the "edit mode" in the RTE which may be in its own window.
Something guides never cover and I am stuck on is how to let users drop "widgets" into these RTEs. Think photos and galleries, where what is displayed in the editor is not what is present in the output (the real output could be 1+ React tags with attributes set) ; tables where the edit view is a spreadsheet & so on.
When I try to build these I get stuck between the representation in the RTE, the final output, and the "edit mode" in the RTE which may be in its own window.
[deleted]
Running your own editor with built-in plugins does not take more than a few lines of code - see the playground code https://github.com/facebook/lexical/blob/main/packages/lexic...
We already provide most common plugins out of the box (inc. lists and tables) but if you're planning to build a feature rich interface with many custom plugins it may take somewhat longer.
We already provide most common plugins out of the box (inc. lists and tables) but if you're planning to build a feature rich interface with many custom plugins it may take somewhat longer.
Is this meant to be a good drop-in rich-text/WYSIWYG editor?
What is the format that it creates that you could then persist in a database? Does it just save its state in HTML or some JSON format or what?
What is the format that it creates that you could then persist in a database? Does it just save its state in HTML or some JSON format or what?
The core Lexical library is really a framework for building such editors. However, we also provide many common rich-text features out-of-the-box via separate packages, such as @lexical/rich-text. We also expose bindings for React (and hope to have them for other frameworks soon). Check out the lexical-playground package on GitHub for an example of how you can create a rich-text editor by adding plugins to the LexicalComposer component in @lexical/react.
And how is the data saved on the BE? is it the case we can save it as JSON or HTML?
Let's say I'm building a stack overflow style editor (you type markdown and it gets rendered in a preview tab) -- would there be any reason to use lexical?
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.
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.
When you say inline markdown shortcut, is an example of that pressing Ctrl-B on some highlighted text in order to surround it with asterisks?
And is the idea of mentions that we can use Lexical to provide nice things like pop-up auto-complete of a username / automatically transform the username into a link inside of the input text?
And is the idea of mentions that we can use Lexical to provide nice things like pop-up auto-complete of a username / automatically transform the username into a link inside of the input text?
Another follow-up question: Do you think Lexical would be a good fit for a "live preview" type editor?
Live preview = the editor is WYSIWYG but the storage format is Markdow
Example: https://help.obsidian.md/Live+preview+update
Live preview = the editor is WYSIWYG but the storage format is Markdow
Example: https://help.obsidian.md/Live+preview+update
[deleted]
Got to work briefly on this project and really excited to see it reach the public! Congrats to trueadm and the whole team on this.
Why did Facebook need to build a text editor? Is this used somewhere in their products?
It's used on Facebook, Messenger, Workplace, Instagram and soon will be rolled out for WhatsApp web.
[deleted]
[deleted]
Do you have any support for collaborative editing such as with Yjs or Automerge?
Yep, we have full support with Yjs. https://github.com/facebook/lexical/tree/main/packages/lexic...
Very exciting! Great to see support for yjs. Does fb use yjs internally? Would love to learn more about this!
How does this compare to others like Monaco, Ace, etc?
Despite the name (and the misleading-at-first-glance "demo" on the home page), Lexical appears to be a rich text editor like Quill or ProseMirror, not a code editor.
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.
How does Lexical compare to Slate.js?
Where might I find docs on the output document persisted to the db? Also, reading back this data back into the editor.
No docs yet - but this code pointer for physical files (plugin) may help https://github.com/facebook/lexical/blob/main/packages/lexic...
Really great work! Especially the time travel functionality feels very innovative. Thank you for it.
Cool but I’ve found two bugs in the first few seconds of using it. Not ready for production IMO.
It would be awesome if you'd be willing to report them on GitHub :)
https://github.com/facebook/lexical/issues/new?assignees=&la...
https://github.com/facebook/lexical/issues/new?assignees=&la...
[deleted]
It's worth mentioning that it seems like you need to use react with this.
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.
The reason we have React bindings from the start, is because we needed these internally at Meta.
GP may be responding to the fact that the vanilla quick start page is empty while the react one is not
https://lexical.dev/docs/getting-started/quick-start
https://lexical.dev/docs/getting-started/quick-start
Yeah, we're still working on our docs. Watch this space! :)
It would seem the very first thing you would do is provide an example for vanilla JS so that everyone could get started. It is impossible to use this at all for the large proportion of the world that isn't using React as we can't even see a single example.
If it's so complicated to use that it takes more than a minute of vanilla JS coding to initialize it, then I don't think I'm interested, thanks all the same.
If it's so complicated to use that it takes more than a minute of vanilla JS coding to initialize it, then I don't think I'm interested, thanks all the same.
They use it internally, why would they rebuild it in vanilla before they released it? Sounds like they are working on it even though it's of no use to them.
yeah - I didn't see any examples on how to use this without react.
Any particular reason Meta decided to implement it's own editor library instead of building on top of ProseMirror?
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.
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.
Great job Dominic and team! :)
Really neat that it has no dependencies and works with anything.
Really neat that it has no dependencies and works with anything.
How does it compare with DraftJS?
I've responded to the same question https://news.ycombinator.com/item?id=31022152. :)
Wish this had LaTex support
So when do we get fbide?
You mean metaide
Yes I did.
> Copyright © 2022 Meta Platforms, Inc. Built with Docusaurus.
I think the title also meant meta
> Copyright © 2022 Meta Platforms, Inc. Built with Docusaurus.
I think the title also meant meta
Does it work on Android?
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.
One quirk for you: using my samsung keyboard with swipe typing, spaces aren't added between words. Not sure at all what causes it. The only other place I have seen this happen is url input in the browser (which I believe is intentional).
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. :)
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. :)
Added an issue here: https://github.com/facebook/lexical/issues/1699
And, as a side note, great work on this project. I had previously built a wysiwyg system from Slate and a custom plugin system; Lexical seems like a solid progression and has some interesting ideas like using React components the way it does to facilitate editor plugins. May have to try creating a Preact wrapper so I can use it in my projects.
And, as a side note, great work on this project. I had previously built a wysiwyg system from Slate and a custom plugin system; Lexical seems like a solid progression and has some interesting ideas like using React components the way it does to facilitate editor plugins. May have to try creating a Preact wrapper so I can use it in my projects.
What's your approach to Android support? Are you relying on mutation events, `beforeinput`, something else?
I built a really solid android adapter (after spilling gallons of tears) for our Draft.JS fork, and might have a few tips if it's helpful.
I built a really solid android adapter (after spilling gallons of tears) for our Draft.JS fork, and might have a few tips if it's helpful.
We listen to a few typing related events and do some computation from here: keydown, input, beforeinput. Android, contrary to any other device, mostly relies on composition so Lexical makes sure to handle and flush these events accordingly.
If you're curious, this is where it all starts - https://github.com/facebook/lexical/blob/main/packages/lexic...
If you're curious, this is where it all starts - https://github.com/facebook/lexical/blob/main/packages/lexic...
Is this the text editor used in products like Facebook (Blue), Messenger and Instagram? Because if it is it's buggy and terrible but thanks anyway I guess.
> Lexical is comprised of editor instances that each attach to a single content editable element.
Now if I only knew what was meant by attach, content editable, and element. Then I suspect I don't know what is meant even by comprised or editor.
To me: A bit is a 0 or a 1. A byte is 8 bits in a sequence where by sequence we mean the order of the bits matters. Or in terms of pure math, a byte is not a set but is an 8-tuple.
A file is a sequence of bytes in a file system on a computer. A leading example of such a file system is Microsoft's NTFS -- New Technology File System.
Each byte can be regarded as a character in the Roman alphabet plus the digits 0-9, some punctuation symbols, and a little more, all as in the common, old definition called ASCII (American Standard Code for Information Interchange).
An editor is a computer program that reads a file, displays the bytes as in the ASCII definition, permits a user of the program to modify the bytes and then writes the sequence of bytes to a file again on the file system.
Uh, what is WCAG?
In what sense "minimal"?
For "rich-text features and markdown", by rich-text is meant Unicode, some technique in Microsoft's program Word, D. Knuth's word processing program TeX? For "markdown", I looked that up at Google and found
"Markdown is a text-to-HTML conversion tool for web writers."
So, in particular Markdown is a computer program. Okay.
Again, from Google, apparently React is a JavaScript library for building user interfaces.
I've been a heavy user of text editors for years. The editor Kedit is my most important tool. Macros? Sure, I've written about 300 of them.
Text? I've got good experience with Knuth's TeX: Wrote about 50 macros for TeX and have published applied math I wrote with TeX.
Uh, for a new Web site, I have written code, 100,000 lines of text in Microsoft's Visual Basic .NET using ASP.NET and ADO.NET and some for their "platform invoke". The 100,000 lines of code runs, apparently as intended. To type in the code, I just used Kedit -- worked great.
But I did nothing with React or JavaScript.
After reading the OP and more, I still have no idea what Lexical is, what it is for, what it can do as an editor, why anyone would use it, etc.
I write this post because in my work far and away the biggest obstacle is getting meaningful information from the available documentation. E.g., I spent all of yesterday on the question, what is a video adapter card? Such cards go for $15, $65, or $500, but what the cards are and the differences are not made at all clear. Before that, I wasted several days working with Microsoft's programs COMP and FC, intended to compare files. I gave up and wrote my own program to compare files. Before that I wasted 1+ weeks mud wrestling trying to get an HP laptop and Windows 10 to write some DVDs -- after wasting several supplies of DVDs, DVD-R, DVD+R, DVD+RW, I concluded that somehow HP or Microsoft just doesn't want people writing DVDs -- millions of bytes of documentation and several YouTube videos didn't contradict that conclusion.
Another problem, Microsoft's Outlook 2003, that I used successfully for years, now won't read my email from my ISP (Internet Service Provider). I wrestled with that problem for some days and finally decided to use Thunderbird. Reading email should not be difficult -- for some years I used my own email software I'd written just with the scripting language Rexx and its way to use TCP/IP.
I mention these problems because they are, in the world of computing, simple, trivial, old, etc., should be taken for granted but all of them remain.
The real, original, core creative work, with some pure and applied math, for my Web site has been fast, fun, and easy, but the real problem that has nearly ruined my effort is bad documentation of the tools I must use.
Now along comes Lexical where I can get no idea at all what the heck they are talking about -- to me that is an example of a big problem in computing.
Now if I only knew what was meant by attach, content editable, and element. Then I suspect I don't know what is meant even by comprised or editor.
To me: A bit is a 0 or a 1. A byte is 8 bits in a sequence where by sequence we mean the order of the bits matters. Or in terms of pure math, a byte is not a set but is an 8-tuple.
A file is a sequence of bytes in a file system on a computer. A leading example of such a file system is Microsoft's NTFS -- New Technology File System.
Each byte can be regarded as a character in the Roman alphabet plus the digits 0-9, some punctuation symbols, and a little more, all as in the common, old definition called ASCII (American Standard Code for Information Interchange).
An editor is a computer program that reads a file, displays the bytes as in the ASCII definition, permits a user of the program to modify the bytes and then writes the sequence of bytes to a file again on the file system.
Uh, what is WCAG?
In what sense "minimal"?
For "rich-text features and markdown", by rich-text is meant Unicode, some technique in Microsoft's program Word, D. Knuth's word processing program TeX? For "markdown", I looked that up at Google and found
"Markdown is a text-to-HTML conversion tool for web writers."
So, in particular Markdown is a computer program. Okay.
Again, from Google, apparently React is a JavaScript library for building user interfaces.
I've been a heavy user of text editors for years. The editor Kedit is my most important tool. Macros? Sure, I've written about 300 of them.
Text? I've got good experience with Knuth's TeX: Wrote about 50 macros for TeX and have published applied math I wrote with TeX.
Uh, for a new Web site, I have written code, 100,000 lines of text in Microsoft's Visual Basic .NET using ASP.NET and ADO.NET and some for their "platform invoke". The 100,000 lines of code runs, apparently as intended. To type in the code, I just used Kedit -- worked great.
But I did nothing with React or JavaScript.
After reading the OP and more, I still have no idea what Lexical is, what it is for, what it can do as an editor, why anyone would use it, etc.
I write this post because in my work far and away the biggest obstacle is getting meaningful information from the available documentation. E.g., I spent all of yesterday on the question, what is a video adapter card? Such cards go for $15, $65, or $500, but what the cards are and the differences are not made at all clear. Before that, I wasted several days working with Microsoft's programs COMP and FC, intended to compare files. I gave up and wrote my own program to compare files. Before that I wasted 1+ weeks mud wrestling trying to get an HP laptop and Windows 10 to write some DVDs -- after wasting several supplies of DVDs, DVD-R, DVD+R, DVD+RW, I concluded that somehow HP or Microsoft just doesn't want people writing DVDs -- millions of bytes of documentation and several YouTube videos didn't contradict that conclusion.
Another problem, Microsoft's Outlook 2003, that I used successfully for years, now won't read my email from my ISP (Internet Service Provider). I wrestled with that problem for some days and finally decided to use Thunderbird. Reading email should not be difficult -- for some years I used my own email software I'd written just with the scripting language Rexx and its way to use TCP/IP.
I mention these problems because they are, in the world of computing, simple, trivial, old, etc., should be taken for granted but all of them remain.
The real, original, core creative work, with some pure and applied math, for my Web site has been fast, fun, and easy, but the real problem that has nearly ruined my effort is bad documentation of the tools I must use.
Now along comes Lexical where I can get no idea at all what the heck they are talking about -- to me that is an example of a big problem in computing.
I think the answer to your woes is to accept that the computing domain (while labelled by a single word "computing"), in reality is so vast that no one can expect to be a master of it all. Most of us are content to carve out our own little niche; I for one have no idea what a video adapter card is, nor how Tex works, but I have good grasp of what a content editable element is, and so on.
The computing domain is perhaps peculiar compared to other domains too, in that there is no "basic concepts" that one needs to master to understand everything else (like mathematics for example). One can live a good life as a web developer without knowing the innards of a database, and vice versa. It is not a big problem in computing, it's just the nature of the field.
The computing domain is perhaps peculiar compared to other domains too, in that there is no "basic concepts" that one needs to master to understand everything else (like mathematics for example). One can live a good life as a web developer without knowing the innards of a database, and vice versa. It is not a big problem in computing, it's just the nature of the field.
My view is that the bottleneck is documentation or technical writing. As far as I can tell, so far nearly all of practical computing is conceptually easy. Digging into the work on the question of P versus NP does get tricky quickly, but so far that question is not very practical, e.g., with the question and the work so far, in practice can't do much with them.
For progress on documentation, as I hinted in my post, a first step is to define terms and acronyms. A second step for a term, concept, feature, etc. is some examples.
With reasonably good technical writing, I understand quickly.
E.g., for M.2, nothing I found from Google, Bing, Amazon, Western Digital, etc. made much sense. Then I downloaded from Asus a PDF of the basic technical information on a current, high end Asus motherboard and just looked at the board "layout" -- there it was easy to see what M.2 was all about, and the information was darned explicit, sockets on a motherboard, and highly credible, an actual Asus product.
To me, in short, for the computer industry and the rest of the economy depending on it, the issue is technical writing and, there, defining and explaining terms.
E.g., React. Okay, I gave the one line Google description. React has to do with writing JavaScript code. Okay. Even though I wrote the software for a Web site, I never wrote any JavaScript at all. Microsoft's ASP.NET wrote a little for me, but for how my site's Web pages work that JavaScript seems optional. So, first cut, for now, I can f'get about React and tools for working with JavaScript. In particular, if Lexical is mostly about working with JavaScript, then, again, first cut, for now I can f'get about Lexical -- but on this point I wanted to be sure, and so far I'm not.
For progress on documentation, as I hinted in my post, a first step is to define terms and acronyms. A second step for a term, concept, feature, etc. is some examples.
With reasonably good technical writing, I understand quickly.
E.g., for M.2, nothing I found from Google, Bing, Amazon, Western Digital, etc. made much sense. Then I downloaded from Asus a PDF of the basic technical information on a current, high end Asus motherboard and just looked at the board "layout" -- there it was easy to see what M.2 was all about, and the information was darned explicit, sockets on a motherboard, and highly credible, an actual Asus product.
To me, in short, for the computer industry and the rest of the economy depending on it, the issue is technical writing and, there, defining and explaining terms.
E.g., React. Okay, I gave the one line Google description. React has to do with writing JavaScript code. Okay. Even though I wrote the software for a Web site, I never wrote any JavaScript at all. Microsoft's ASP.NET wrote a little for me, but for how my site's Web pages work that JavaScript seems optional. So, first cut, for now, I can f'get about React and tools for working with JavaScript. In particular, if Lexical is mostly about working with JavaScript, then, again, first cut, for now I can f'get about Lexical -- but on this point I wanted to be sure, and so far I'm not.
I'm sure good documentation, i.e. one that starts at a basic level assuming almost no prior knowledge and then gradually building on that, would lower the barrier of entry for many autodidacts. Maybe that will be the norm one day. But until then, we all find ourselves in the position where we need to quickly scan a text in order to assess if the level expertise required to understand it is within our potential grasp or not. Especially the texts that are posted here. Sometimes one might go down a rabbit-hole, google all the terms and see if it fits in with one's already acquired body of knowledge in an adjacent field, and sometimes one might find that one's knowledge actually has expanded.
Admittedly, that is the good feeling of having learnt something new. But sometimes it's just too many new terms and concepts to learn. I don't fret about it, one can't know everything. If one tries I suspect it would be a shallow understanding - except for the odd genius maybe. But I doubt it, even then.
That said, you can't go wrong with learning Javascript (Typescript) these days. It's really not hard once you've got a grasp of the basics and there is all kinds of documentation that guides even the complete novice. Writing a web-site without JavaScript at all is commendable (especially here on HN), but it doesn't hurt to know how it works.
Admittedly, that is the good feeling of having learnt something new. But sometimes it's just too many new terms and concepts to learn. I don't fret about it, one can't know everything. If one tries I suspect it would be a shallow understanding - except for the odd genius maybe. But I doubt it, even then.
That said, you can't go wrong with learning Javascript (Typescript) these days. It's really not hard once you've got a grasp of the basics and there is all kinds of documentation that guides even the complete novice. Writing a web-site without JavaScript at all is commendable (especially here on HN), but it doesn't hurt to know how it works.
Yup.
1. Marijn has built an awesome open source richtext library (https://prosemirror.net/) which has a huge plugin ecosystem and bindings with a bunch of front-end frameworks (including React). Is there any specific motivation behind building one from scratch?
2. How is this different from Facebook's own DraftJS lib?
3. What's the story of realtime collaboration support with OT/CRDT? Prosemirror had this in mind when designing its state model and delta model, so it comes with out of the box support for realtime collaborations. Can we expect the same with Lexical?
4. What's the cross platform strategy for Lexical? If I store the editor's state as JSON on the server, how will I render it on devices and native desktop apps?
We've built our own library on top of Prosemirror to power the comments and feedback sections of Zoho Writer - https://writer.zoho.com
I'm always looking out for better approaches/alternatives in this space and I'm curious how different Lexical is. Thanks!