After years of developing C++/JSI libraries, I built a module system with all the lessons I learned and all the requirements we had to build powerful native libraries while still being fast af - I recently open-sourced this - it's called Nitro.
Nitro solves;
Threading issues with JSI (we just had a hard-crash in RN Skia with RuntimeAwareCache.cpp today)
Flexibility issues (HybridObjects are basically limitless in features because you can expose everything to JS)
Performance issues (Nitro uses NativeState, clever caching, and has a highly optimized C++ codebase)
We're migrating more and more libraries over to Nitro, starting with react-native-unistyles, to react-native-video, even react-native-webgpu and react-native-filament. I am also migrating react-native-vision-camera and react-native-mmkv over to Nitro.
I'd love to discuss a potential migration to Nitro for RN Skia as well - I think it could yield great stability improvements (no more threading crashes), as well as a much simpler codebase (way less code, especially for any C++ -> Java or C++ -> Swift/ObjC bindings we had to write ourselves - Nitro does all that). On top of that, we might even see some great performance improvements, but hard to estimate beforehand.
I realize that the RN Skia codebase is huge and a migration to Nitro cannot happen overnight - so I'm just creating this issue to discuss it.
Description
Hey William (and other maintainers)!
After years of developing C++/JSI libraries, I built a module system with all the lessons I learned and all the requirements we had to build powerful native libraries while still being fast af - I recently open-sourced this - it's called Nitro.
Nitro solves;
RuntimeAwareCache.cpptoday)We're migrating more and more libraries over to Nitro, starting with react-native-unistyles, to react-native-video, even react-native-webgpu and react-native-filament. I am also migrating react-native-vision-camera and react-native-mmkv over to Nitro.
I'd love to discuss a potential migration to Nitro for RN Skia as well - I think it could yield great stability improvements (no more threading crashes), as well as a much simpler codebase (way less code, especially for any C++ -> Java or C++ -> Swift/ObjC bindings we had to write ourselves - Nitro does all that). On top of that, we might even see some great performance improvements, but hard to estimate beforehand.
I realize that the RN Skia codebase is huge and a migration to Nitro cannot happen overnight - so I'm just creating this issue to discuss it.
Thoughts? 😄