Issue #8
You’re reading The Lynx Lookback #8
April fools 😉 it’s a joke. No, seriously, we weren’t going to cover it. But then the developer world lost its collective mind, so now we’re here—begrudgingly poking around ByteDance’s shiny new toy like someone who found their ex’s rebound on LinkedIn. Is Lynx the React Native killer? Maybe. Is it worth your time? Well, that depends—how much do you enjoy rewriting your codebase every 18 months?
ByteDance just dropped Lynx, a shiny cross-platform framework quietly powering parts of TikTok—and suddenly half of tech Twitter is acting like React Native’s funeral needs planning.
Calm down.
Yes, it runs Android, iOS, and Web. Yes, it ships with real CSS—real as in native support for animations, transitions, selectors, variables, gradients, clipping, and masking. And yes, the dual-thread model separating UI and logic is cool, aiming for instant launch and silky UI responsiveness via its multithreaded engine. But let’s not pretend React Native isn’t already doing similar work under the hood with JSI and Fabric. It’s 2025—we’ve all moved on from the bridge.
Lynx is launching with React bindings but promises Vue and Svelte support too, which sounds great until you remember that shipping one ecosystem well is hard enough. And while their styling story feels like catnip for frustrated web devs, it’s not clear how that translates into dev tooling, DX, or cross-team velocity at scale. TikTok scale doesn’t mean open-source scale.
Does it look promising? Sure.
Are we all rewriting our apps next quarter? Please.
Wake me up when it has a proper ecosystem, a setup flow that doesn’t require wrangling Gradle and CocoaPods just to render a <view> (Axion.pm — “Setup and Project Structure” section), and enough third-party libraries to get through a week without rebuilding a date picker.
👉 Read the docs, poke around, and maybe start a side project.
But React Native isn’t sweating yet.
Speaking of multithreading—there’s a new RFC (that’s a Request For Comments, i.e. a formal proposal, not a release) from the team behind Reanimated that could change how React Native apps handle heavy work in the background. The idea? Take the system Reanimated uses to run animations on separate threads and turn it into a general-purpose tool that any library—or even your app code—can use, animation or not.
Worklets, if you’ve never touched them, are tiny JavaScript functions that can run off the main JS thread. They’re typically used inside Reanimated or camera libraries to keep performance high, especially when working with gestures, animations, or frame-by-frame image processing. Instead of bogging down the app by queuing everything through JavaScript, a worklet runs directly on another runtime (like the UI thread), keeping things smooth and snappy.
This RFC proposes turning that power loose. By extracting worklets into their own standalone library, the idea is to let developers move all kinds of computational tasks—AI inference, data processing, audio transforms, async storage writes—off the main thread. To make this work, they’re introducing a shared memory model which basically help threads exchange data safely without corrupting state or crashing the app.
It’s not released yet, and there’s no react-native-worklets package on npm. But if you’ve seen something similar in action, you’re probably thinking of react-native-worklets-core—a community-driven solution built by the team behind VisionCamera. It offers similar functionality for things like real-time camera frame processing or Skia rendering, but it’s tailored toward specific performance-focused libraries, not meant to be a shared, framework-agnostic utility. This RFC is aiming for something more universal.
👉 Read the RFC and maybe throw a 👍 on it while you’re there. You know… if you’re into faster apps and fewer dropped frames.
If you’ve ever stared at Metro’s bundling logs and wondered if your app could launch sometime this decade, Re.Pack 5.0 might be the alternative you’ve been waiting for. Built on Rspack—a blazing-fast bundler written in Rust (Rust is a systems programming language focused on safety, performance, and concurrency, known for its memory management without a garbage collector)—Re.Pack is designed to replace Metro with smarter builds, faster startup, and better flexibility for complex apps.
The biggest headline in 5.0 is **Module Federation 2**. This isn’t about fancier imports or clever bundling tricks—it’s an architecture pattern that lets you break your app into independently built, independently deployed pieces. Think: each major feature or screen in your app is its own bundle, managed by its own team, deployed on its own schedule. Then, at runtime, Re.Pack stitches them together in the shell app. That means less coupling, fewer conflicts, and a much more scalable codebase when your team or product outgrows the monolith.
This model originated in the web world under the “microfrontend” name, but now it’s making its way into mobile—and Re.Pack is one of the first bundlers in the React Native space to support it natively.
Performance-wise, Re.Pack’s switch to Rspack (from Webpack) under the hood gives you faster build times (up to 5x in some cases), better tree shaking, and tighter bundles—especially if you’ve got a big app and a long cold start. They’ve also improved code-splitting, so you can load only the chunks needed for the screen that’s currently in view.
As for switching? Their homepage says you can swap out Metro with a single command—and for bare or Expo Dev Client apps, that’s pretty close to the truth. They’ve got a quick start guide that walks you through installing @callstack/repack, adding a simple Webpack config, and pointing your app at it. But if your project has Metro plugins, custom loaders, or weird build scripts, you’ll still be doing a little cleanup work.
👉 Read the release post, or jump into the quick start guide.
Expo just shipped BackgroundTask, a new API that lets your app run code even when it’s not foregrounded. Perfect for syncing data, refreshing auth tokens, or doing light maintenance work in the background—finally without the silent push workaround and a prayer.
It uses a headless JS runtime that executes when the OS schedules it—not during deep sleep, but close enough to feel useful. You register a task, write the handler, and Expo schedules it when it can. No hacks, no ejecting, no regrets.
But let’s manage expectations: iOS support is limited (no background fetch yet), and execution isn’t guaranteed. Still, for managed apps, it’s the cleanest solution yet.
Last time on The Cramp Twins—sorry, Radon IDE (a tool built to streamline React Native development by integrating debugging, profiling, and performance optimization directly into your IDE)—we teased the upcoming Network Inspector and watched the tool go from “debugger with potential” to “actually useful day-to-day.” Now it’s back for version 1.4, and while we didn’t get the season finale reveal just yet, this release still moves the story forward.
The latest update introduces the Outline Renders tool, enabling developers to visualize component re-renders directly within the interface. This feature is invaluable for identifying inefficient components that may be impacting performance. Additionally, Radon 1.4 integrates first-party support for React Query DevTools, allowing seamless inspection and management of React Query caches without leaving the IDE. Furthermore, the update includes an option to record and preview CPU profiles of your application, providing deeper insights into performance bottlenecks.
The Network Inspector may have been the season highlight, but consider this a solid mid-season drop. Horace is still pretending console logs are enough. Dorothy has discovered performance tooling and is now deeply suspicious of all useEffect.
It’s official—React Native is sunsetting JavaScriptCore (JSC). JSC is the original JavaScript engine used by React Native, responsible for interpreting and running your app’s JavaScript code. As of version 0.79, Hermes becomes the default engine, and JSC is being moved to a community-maintained repository. In versions 0.81 or 0.82, JSC will be removed from the core entirely.
That might sound fine on paper—Hermes is faster, leaner, and works seamlessly with the New Architecture—but plenty of devs aren’t thrilled. For projects that still rely on JSC, integration with Hermes isn’t always seamless. Whether it’s compatibility issues, platform-specific quirks, or the pain of dealing with Hermes’ idiosyncrasies, the transition can feel like more of a headache than it’s worth. For teams with existing JSC-dependent setups, it’s not a simple “plug and play.” There’s no official guide (yet), but the clock is ticking, and Hermes isn’t waiting.
Fernando Rojo, another developer who probably doesn’t sleep, has gifted us with Galeria 1.0. And no, it’s not some front for money laundering disguised as an art gallery, as far as we know. It’s a React Native universal image viewer that supports the New Architecture, works on the Web, and integrates with next/image, expo-image, react-native <Image />, FastImage, and more. Under the hood, it’s built with native libraries to ensure smooth performance across all platforms, giving you top-tier image rendering with minimal overhead.
Galeria supports common image gestures like pinch-to-zoom and pan-to-close for easy navigation. It’s built to deliver fast, responsive image viewing across both mobile and web platforms, and it’s designed to work well with a variety of image sources, whether you’re using static images, remote assets, or dynamic content.
👉 Galaria
Long forms on mobile? We all know the pain. The keyboard pops up, and suddenly your inputs are hidden. Magic Scroll solves this by keeping your ScrollViews and input fields responsive, even when the keyboard’s on screen. It’s designed to prevent layout issues and ensure smooth interactions while users fill out forms.
With support for the New Architecture and Expo 52, Magic Scroll integrates seamlessly into your project with minimal setup. It’s a simple, no-fuss solution to manage keyboard behavior in long forms without needing a ton of custom code.
If you’ve had trouble with form fields disappearing or being covered by the keyboard, Magic Scroll offers a reliable fix without the complexity.
Skeleton screens are those gray placeholders that pop up while content loads—think of them as a “coming soon” sign for your app’s images or text. Setting them up manually? Yeah, not so fun. That’s where React Native Auto Skeleton comes in. It automatically generates skeleton screens based on your UI layout. No more stressing about how to align your loading state with your components.
It works across both iOS and Android, fully supporting the New Architecture and Expo 52. And if you’re picky about design (and who isn’t?), you can easily tweak the appearance of the skeleton loaders to match your app’s theme. It’s simple to integrate with minimal setup, so you can get back to actually building your app instead of spending hours on loading screens.
No, this isn’t an April Fools’ joke—it’s really that easy.
