Hacker News: rickhanlonii

New comment by rickhanlonii in "Denial of service and source code exposure in React Server Components"

rickhanlonii — Fri, 12 Dec 2025 00:04:42 +0000

fwiw, the goal here wasn't to downplay the severity, but to explain the context to an audience who might not be familiar with CVEs and what's considered normal. I moved the note down so the more important information like severity, impacted versions, and upgrade instructions are first.

New comment by rickhanlonii in "Denial of service and source code exposure in React Server Components"

rickhanlonii — Thu, 11 Dec 2025 23:25:08 +0000

Yeah agreed, thanks again for the feedback. The priority here is clear disclosure and upgrade steps.

New comment by rickhanlonii in "Denial of service and source code exposure in React Server Components"

rickhanlonii — Thu, 11 Dec 2025 22:22:47 +0000

GitHub has to review the advisories and publish it for it to show in `npm audit`, so it's delayed.

New comment by rickhanlonii in "Denial of service and source code exposure in React Server Components"

rickhanlonii — Thu, 11 Dec 2025 22:17:01 +0000

Thanks for the feedback, I adjusted it here so the first note is related to the impacted versions:

https://github.com/reactjs/react.dev/pull/8195

New comment by rickhanlonii in "Denial of service and source code exposure in React Server Components"

rickhanlonii — Thu, 11 Dec 2025 21:54:06 +0000

After Log4Shell, additional CVEs were reported as well.

It’s common for critical CVEs to uncover follow‑up vulnerabilities because researchers scrutinize adjacent code paths looking for variant exploit techniques to test whether the initial mitigation can be bypassed.

New comment by rickhanlonii in "New Architecture is here"

rickhanlonii — Fri, 25 Oct 2024 17:58:39 +0000

That's a lot of questions, thanks for asking! I'll stick to answering the ones related to the new arch.

The next thing is to continue building on this foundation and fix some long standing issues things like scroll perf and text input. A lot of our focus has been on the gradual migration strategy for the new arch, so now we'll have more capacity to work on other things.

For perf differences, we shared some benchmarks here: https://github.com/reactwg/react-native-new-architecture/dis...

But perf alone doesn't really tell the whole story. In raw perf terms, flashing empty content for just one frame is only a few milliseconds, but user is disproportionally impacted by that flicker. The new arch allows us to fix those types of issue in addition to the raw perf wins.

New comment by rickhanlonii in "New Architecture is here"

rickhanlonii — Fri, 25 Oct 2024 17:52:48 +0000

I don't know of any Flutter comparisons, but we shared some benchmarks here: https://github.com/reactwg/react-native-new-architecture/dis...

New comment by rickhanlonii in "New Architecture is here"

rickhanlonii — Fri, 25 Oct 2024 17:51:33 +0000

Will do, thanks paul big fan of your work

New comment by rickhanlonii in "New Architecture is here"

rickhanlonii — Thu, 24 Oct 2024 18:45:03 +0000

In the post we explain that this release removes the bridge, so the JS thread calls C++ directly without a queue, serialization, or bridge: https://reactnative.dev/blog/2024/10/23/the-new-architecture...

New comment by rickhanlonii in "New Architecture is here"

rickhanlonii — Thu, 24 Oct 2024 18:29:49 +0000

Kind of. We already had a native UI tree running in native (the same way the browser has it's own internal representation of the DOM). The difference in this release is that we rewrote it in C++ and made it immutable. That means instead of having a different UI tree in each platform (one for iOS, one for Android, etc), we have one C++ tree that all platforms use. And since it's immutable, it's thread safe and we can read layout and commit it from different threads if needed.

Reconciliation is still done in React on the JS thread, similar to React DOM.

New comment by rickhanlonii in "New Architecture is here"

rickhanlonii — Thu, 24 Oct 2024 18:26:23 +0000

Yeah this is a tricky problem, and it's one of the reasons we updated our recommendation to use a framework like Expo that can make upgrades be smoother by being more opinionated about the setup.

As the core library, we need to support all the different ways React Native can be added to an app (from fully react native to adding react native to an existing app) and all the different build tools an existing app may use. So it's hard for us to be opinionated about the setup in a way that would make upgrades seamless, but a framework can solve this for you.

New comment by rickhanlonii in "New Architecture is here"

rickhanlonii — Thu, 24 Oct 2024 18:16:47 +0000

Capacitor is really cool because it allows you to build a web app in iOS and Android and access the platform APIs from JavaScript. The rendering layer is a bit different though, because in React Native you can use the platform APIs _and_ the platform components. In React Native, the views you render on iOS are the same UIKit UIViews that a native app would write. In Capacitor, these are DOM elements in a webview. There are different tradeoffs, but this difference is what makes React Native look and feel more native.

New comment by rickhanlonii in "New Architecture is here"

rickhanlonii — Thu, 24 Oct 2024 18:05:21 +0000

I helped write this post, so feel free to ask me anything about the New Architecture!

React Native: The New Architecture Is Here

rickhanlonii — Thu, 24 Oct 2024 13:51:20 +0000

Article URL: https://twitter.com/reactnative/status/1849200964303196491

Comments URL: https://news.ycombinator.com/item?id=41935494

Points: 2

# Comments: 0

New comment by rickhanlonii in "Ink: React for interactive command-line apps"

rickhanlonii — Tue, 09 May 2023 01:07:51 +0000

Yeah we all know what you're talking about, you don't have to explain it. Testing is not the universally correct strategy for every case, and unless you take the time to understand their use case, you're really not in a position to understand the tradeoffs or make value statements about their work.

New comment by rickhanlonii in "Meta Is Transferring Jest to the OpenJS Foundation"

rickhanlonii — Wed, 11 May 2022 18:35:17 +0000

From Jest's perspective, that amount is way over what we've needed to date.

New comment by rickhanlonii in "Meta Is Transferring Jest to the OpenJS Foundation"

rickhanlonii — Wed, 11 May 2022 18:34:24 +0000

We don't really need the funds and can't spent the ones we have, so we haven't pushed for more donations over the years.

New comment by rickhanlonii in "Meta Is Transferring Jest to the OpenJS Foundation"

rickhanlonii — Wed, 11 May 2022 17:17:22 +0000

Yeah, Meta will continue to use Jest internally. It still works really well for us, it's just "feature complete" for our use cases so we haven't needed to invest in it.

New comment by rickhanlonii in "Meta Is Transferring Jest to the OpenJS Foundation"

rickhanlonii — Wed, 11 May 2022 17:14:58 +0000

Meta is a backer of the Linux Foundation which OpenJS is a part of and has donated $22,000 to the Jest Open Collective which was created by Meta in 2016 to support non-employee Jest contributors. Jest actually has all the funds we need right now and our bigger issue is finding ways to spend it!

New comment by rickhanlonii in "Meta Is Transferring Jest to the OpenJS Foundation"

rickhanlonii — Wed, 11 May 2022 17:11:31 +0000

I started as a Jest core contributor before joining Meta. It's arguably the reason I work there now, and I'm really excited for the move.

Meta created Jest and a lot of the features that it's known for, but it's true that it hasn't been invested in for a few years and most of the recent features were created by the community.

With this move, Meta is showing their commitment to Open Source and Jest will be able to grow with ownership through the OpenJS Foundation led by the Jest core team and the Jest community.