We definitely have plans to improve Tables drastically over time, but I'm not sure when we'll get to those particular issues. If you care to make an Issue for this on GitHub, that would be much appreciated :)
You mean typing latency, right? The most important thing we do there is handling reconciliation ourselves rather than delegating to a framework (e.g., React). If you have full control over the reconciliation process, it's just a matter of continuous incremental optimization.
Sure - DraftJS, for instance, delegates DOM reconciliation to React. Lexical does not. The core library is framework-agnostic, with it's own diffing and reconciliation processes.
I work at Meta on the Lexical team - yes, Lexical supports markdown and rendering from markdown syntax. Lexical isn't a drop-in replacement for Draft, but we're migrating all of our surfaces internally and it isn't particularly difficult, especially if you aren't storing in the DraftJS-specific format. As for alternatives, you can also consider storing it as JSON, which Lexical supports.
> 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.
> 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.
> 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.
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.
> 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.
