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 story of realtime collaboration support with OT/CRDT? Prosemirror had this in mind when designing its state model and delta model, so it comes with out of the box support for realtime collaborations. Can we expect the same with Lexical?
4. What's the cross platform strategy for Lexical? If I store the editor's state as JSON on the server, how will I render it on devices and native desktop apps?
We've built our own library on top of Prosemirror to power the comments and feedback sections of Zoho Writer - https://writer.zoho.com
I'm always looking out for better approaches/alternatives in this space and I'm curious how different Lexical is. Thanks!
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-played without further ado also simplifies devX as collaboration can be added later when the application is mature without the need to rethink any of the plugins that were originally created for non-collab plain/rich text.
4. Lexical Web is just the first of many. We want to port the API and fundamentals to various others platforms, including iOS for which we are already performing the initial set of testing. Cross-platform means the API, including Node's will look alike and EditorState and node's properties will be compatible even if behind the scenes the reconciler is constrained by the toolkit available on each platform (and doesn't render or behave 100% like Web's).
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!
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 take you moved from the React team to this dedicated Lexical team?
What does this mean?
Competition is welcome, but the description sounds like this is more of a library than a finished product (which Monaco isn't), and if so, some examples showing how to take advantage of that would have been helpful.
Lexical definitely has the foundational requirements capable of building a CodeMirror or Monaco editor, but that wasn't our initial target with this library. That doesn't mean that we don't expect the community to push it that way in the future, we fully expect that. Let's see how things go, competition is healthy! :)
The real demo is here: https://lexical-playground.vercel.app/
(Edit) I think you should put this demo on the front page and the code sample on some other page. I was expecting to see the demo on the home page.
Lexical is now open-source (web text-editor) - https://news.ycombinator.com/item?id=31017943 - April 2022 (13 comments)
Of course inclined to believe you, but do you have a source to back this up?
_Perhaps_ it wasn't intentional, but it started happening around the time FB started forcing people to use Messenger and now you can't even access messages via the mobile website so who knows.
I haven't used FB for several years now so I'm a bit out of touch.
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.
Disappointing.
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.
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.
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.
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.
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.
> 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?
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.
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-support. Today, it's nowhere near as bad. We can leverage modern events and we can try and tackle things from a different point of view. One of the core things we've tried to do is make the developer experience and performance better. DraftJS pulled in a lot of JavaScript and much of it was hard to reason with because of the lack of types. ImmutableJS just didn't scale how we would have liked it to, and from our experience, developers didn't really like using it all that much. DraftJS also had a block based approach, which quickly fell apart when you wanted to do something more complex. Not to mention compatibility with React 18+ and the countless issues with having to depend on ReactDOM for rendering when fighting with browser extensions that want to take over control of the DOM from Draft.
With these things in mind, we looked at how we could keep the good ideas from Draft, Slate, ProseMirror and also invent some new ideas of our own. Lexical doesn't have any dependencies, so you can use it with Svelte or Solid (once their bindings have been created), or any other framework of your choice. Lexical also doesn't need ImmutableJS, which means the APIs are fully typed in Flow and TypeScript, reducing issues. Lexical is also around 22kb gzip+min, so it's far smaller than Draft. 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.
Are there any plans to make inserting text from the "outside" easier on Lexical? Maybe exposing the Lexical instance on the dom node (like CKEditor does)? Right now we're using `execCommand` to support Lexical.
[1] https://github.com/Briskine/briskine/blob/master/src/content...
Something guides never cover and I am stuck on is how to let users drop "widgets" into these RTEs. Think photos and galleries, where what is displayed in the editor is not what is present in the output (the real output could be 1+ React tags with attributes set) ; tables where the edit view is a spreadsheet & so on.
When I try to build these I get stuck between the representation in the RTE, the final output, and the "edit mode" in the RTE which may be in its own window.
We already provide most common plugins out of the box (inc. lists and tables) but if you're planning to build a feature rich interface with many custom plugins it may take somewhat longer.
What is the format that it creates that you could then persist in a database? Does it just save its state in HTML or some JSON format or what?
You could also roll with a `<textarea>` but that can be limiting if you want additional functionality further on down the line – such as mentions or inline markdown shortcuts.
And is the idea of mentions that we can use Lexical to provide nice things like pop-up auto-complete of a username / automatically transform the username into a link inside of the input text?
Live preview = the editor is WYSIWYG but the storage format is Markdow
https://github.com/facebook/lexical/issues/new?assignees=&la...
The reason we have React bindings from the start, is because we needed these internally at Meta.
Really neat that it has no dependencies and works with anything.
> Copyright © 2022 Meta Platforms, Inc. Built with Docusaurus.
I think the title also meant meta
Now if I only knew what was meant by attach, content editable, and element. Then I suspect I don't know what is meant even by comprised or editor.
To me: A bit is a 0 or a 1. A byte is 8 bits in a sequence where by sequence we mean the order of the bits matters. Or in terms of pure math, a byte is not a set but is an 8-tuple.
A file is a sequence of bytes in a file system on a computer. A leading example of such a file system is Microsoft's NTFS -- New Technology File System.
Each byte can be regarded as a character in the Roman alphabet plus the digits 0-9, some punctuation symbols, and a little more, all as in the common, old definition called ASCII (American Standard Code for Information Interchange).
An editor is a computer program that reads a file, displays the bytes as in the ASCII definition, permits a user of the program to modify the bytes and then writes the sequence of bytes to a file again on the file system.
Uh, what is WCAG?
In what sense "minimal"?
For "rich-text features and markdown", by rich-text is meant Unicode, some technique in Microsoft's program Word, D. Knuth's word processing program TeX? For "markdown", I looked that up at Google and found
"Markdown is a text-to-HTML conversion tool for web writers."
So, in particular Markdown is a computer program. Okay.
Again, from Google, apparently React is a JavaScript library for building user interfaces.
I've been a heavy user of text editors for years. The editor Kedit is my most important tool. Macros? Sure, I've written about 300 of them.
Text? I've got good experience with Knuth's TeX: Wrote about 50 macros for TeX and have published applied math I wrote with TeX.
Uh, for a new Web site, I have written code, 100,000 lines of text in Microsoft's Visual Basic .NET using ASP.NET and ADO.NET and some for their "platform invoke". The 100,000 lines of code runs, apparently as intended. To type in the code, I just used Kedit -- worked great.
But I did nothing with React or JavaScript.
After reading the OP and more, I still have no idea what Lexical is, what it is for, what it can do as an editor, why anyone would use it, etc.
I write this post because in my work far and away the biggest obstacle is getting meaningful information from the available documentation. E.g., I spent all of yesterday on the question, what is a video adapter card? Such cards go for $15, $65, or $500, but what the cards are and the differences are not made at all clear. Before that, I wasted several days working with Microsoft's programs COMP and FC, intended to compare files. I gave up and wrote my own program to compare files. Before that I wasted 1+ weeks mud wrestling trying to get an HP laptop and Windows 10 to write some DVDs -- after wasting several supplies of DVDs, DVD-R, DVD+R, DVD+RW, I concluded that somehow HP or Microsoft just doesn't want people writing DVDs -- millions of bytes of documentation and several YouTube videos didn't contradict that conclusion.
Another problem, Microsoft's Outlook 2003, that I used successfully for years, now won't read my email from my ISP (Internet Service Provider). I wrestled with that problem for some days and finally decided to use Thunderbird. Reading email should not be difficult -- for some years I used my own email software I'd written just with the scripting language Rexx and its way to use TCP/IP.
I mention these problems because they are, in the world of computing, simple, trivial, old, etc., should be taken for granted but all of them remain.
The real, original, core creative work, with some pure and applied math, for my Web site has been fast, fun, and easy, but the real problem that has nearly ruined my effort is bad documentation of the tools I must use.
Now along comes Lexical where I can get no idea at all what the heck they are talking about -- to me that is an example of a big problem in computing.
The computing domain is perhaps peculiar compared to other domains too, in that there is no "basic concepts" that one needs to master to understand everything else (like mathematics for example). One can live a good life as a web developer without knowing the innards of a database, and vice versa. It is not a big problem in computing, it's just the nature of the field.
For progress on documentation, as I hinted in my post, a first step is to define terms and acronyms. A second step for a term, concept, feature, etc. is some examples.
With reasonably good technical writing, I understand quickly.
E.g., for M.2, nothing I found from Google, Bing, Amazon, Western Digital, etc. made much sense. Then I downloaded from Asus a PDF of the basic technical information on a current, high end Asus motherboard and just looked at the board "layout" -- there it was easy to see what M.2 was all about, and the information was darned explicit, sockets on a motherboard, and highly credible, an actual Asus product.
To me, in short, for the computer industry and the rest of the economy depending on it, the issue is technical writing and, there, defining and explaining terms.
E.g., React. Okay, I gave the one line Google description. React has to do with writing JavaScript code. Okay. Even though I wrote the software for a Web site, I never wrote any JavaScript at all. Microsoft's ASP.NET wrote a little for me, but for how my site's Web pages work that JavaScript seems optional. So, first cut, for now, I can f'get about React and tools for working with JavaScript. In particular, if Lexical is mostly about working with JavaScript, then, again, first cut, for now I can f'get about Lexical -- but on this point I wanted to be sure, and so far I'm not.
