Brian Lovin
/
Hacker News
Daily Digest email

Get the top HN stories in your inbox every day.

lewisjoe

Hi Dominic, thanks for open sourcing the library. I have quite a few questions though:

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!

zurfyx

For 1. 2. see @trueadm's answer here - https://news.ycombinator.com/item?id=31022152

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

lewisjoe

Thanks for the pointer. His comparison of Draft vs Lexical makes a lot of sense. I'm keener to understand the different between Prosemirror vs Lexical. He mentions that he pulled the best ideas from libs like Prosemirror.

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!

trueadm

I don't think ProseMirror has taken a bad approach. I think we've just taken a different approach when it comes to the design of things. In Lexical, you rarely concern yourself with the DOM – and typically you deal with Lexical's node API directly and that's really all you touch.

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.

zeroonetwothree

FB essentially stopped supporting DraftJS. I think they don't use it much internally anymore. This seems to be the replacement.

andygcook

One of the big frustrations with DraftJS is that Facebook moved on (which is understandable), but the core repo wasn’t given control to the community, so patches and updates couldn’t be pulled in. Obviously it’s open source and could be hard forked, but that’s not ideal.

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.

trueadm

I completely understand. I can't guarantee anything, no on can in software. However, we do have a dedicated full-time team working on Lexical. DraftJS never had that, it only had a few part-time maintainers at Facebook.

andygcook

Agreed there’s no guarantees in software, but that’s helpful context that there’s a dedicated team working on Lexical. Thanks for sharing and also for giving back to the software community by open sourcing the code. Editors are tough and every thoughtful approach like this that’s publicly available to use helps push them forward.

lhorie

Hey Dominic, good to see you :)

I take you moved from the React team to this dedicated Lexical team?

trueadm

Good to see you too! I moved from the React core team about 2 years ago, and since then, I was fortunate to be able to build a team around Lexical!

robertlagrant

> I can't guarantee anything, no on can in software.

What does this mean?

mjburgess

(1) People aren't often good at communicating their intent with language. It requires using public meanings (words) assembled in some order to reflect a private meaning which is non-linguistic.

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

petilon

The examples shown on the site are code editing. Which puts it in direct competition with the more established Monaco from Microsoft [1].

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.

[1] https://microsoft.github.io/monaco-editor/

trueadm

By the examples, do you mean the fact we are using Codesandbox embed to show code examples of the editor itself?

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! :)

mkl

Having the live editor examples on the home page be live examples of a different editor (of a different kind) is more than a little confusing. I understood Lexical to be a code editor until I came here and saw your comment. The main page even describes Lexical as a "text editor", a term used for plain text like code. I suggest embedding the playground up the top of the main page and describing Lexical with a different term.

astroalex

Totally agree. I assumed I was seeing an example of the editor!

petilon

My mistake... I thought the code editor was implemented using Lexical.

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.

distrill

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

yeah lol, i think everyone in this thread had the same experience

cetra3

Is this in production on Facebook? I have not had the greatest experiences with their rich text editor, from not being able to remove styling on subsequent lines, to getting a nice little note saying that you can't edit rich text posts on mobile. Hoping lexical brings some improvements here.

trueadm

It is in production at Facebook. We're slowly rolling out to more surfaces, replacing our existing DraftJS implementations as we go. We've noticed a big improvement internally from doing so, both in terms of less bugs but also performance and accessibility.

nojvek

If I remember correctly you’re the Dominic who wrote inferno.js right?

Love how performance obsessed you are. Facebook is lucky to have you.

trueadm

Yep, I’m the same person still :p

ryanar

Hey Adam, is Meta using / planning on using Lexical for React Native as well?

trueadm

Adam? You mean Dominic/trueadm? We have some ideas for supporting RN once we have iOS/Android versions of Lexical.

dang

Related:

Lexical is now open-source (web text-editor) - https://news.ycombinator.com/item?id=31017943 - April 2022 (13 comments)

bhl

Maybe worth merging threads since they're about the same event and that post has some comments by a maintainer.

SaulJLH

Yeah that was posted first but this one seems to have more comments now, please merge.

petepete

From a company that intentionally broke text editing on mobile to force people to install the Messenger app, I wouldn't use it even if it was great.

HL33tibCe7

That’ll show em!

stareatgoats

> a company that intentionally broke text editing

Of course inclined to believe you, but do you have a source to back this up?

petepete

https://github.com/facebook/draft-js/issues/1077

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

thorncorona

Perhaps not intentionally broken but I still have issues with double texting on the Messenger mac/web app.

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.

rmbyrro

Excuse my ignorance, but what is a "double text"?

koheripbal

That makes no sense. These two things have nothing to do with one another.

asxd

It crashed after I created a code block, converted it to a quote block, and the hit ctrl+z to undo (something about a history node not being found, I think. Sorry, should have saved the output).

zurfyx

Thanks for trying it out! Mind drafting a quick issue here so that we can have a look? https://github.com/facebook/lexical/issues

asxd

Sure, just submitted a new issue. Included in the issue, but I think there might be a more general problem with how block conversion is handled (at least for quote and code block types). On firefox at least, it's pretty easy to crash this by messing with block type dropdown.

mlajtos

zurfyx

mlajtos

I thought it was some kind of crazy obscure low-level optimization black magic, but probably not. :)

trueadm

I had to take a second pass on it. I thought I was maybe onto something when I wrote that originally. Is it a V8 perf hack? Nope, just my brain not functioning correctly at the time :P

eyelidlessness

Here I was ready to be crabby about yet another web based rich text editor, but after reading so many comments about how it’s not a good code editor—which it’s not, it’s not one at all atm—I’m kind of just crabby about the discussion being completely about something other than the topic. Y’all, I know it’s a thing in software to curmudgeon everything but can we at least curmudgeon the actual thing it actually is? Or maybe just suspend curmudgeon-ness and see if the thing is deserving of that in the first place?

dabedee

The code examples seem to not be working for me on Firefox 100.0b5 (64-bit) on Windows. I only see black rectangles.

compiotr

I understand the API will change, but will the JSON representation in such a way that it's not safe to use currently? I don't mind a bug here and there, but it would be quite serious not to be able to use old content with a new version of the editor.

Daily Digest email

Get the top HN stories in your inbox every day.