Joe Savona

Your post was totally fair! I appreciate you sharing your experience :-)

The parts of the post describing subtle nuances are about which specific ways of breaking immutability the compiler does/doesn’t catch. But developers don’t need to remember which way of crafting an error will be caught or not! They just need to remember the rule, which is straightforward.

Thanks for sharing your experience! We’ll take a look to see if there are any of the cases you flagged where we can detect an error automatically.

There are two aspects: the rule & how we enforce. The rule is simple: don’t mutate stuff that crosses JSX/hook boundaries. You almost certainly follow this ~all the time, else you would have crazy bugs. What feels and is more complex is that we can’t statically catch all violations of this rule.

What if we all got together and agreed to pay a bit of money to the government every year so that they could put together a group of trained people to protect us from masked thugs in the streets?

We’re exploring a different direction but I don’t have a link handy. Cc @capt.dev

Still something we have on our list to potentially optimize further in a future release

In this example each element will “re-render” but what that means has changed: since each item will largely no-op if its inputs haven’t changed. With React Compiler a component function executing doesn’t necessarily mean much work happens.

I hope we’ve earned enough trust that people don’t think we’re so naive as to _only_ rely on feedback that we hear about directly. We also look at things like adoption which accounts for people bouncing off for various reasons, as well as on our own judgment/experience.

Did you already have ESLint running and our plugin slowed it down, or was the slowdown from switching from a fast linter back to ESLint?

..and avoid rewriting the core logic. But more importantly: we are very actively expanding and building upon the compiler. We’ll hopefully be able to prioritize build performance sometime in 2026 but we’ll see how things go. The more we hear about it the easier it is to prioritize so send feedback.

We get that reintroducing Babel in an otherwise Rust-based toolchain slows down builds. It’s a compromise. Unfortunately the Rust-based JS tooling ecosystem is fragmented - SWC and OXC - with different parsers and AST formats. We’re still hoping to be able compile with Static Hermes

Expanding on Dan’s answer. First, everyone on the React Compiler team had significant experience in Rust or C++, and several of us had also worked on rewriting Relay Compiler from JS->Rust before that was cool. The decision to use JS was purely about practicality..

panicThreshold – React The library for web and native user interfaces

You may also be interested in react.dev/reference/re... to fail the build on errors

So you should generally spread in the rules from the preset, and then override/add.

Great post, and it’s great that the compiler is working so well for you! One thing to be aware of w the way you set up your rules: you’re missing out on most of the validations!!! In ESLint if you specify any specific rules, it disables everything else from that preset..

Recent favorite: “test plan: yarn jest path/to/feature-test.js, all tests pass”. WE DONT USE JEST and the named test file doesn’t exist

Trend I’m seeing getting worse recently: a legit GitHub issue gets filed. Somehow people latch onto it as something they can spam us on. Multiple similar PRs, often from different people sharing bits of code, that look 90% plausible but with blatantly obvious tells.

Try `/terminal-setup` in Claude, that fixed it for me

Have you tried using React Compiler?

Link to the issue?

It’s in the docs (?)

panicThreshold – React The library for web and native user interfaces

By default we don’t error in the Babel plugin because breaking builds is generally not preferred. But if you want to fail the build on errors, you can: react.dev/reference/re...

Debugging and Troubleshooting – React The library for web and native user interfaces

React Compiler tries to automatically skip code that breaks React’s rules. Use the ESLint plugin to see the errors react.dev/learn/react-...

I would offer to fix it but we didn’t build that extension :-) An official React Compiler IDE is in the works, for now we recommend using the ESLint plugin in parallel w the compiler.

Yeah the word order just clicks after a while if you’re reasonably immersed. Vocab and kanji require study even if you’re immersed.

Customize your deck for words and phrases that you actually care about, aggressively delete cards that are boring. The time to create cards is study time.

One thing to watch out for with these sites is that the spaces repetition they use can be absolutely awful. WaniKani is *phenomenal* for learning kanji - or would be if their SRS wasn’t garbage. You waste so much time reviewing things you don’t need. Consider using Anki for your actual reviews.

Fuck yeah, this is the way. Diverse teams build better products. Good for Python.

Duplicating React Compiler’s lints is not realistic: it’s a lot of work and any community port will fall behind too. What we need is a Biome/Oxlint plugin that calls out to JS to run React Compiler. Eventually we will port the compiler to native, but we’ve got a lot more work in flight.