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.
Lastly, we found ProseMirror was too heavy in terms of bytes for very minimal almost plain-text interfaces where we only wanted mentions + hashtags + custom emojis. Lexical comes in at around 22kb min+gzip, so it works really well for us.
Admittedly, that is the good feeling of having learnt something new. But sometimes it's just too many new terms and concepts to learn. I don't fret about it, one can't know everything. If one tries I suspect it would be a shallow understanding - except for the odd genius maybe. But I doubt it, even then.
That said, you can't go wrong with learning Javascript (Typescript) these days. It's really not hard once you've got a grasp of the basics and there is all kinds of documentation that guides even the complete novice. Writing a web-site without JavaScript at all is commendable (especially here on HN), but it doesn't hurt to know how it works.
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.
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. :)
And, as a side note, great work on this project. I had previously built a wysiwyg system from Slate and a custom plugin system; Lexical seems like a solid progression and has some interesting ideas like using React components the way it does to facilitate editor plugins. May have to try creating a Preact wrapper so I can use it in my projects.
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.
If you're curious, this is where it all starts - https://github.com/facebook/lexical/blob/main/packages/lexic...
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.
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
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...
https://github.com/facebook/draft-js
Point taken about updating the site, though.
(2) I think something like "At the moment it's funded, but I can't legally bind my org to that commitment. And in general, as software comes-and-goes, it's future utility and support is always hard to pin-down".
I mention (1) because I think (2) can be inferred from the comment, and I think we have some responsibility as readers/listeners to do that; rather than expect all communication will be clear to us.
yeah lol, i think everyone in this thread had the same experience
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?
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.
Lexical also treat its own EditorState as the source of truth. We use DOM MutationObservers to ensure the DOM matches the EditorState at all times. We do allow external mutations from things like spellcheckers update Lexical – otherwise people wouldn't be able to use Grammarly and other tools with Lexical. However, that's really constrained so that they don't overreach.
Lexical also has the notion of double-buffering. When you update Lexical, or use a node transform, you're actually mutating the "work in progress" EditorState. Once Lexical feels that the EditorState is ready, it will commit it to the DOM, and that EditorState will become immutable and will reflect what you see on the page.
This could be a huge win for simple multi-platform rendering.
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.
A rendering layer. With Lexical, you'd have to add in the React layer, which wasn't already included in the bundle size comparison.
In the case of text editors, 1 object node per line implementations work fine for small files. They'll even edge out the overhead of more esoteric implementations requiring trees. Lookups are O(1) versus O(log n) in the depth of trees, but insertions get slow as you have to shift all the array elements. Again for few number of lines, that's fine. For small data ( tens of thousands of characters), even a giant string will do fine and within tens of milliseconds, too.
Facebook Blog / Article posts may get relatively long, but still not in the Megabytes ( metadata, not images ).
My point of contention is the claim and marketing that the library is suitable as a high performance text editor implementation. Depends on what the constraints and use case is. For Facebook posts and small editor widgets, I'll believe that. There is a hint that it can serve as the foundation for an IDE, but likely only a small snippet editor or a toy IDE implementation. The devil is in the details for a "serious" IDE / text editor like VSCode / Ace. It's an apple to bananas performance claim.
> low-end devices that went way over 16ms response time per keypress
Shaving milliseconds of keypresses for users on low end devices is msotly a Facebook and FANG concern. This performance concern is invisible and not important for someone looking to build an IDE where the users are accessing from a powerful device. For people editing huge files, the bottleneck are caused by data structures choices which I don't think will be mitigated by having a high level and convenient programming paradigm in the case of Lexical.
My best guess is to use a NodeJS/V8 instance on the server to somehow transform JSON to HTML using Lexical's serializer (if something like that exists). Even this is tricky because it might depend on browser DOM apis for the conversion.
A better solution would be support language specific bindings to get HTML from JSON with zero dependecies.
Any chance you thought along these lines?