[alephnan]

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.

[motoxpro]

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.

[alephnan]

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

[acywatson]

>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

[alephnan]

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

[zelphirkalt]

The criticism to me reads more like "do not reinvent the wheel" type of criticism, which sometimes we need more of.

[acywatson]

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

[alephnan]

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

[trueadm]

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.

[acywatson]

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/slate@0.77.0

[alephnan]

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

[acywatson]

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

[alephnan]

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

[trueadm]

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