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

51–60 of 141 posts

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

#51

Post by alephnan »

acywatson wrote: post #48
alephnan wrote: post #42

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://lexi…

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://bundleph…

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

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

#52

Post by alephnan »

acywatson wrote: post #50
alephnan wrote: post #42

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://lexi…

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

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

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

#53

Post by acywatson »

alephnan wrote: post #51
acywatson wrote: post #48

Earlier quoted context omitted.

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://bundleph…

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

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.

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

#54

Post by kingcharles »

trueadm wrote: post #13
distrill wrote: post #10

Earlier quoted context omitted.

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

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.

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

#55

Post by netghost »

trueadm wrote: post #34
hiimshort wrote: post #33

Earlier quoted context omitted.

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

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.

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

#56

Post by alephnan »

acywatson wrote: post #53
alephnan wrote: post #51

Earlier quoted context omitted.

> 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? 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 base…

> I'm not sure what you mean by "batteries included"?

A rendering layer. With Lexical, you'd have to add in the React layer, which wasn't already included in the bundle size comparison.

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

#58

Post by nojs »

trueadm wrote: post #14
johnny35 wrote: post #12

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

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/

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

#59

Post by nojvek »

trueadm wrote: post #27
cetra3 wrote: post #26

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.

If I remember correctly you’re the Dominic who wrote inferno.js right?

Love how performance obsessed you are. Facebook is lucky to have you.

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

#60

Post by alephnan »

trueadm wrote: post #14
johnny35 wrote: post #12

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-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-based text buffer approach does not scale.

Post reply on HN