1.0.0-alpha.3 is the release where a public critique turned into a work item.

Someone from the Worklets team read my comparison page and pointed out, politely and correctly, that one of its central claims did not hold: native modules in a worker were not as isolated as I implied. A worker's HTTP response still landed on the React Native JS thread. If that thread was busy, your worker waited — which is the exact problem a worker is supposed to solve.

He was right. This release is mostly what it took to make that claim true, plus the zero-copy binary transfer he'd separately called out as missing, plus a new Hacks & compatibility seams page that writes down every place I'm leaning on private internals and what upstream change would let me delete it.

React Native has always been single-threaded where it matters most. Your JavaScript runs on one thread, and anything heavy you do there — parsing a big payload, hashing, compression, image work, a chatty reducer, a busy render — competes with the UI for the same runtime. The usual advice is "move it native," but that means writing a native module for every heavy thing you'd rather just write in JS.

react-native-workers brings the Web's answer to this problem to React Native: real background threads, each with its own JavaScript runtime, behind the Worker API you already know from the browser. Today it enters public alpha as 1.0.0-alpha.

This post is the full tour — what it is, how it's built, everything it can do (including some things a worker library usually can't), how hard it's been tested, what's still rough, and where it's going.