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