Hacker News Reader

Comment by willsmith72 | Hacker News Reader

Are people actually using the react compiler?

Haven't heard about since ages ago when it was extremely slow

Yes absolutely.

It's brilliant: all useMemo and useCallback can be removed and you get the same runtime performance and then some, at the cost of only a slight increase in code size.

A small downside at the moment is the build time. This change will hopefully help address that because it will no longer depend on babel.

Very insightful, thanks. I just delved into it, starting here: https://react.dev/learn/react-compiler/introduction

I haven't tried the compiler yet, but I been very skeptical of the automatic memoization features. Both in that sometimes the default strategy to decide when to memoize is not good enough but also the hidden flow to trigger the memoization causing hard to spot performance regressions.

I would be interest to hear how it worked out for you.

It really does work very well in practice. A few things really help:

- Lints [1] that flag code that cannot be (correctly) optimised. Usually this is obscure code that is too smart for its own good. But the compiler leaves it alone and flags it for review, so most things just keep working.

- Lints that flag code that violate the rules of hooks. These rules became more critical to follow: failure to do so may break rendering. But non-compliant code can be easily be excluded from compilation [2], so you do not have to fix everything at once.

- Popular libraries that are not compatible (yet) are flagged and excluded automatically [3].

The compiler is better than manual memoization, because 1) it is hard not to forget memoizations, and 2) the compiler's output memoizes more granularly than manual memoization realistically could.

I have not found performance regressions. Not saying they're not possible; but we haven't encountered them.

We have a very performance-sensitive project that used preact (chosen for performance) via its compatibility layer, that we switched to React + React compiler. Performance is noticeably better than with preact. Whereas previously the React-only version was incredibly slow even with carefully placed memoizations, because they were very hard to get right.

[1]: https://react.dev/learn/react-compiler/installation#eslint-i...

[2]: https://react.dev/learn/react-compiler/incremental-adoption

[3]: https://react.dev/reference/eslint-plugin-react-hooks/lints/...

I was thinking mainly cases like this

const nestedDependency = { a: { b: { c: 'c' } } }

useMemo(() => nestedDependency.a.b.c, [nestedDependency])

useMemo(() => nestedDependency.a.b.c, [nestedDependency.a.b.c])

neither triggers react hook lint warnings, although I guess this is more relevant to useEffect than memoization.

If you’re interested in what a specific piece of code compiles to, it’s worth checking out the online compiler playground [1]

https://playground.react.dev/

I think the reason you haven't heard about it is that it just works. It's fast - with Vite 8 my moderately large app compiles in ~800ms, which includes typescript, react compiler etc.

I also took a step to clean out all memo, useMemo, useCallback across the app and so far have not run into any issues from doing this.

We have used React Compiler in production for a large ecom / media website for about a year. Performance has been fine overall, and we haven't ran into any major bugs attributable to it in that time.

My company tried it but reverted the changes. The biggest reasons - it's not compatible with mobx and we didn't notice any perf gains on an existing codebase.

We started using it for unifi.ui.com and the render performance gain has been massive.

Yes, and no. For some of us, there are projects with Next.js we cannot get away from, but those use Vercel stuff, also written in Rust.

Not sure how they relate to each other.

Next.js supports React Compiler: https://nextjs.org/docs/app/api-reference/config/next-config...

Reply on news.ycombinator.com