I mean I created Octane coming from being one of the authors of React from years ago. Octane makes breaking changes compared to React to improve on things that aren’t that important in 2026. For example the synthetic event system - which takes up 13kb of React’s payload and adds overhead over just using the correct DOM events.
TSRX allows for better runtime generated guarantees, especially around loops which generates faster runtime logic from it. We can’t assume too much statically when reading something.map as the method might have different heuristics
It has all the same SSR APIs as React. The Octane website is rendered with Octane and the source is in the GitHub repository if you’re interested to see how it works
We just run a script that runs the benchmarks and updates the chart. It’s rounds numbers too. We’ve been as honest as possible in all the benchmarks - there’s no point in lying about a metric.
Thank for the detailed input. Would it be possible for you to create a GitHub issue around these (or many issues?) so that the team can track them and fix them. Thanks again!
Now thinking about it, I don't know why we didn't just do that. There must have been a reason, but I really can't recall what it was. If you're ever interested in contributing, this would be an epic contribution! :D
ProseMirror is a great choice. Lexical might offer you more mileage if you're working with React (especially React 18 and the new concurrency features) and are happy to invest into a project that is still pre 1.0.
The Lexical playground is one giant kitchen-sink example all written in React. You could check out the code for it locally and `npm run start` and play around with removing/adding plugins. You can also check out some examples on Codesandbox: https://codesandbox.io/s/lexical-rich-text-example-5tncvy
For Meta, or in general? For Meta, there are plenty of teams that require some infra knowledge around these common concepts. It's been fairly straightforward to find a team as a front-end engineer that allows you to excel in these areas at Meta (once you're successful in the interview loops).
It's replacing any previous web text editor UX components that we had in the past (likely DraftJS). We're also building Lexical for iOS which is slowly rolling out across iOS devices too.
Lexical supports code support / markdown. We actually use it a lot for Workplace, which is a kind of Facebook-like website for companies. It's really down to the product surfaces what features from Lexical they choose to use.
Yeah, I really wanted to avoid them too. There doesn't seem a good way. The issue you describe with selection jumping is a well known issue with GBoard. Here's the logic for the mutation handling:
What features in particular are you missing? We haven't really discussed a deadline for 1.0, as we've been trying to take our time making sure each release is impactful and correct.
It's used throughout Meta. The Post Composer, and Comment Composer on Facebook/Workplace, on Messenger, WhatsApp Web, Instagram Messenger, and many other surfaces too!
Android is indeed a headache to support. The biggest issue is how all keyboards force composition on all keystrokes, meaning you're constantly having to read the DOM input and work out what might have been entered. We don't use extra DOM nodes, but we do listen to `beforeinput`, `input` and use DOM MutationObserver to try and detect common Android patterns. I'd search this module for references to Android: