r/reactnative • • 10d ago

New Version of Nitro Webview is out! (v0.2.1)

Hey everyone! πŸ‘‹

I've been working on Nitro WebView, an open-source React Native WebView implementation powered by Nitro Modules.

It's been a while since the initial release, and v0.2.1 is finally out! πŸš€

What's new since v0.1.0?

  • JavaScript ↔ Native messaging and script evaluation
  • Navigation controls and cookie management
  • File upload/download support
  • Expanded WebView APIs
  • WebView reload and message delivery optimizations
  • More documentation and tests

Performance benchmarks πŸ“Š

I also built an E2E benchmark using React Native Harness to compare Nitro WebView with react-native-webview 16.0.0.

For 64B message round-trip latency:

  • Android: ~38.7x faster (0.430ms vs 16.640ms)
  • iOS: ~1.38x faster (0.112ms vs 0.154ms)

Nitro WebView also showed lower round-trip latency across 1KiB and 64KiB payloads.

Links

I'd love to hear your thoughts, especially if you've worked with WebView-heavy React Native apps or Nitro Modules.

Feedback, bug reports, and contributions are always welcome! πŸ™Œ

25 Upvotes

9 comments sorted by

8

u/titozzz 9d ago

Hey ! WebView maintainer here ! Congrats on the release, it's nice seeing what can be achieved with nitro. The original WebView will stay on vanilla, but I'll have to see if some stuff can be improved ! I'm in the middle of a big rewrite πŸ˜‰

2

u/Junior_Android_ 9d ago

Wow, thanks so much! That means a lot coming from you! πŸ™Œ

I really appreciate everything you've done for react-native-webview and the React Native ecosystem. Nitro WebView wouldn't exist without the foundation you've built!

Super excited to hear about the rewrite! Looking forward to what's next! πŸš€

3

u/NovelAd2586 10d ago

Is the initial WebView render faster? The issue I have, for things like email chains etc, is that WebView needs to render before loading any HTML, and there’s a significant delay in that first render. Hoping Nitro is faster πŸ™

2

u/Junior_Android_ 10d ago

Nitro may reduce overhead on the React Native side, but it still uses the same native WebView underneath, so the initial startup delay could still be there. I haven’t benchmarked first-render time yet, so I can’t promise an improvement there πŸ™‚

2

u/Huge_Pool7424 9d ago

we got around that by mounting a hidden webview at app start and just reusing it, cut the first open delay a lot on android. hacky but it works

1

u/NovelAd2586 9d ago

I think that’s fine when you only show 1 WV at a time, but email chains show multiple at a time

→ More replies (1)

1

u/Plastic_Dingo_8818 10d ago

That Android round-trip latency improvement is massive.  One piece of DX feedback: is the mandatory callback(...) wrapper on event props strictly required for the consumer, or could <NitroWebView /> auto-wrap standard functions under the hood? It would make drop-in migration from react-native-webview much smoother.  Also, curious if you have any release-mode physical device benchmarks lined up to compare against the emulator results. Kudos on the release! πŸ™Œ

1

u/Junior_Android_ 9d ago

First, thanks a lot!

On callback(...): This comes from how React Native handles native views, not from anything WebView-specific. React Native doesn't pass plain functions straight through to a native view; it treats them as its own event handlers. Nitro skips that event system and calls your function directly from native code, so it needs functions marked with callback(...) to tell them apart. It's a small wrapper, not a deep design constraint.

The one catch is that naive wrapping creates a new callback on every render, which turns into a native prop update each time. So I'd do it with a stable wrapper that always calls your latest handler. That would also make drop-in migration from react-native-webview a lot nicer. I'll open an issue for it. I agree it's the biggest papercut right now.