trueadm

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.

The Octane compiler has overlap in terms of memoization but also goes far further

We’ll address the website content :) thank you for the feedback

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

We’re looking to address the feedback with the website copy. Thank you for the feedback!

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.

It's a relatively new domain, so corporate DNS servers are likely to block it.

There is definitely a bug there, I'll put up a fix in a bit. Thanks! :)

I contributed to React and Svelte on their core teams for years. Sometimes you just need to break free

It was a good time for change, I was working on Svelte 5 non-stop for two years! I'll be announcing my new role nearer the time :)

Please can you create a Github issue with the security holes you've found? That would be greatly appreciated. I've given it a sweep and found nothing.

I left Vercel a few weeks ago and I left the Svelte team earlier this year.

I work on Svelte 5 and I was also a React engineer on the core team previously FWIW.

You can set the direction of the ElementNode explicitly to define LTR/RTL semantics. By default it’s automatically detected.

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!

We have some important changes landing soon that will make insertions O(1) rather than the current O(n) - so this will greatly improve performance.

It's probably because we're using a native select element, which likes to steal selection on Android.

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.

Lexical has markdown support via `@lexical/markdown`. See https://lexical.dev/docs/api/lexical-markdown.

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.

Check out this answer I used in a previous HN thread:

https://news.ycombinator.com/item?id=31020205

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:

https://github.com/facebook/lexical/blob/main/packages/lexic...

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:

https://github.com/facebook/lexical/blob/main/packages/lexic...