Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Facebook open sources Lexical, an extensible text editor library

lexical.dev

Post reply on HN
Print view View original

91–100 of 141 posts

Re: Facebook open sources Lexical, an extensible text editor library

#91

Post by zurfyx »

alephnan wrote: post #60
trueadm wrote: post #14

Earlier quoted context omitted.

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-suppo…

> 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-ba…

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.

Re: Facebook open sources Lexical, an extensible text editor library

#92

Post by robertlagrant »

trueadm wrote: post #28
andygcook wrote: post #23

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 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.

> I can't guarantee anything, no on can in software.

What does this mean?

Re: Facebook open sources Lexical, an extensible text editor library

#94

Post by asxd »

zurfyx wrote: post #88
asxd wrote: post #83

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.

Re: Facebook open sources Lexical, an extensible text editor library

#95

Post by stareatgoats »

graycat wrote: post #81
stareatgoats wrote: post #69

Earlier quoted context omitted.

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 perha…

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…

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.

Re: Facebook open sources Lexical, an extensible text editor library

#96

Post by thorncorona »

stareatgoats wrote: post #90
petepete wrote: post #75

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.

> a company that intentionally broke text editing Of course inclined to believe you, but do you have a source to back this up?

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.

Re: Facebook open sources Lexical, an extensible text editor library

#97

Post by alephnan »

zurfyx wrote: post #91
alephnan wrote: post #60

Earlier quoted context omitted.

> 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-ba…

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.

Re: Facebook open sources Lexical, an extensible text editor library

#99

Post by robertlagrant »

zurfyx wrote: post #91
alephnan wrote: post #60

Earlier quoted context omitted.

> 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-ba…

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.

What's a high traffic surface? Isn't this rendering on the client anyway? What's high traffic?

Re: Facebook open sources Lexical, an extensible text editor library

#100

Post by lewisjoe »

zurfyx wrote: post #68
lewisjoe wrote: post #47

Hi Dominic, thanks for open sourcing the library. I have quite a few questions though: 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 st…

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…

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!

Post reply on HN