solito-vite

[redbar0n]

Would be awesome if someone made a Solito-like implementation but for Vite (to work with one of its awesome Vite SSR libraries/frameworks, instead of NextJS (which is likely forever tied to Webpack). Where @brillout's vite-plugin-ssr looks the most promising.

Why do this? Well, to quote @nandorojo :

Faster building (ESBuild, etc.) If my Next.js app took 30 seconds instead of 15 minutes to build, I could move so much more quickly. Also: Babel, Webpack, and co. are too confusing. I hope the future holds a simpler version of these. tweet

My response:

vite-plugin-ssr lets you replace Next/Webpack (and babel?), and use ESbuild, since @vite_js
uses an unbundled development env with ESbuild for transpiling types, and Rollup for the production bundle. tweet

Some benefits of vite-plugin-ssr:

• Faster: Vite > Webpack, since unbundled (ESM) > bundled development.
• Removes magic..
• Interoperability with other libraries out of the box (without waiting for NextJS framework updates/plugins...)
• Gives architectural control back to the developer (choose any render lib) for a slight bit of more initial work (simple > easy).
• some more benefits.

Tagline for solito-vite/solito-vite-plugin-ssr could be "A library dedicated to unifying React Native with vite-plugin-ssr, primarily focused on navigation."

(In the same spirit as solito-remix or solito-redwood.)

Just throwing the idea out there. Fully understand if it won't be on Fernando's radar, since I imagine untying from NextJS might be a hassle.

Solito is supposedly a tiny wrapper library, that looks like it has about 2000 lines of TS & JS code.

@natew of Tamagui is currently brewing on something Vite-related, but he's currently using (parts of?) Hydrogen because of its Vite and cutting edge React Server Components support. But Hydrogen is a framework for making Shopify storefronts, so relying on it wholesale won't generalize as well to all kinds of universal apps.

Update 2023-10-24: Link to Discord discussion: https://discord.com/channels/1085921563372703815/1166451963974668319

[jkhaui]

I haven't worked with Solito personally (came across this repo from one of Fernando's talks), but thought it would be worth sharing my experience building a Vite SSR-based universal router which makes use of native navigation patterns (stack navigators, tab navigators, etc.)

Context

I'm working on a hybrid cross-platform framework which adheres to two fundamental philosophies:

• Vite & ESM is the future of JavaScript infrastructure, thus should have first-class integration from day one (as opposed to bundlers like Metro or Webpack)
• Cross-platform UI should be server-driven, while navigation should be isomorphic (that is, initial page loads on web should be server-rendered -> client handoff -> clientside routing for duration of session)

Also note that I'm actually building on top of Astro as a base framework.

Astro is essentially just a light wrapper over Vite in SSR mode—analagous to the way vite-plugin-ssr/vikejs works—so for simplicity's sake I use "Vite" to refer to any of:

• vite-plugin-ssr
• Astro
• vanilla Vite in SSR mode

as they are essentially the same thing. A navigation implementation in any of these modes should be easily portable to any of the others.

Strategy, rationale & complications

Unlike Solito's approach of splitting navigation responsibility between Next/react-navigation depending on the platform, I chose a higher-level abstraction with deep web integration: a server-first implementation of react-navigation, using Astro as the backbone for Vite on the server.

IMO this was the only feasible way to get server rendering working because of the explosion in complexity when you combine cross-platform inconsistencies with client/server handoff. Furthermore, I soon realised why no (decent) modern cross-platform routing solution currently exists despite the obvious need for one - because it's bloody hard to build 😬. Here are just some additional complications that must be handled:

• CJS/ESM interop errors
• Opaque errors thrown by transient react-native dependencies which can only be fixed by monkey-patching node_modules
• Hydration issues
• ReactDOM.renderToPipeableStream + suspense boundary issues
• React 18 concurrent mode issues
• Conflicting transpilers
• If you've made it this far, realising that Vite itself has many issues with inconsistent dev/prod behaviour due to its use of ESBuild/Rollup
• ...and a lot of functionality one takes for granted with Webpack on the server (e.g. pre-rendering static assets) completely breaks Vite in SSR mode because server-side Vite uses Node in a weird way

A couple more tricks I used were to borrow (i.e. steal) Nate's react-native-web-lite from Tamagui and Expo's Babel preset. Both of these libraries made it much easier to support Vite.

---

Anyway, after tearing my hair out for a few weeks fighting all these issues, I managed to get a working MVP locally.

It's an isomorphic router (free of hydration issues!) with first-class support for stack + tab navigators and SSR. Conceptually it's a similar approach taken by Expo Router; however, with native Vite & SSR integration (Expo is tightly coupled to Metro and currently only supports static page generation).

I hope this post provided you or others reading with some insight.
I'm polishing up my router so I can open-source it soon. If anyone has any questions or wants to collab, just tag me. The next feature I want to build in the router is RSC support but this looks like it could be an even bigger undertaking unless Remix, Redwood, or React's core team ships an official Vite implementation first.

P.S. if you're not aware, in the time since you wrote this post, Hydrogen announced it's no longer supporting RSCs. But Shopify also acquired Remix which announced it is working on RSC support, so... 🙄

[redbar0n]

Awesome!👏🏻

Two clarifying questions:

Cross-platform UI should be server-driven

Do you intend this also for react native? Like AirBnB’s server-driven rendering (SDR) which basically lets the server control what components are rendered on mobile? (Meta’s Messenger does something similar but via SQLite wizardry). I presume you don’t mean this (as it ventures into the potential domain of RSC’s), just curious to clarify.

Unlike Solito's approach of splitting navigation responsibility between Next/react-navigation depending on the platform, I chose a higher-level abstraction with deep web integration: a server-first implementation of react-navigation, using Astro as the backbone for Vite on the server.

Could you clarify this a bit? Do you run react-navigation on the server? How does that work, I thought it juggled react native screens and whatnot?

[brillout]

Thanks for pushing the envelope @jkhaui. FYI: Vike very much wants to accommodate its interface (when it doesn't already) for endeavours like yours in the long term. We're currently focusing on a couple of priorities right now but, after that, we're looking forward to (further enable) deep integration with mobile platforms.

[natew]

@jkhaui you should get in touch with me, I've gotten vxrn somewhat working with a forked expo router and I'm aiming to put together a stack eventually that does make universal easier. We should collab

[jkhaui]

Awesome!👏🏻

Two clarifying questions:

Cross-platform UI should be server-driven

Do you intend this also for react native? Like AirBnB’s server-driven rendering (SDR) which basically lets the server control what components are rendered on mobile? (Meta’s Messenger does something similar but via SQLite wizardry). I presume you don’t mean this (as it ventures into the potential domain of RSC’s), just curious to clarify.

Unlike Solito's approach of splitting navigation responsibility between Next/react-navigation depending on the platform, I chose a higher-level abstraction with deep web integration: a server-first implementation of react-navigation, using Astro as the backbone for Vite on the server.

Could you clarify this a bit? Do you run react-navigation on the server? How does that work, I thought it juggled react native screens and whatnot?

Good questions - firstly, I should've been clearer in explaining that what I'm trying to build specifically is a webview-based framework by leveraging core RN libraries that work with react-native-web, and supplementing any native functionality with Capacitor plugins. So sort of like a modern take on quasar or Ionic. Therefore, in my previous post, by server-driven UI I mean meant server-rendered HTML.

But here's where it gets interesting if you're attempting to build a server-driven solution using the conventional RN strategy of deploying native iOS & Android builds. In case you weren't aware, some context: a server components endpoint doesn't actually ship HTML to the client. Rather, it streams something called an "RSC payload". This is serialised JSON which the client React renderer then uses to work out what to diff/reconcile in the vDOM tree to update the UI with the server response.

The above is really the key point IMO because it means we'd derive the most value focusing on a Vite RSC implementation. This can then have routing logic layered on top. In this way, we'd finally have cross-platform server-driven UI & navigation, instead of all the current intermediate workarounds.

**in writing this, I literally just came across this tweet from Evan Bacon which gives me even more confidence that it's the approach to take. Super cool!

To answer your second question: basically, yes, running react-navigation on the server: https://reactnavigation.org/docs/server-rendering/

It's a bit involved to explain so hopefully I can just get a demo up soon. I render a shell of the requested route as an Astro island which is then hydrated client-side. And it does use react-native-screens, though on web you can omit this and react-navigation will fall back to react-native-web's default View.

Thanks for pushing the envelope @jkhaui. FYI: Vike very much wants to accommodate its interface (when it doesn't already) for endeavours like yours in the long term. We're currently focusing on a couple of priorities right now but, after that, we're looking forward to (further enable) deep integration with mobile platforms.

Sounds great, I'm a big fan of your work. Keep it up!

[redbar0n]

bringing the server like experience to web apps

*native like experience to web apps, I presume you meant.

[nandorojo]

There is no reason to optimize server components for native apps. It’s the wrong thing to prioritize and will introduce problems that don’t need to exist.

[javascripter]

Remix released an unstable Vite support recently and it supports SSR without RSC. Remix is a web framework so it implements various bundling optimization features similar to Next.js. For example it can inline critical CSS, which is useful for large apps.

• https://remix.run/docs/en/dev/future/vite

The most painful part of universal RN apps right now is:

• Next.js App Dir with RSC is incompatible with RN and you need to sprinkle "use client" everywhere and it doesn't add much value for RN and complicates codebase
• Expo Router for Web is more compatible with RN but lacks critical web bundler features like Tree Shaking and Bundle Splitting. SSG support is too slow and SSR support isn't there yet either.

A custom Vite framework that implements Expo Router file-based routing is great. However, I'm a little concerned about the web optimization features if we go that route, given Expo Router for Web lacks many of the features Next.js provides currently.

Creating a React Native for Web adapter for Remix Vite won't solve the universal routing part, but we'll get many web optimization features for free without RSC incompatibility issues so it could be worth the trade-off.
I'm not using Vite at work currently so I'm not too sure if web optimization features Next.js / Remix provides is easy to keep up in a custom Vite framework though.

[redbar0n]

Next.js App Dir with RSC is incompatible with RN

I think it works now, with Solito: https://solito.dev/app-directory/overview

A custom Vite framework that implements Expo Router file-based routing is great. However, I'm a little concerned about the web optimization features if we go that route, given Expo Router for Web lacks many of the features Next.js provides currently.

A Vite framework or plugin wouldn't necessarily need to use "Expo Web" (what I think you mean with "Expo Router for Web", since Expo Web uses Expo Router). It could rather use Expo's file system routing matchers, as suggested by this guy who combined React Native Web with Remix.

It's also helpful to support the effort of a file system routes matcher rewrites API for Expo Router by encouraging Evan Bacon to implement and expose it. That way Remix, Vike and other file system routers could be brought into alignment. Please upvote this comment, as a start.

[javascripter]

https://github.com/javascripter/remix-vite-rnw
I experimented a little with Remix Vite mode and so far made the following basic features work:

• file extensions (.web.ts / .web.tsx works, see vite.config.ts)
• import { Text, View } from 'react-native' works (using bun alias, see package.json and vite.config.ts. doesn't have TypeScript definitions)

[redbar0n]

@jkhaui Thanks for the detailed response!

I’m not entirely sure of the setup you’re envisioning…

Is it similar to tech strategy 6.2 «Turbo Native w/ React Native shell« or nr 7 «React inside React Native WebView [hybrid]» in this article: https://dev.to/this-is-learning/the-different-strategies-to-building-a-cross-platform-app-3p56 ? But using Capacitor instead of React Native for the shell app?

Let me see if I get this correct:

You have a CapacitorJS shell app, which bundles a native Web View, which again loads the webapp on-demand from the server. On the server you SSR the webapp with Astro mainly as a big Island made with React Native Web (which is then hydrated in the client Web View).

It does sound a bit convoluted.. Note that CapacitorJS by default bundles all HTML/CSS/JS with the app that is shipped to the App Store. Even if it is in a Web View. Since Apple is more likely to reject shell apps that load the HTML/CSS/JS from the server on demand (with the reason «the web is for that», requiring some Minimum Native Functionality).

Not sure why Astro is a particularly good fit either, if you don’t render parts of the page potentially in pure HTML? If it’s only a single big island anyway, why not bare metal Vite or even vite-plugin-ssr aka Vike ?

Also, if you’re using React Native Web, why not take advantage of the React Native part of it on native? If you only ever load it from the web server and in a Web View, couldn’t you just use React then, and get access to the wider web ecosystem/libraries, and deal with less potential cross-compat issues between RN and web?

Not to mention where RSC’s really fit into this… Why bother with RSC’s (to avoid shipping JS bundles and hydration) if you are already using Astro which can avoid sending JS bundles and just SSR and ship the pure HTML (which doesn’t need hydration and is lighter than JSON wire format that RSC uses)?

PS: If it at all makes sense to go the RSC route* then for potential inspiration/collaboration, here is a vite-rsc reference implementation made by cyco130 the author of RakkasJS.

‘* I’m with Nate here in questioning the utility of RSC’s, due to complex setup («use server» and whatnot), convoluted mental model / onboarding issues, and RSC’s requiring more server work/interactions and network round trips. I’d rather have offline-first than server/hostingprovider-centric !

[redbar0n]

If we’re really going Hybrid and Server-driven / Web oriented, then what I’d really like is to be able to easily make:

• a React Native shell app with Tamagui (RNW), which could access some native functionalities (camera etc.)
  -which would handle native navigation (like Turbo Native)
• which would have a Web View that loads the main part of the app as an initially SSR’ed webapp (but subsequently offline-first, like Vike/vite-plugin-ssr enables)
• which would be written in Tamagui (RNW)
• so that in case I later want to make the whole app native and publish via the App Store, it would be as easy as «ejecting» the web app from the Web View and simply replacing the shell app wholesale.

Because then it’s easier to start web-first, while having access to native functionality (via the shell app), but keep a fast testing and rollout pipeline (on-demand via your web server, not wait for app store), with the option to eject to a full React Native app if/when need be.

(But, frankly, all of these merry-go-arounds feel a bit like a code smell. The simplicity of a simple server-template rendered webapp with HTMX served to all platforms seems more and more enticing.. since https://whatpwacando.today has come quite far, even notifications on iOS.)

[nandorojo]

Not sure I follow. Just use a web framework on web and React Native on iOS/Android.

[redbar0n]

@nandorojo The reason to avoid having the entire app, in React Native on iOS/Android, in favor of merely a shell app, would be to get a smoother:

• Testing story (not having to setup testing tools for native/RN, but rely only on the web testing tools for the webapp).
• Deployment pipeline (not having to rely on paid services like Expo EAS for code push, but merely update your server’s rendering).
• Auth: not having to deal with crossplatform auth (or paid services like Clerk), which is a major pain.
• Fewer environments to adapt to (staying web-first), since every env has a rate of change and your app can fall out of sync with either one (esp. if executing it in 3 envs like in the webserver, webclient/browser and RN/native).

The goal being to be as much web-first/PWA as possible (avoid app store hassle and the 30% revenue cut), but while having 2 readily available fallback options if users really want/need a native app (after all). In order of preference, then fall back to:

1. the React Native shell app (getting the above benefits)
2. create a full blown React Native app (monorepo, solito, expo EAS etc.)

[javascripter]

@redbar0n cc @nandorojo
A couple thoughts on this:

• Sometimes it does make sense to have web-only implementation for some screens even in RN apps
  • e.g. In ChatGPT like app, you may want to show some complex Markdown + math equations in Chat screen, which is easy in React DOM, but difficult in RN
• Evan Bacon tweeted about this idea briefly
• Software Mansion created a demo repository of Turbo Native for integration with React Native a while ago, which is based on Ruby on Rails's Turbo Native
  • Basically, shell screens containing WebViews load only the content part of the website (excluding the nav bar, etc), and navigation back/forward to another route will be intercepted on native side and screen stacks are handled properly on native side
  • a single WebView is shared across multiple screens and unfocused screens will just show the screenshot of the WebView to save memory
  • Some screens can be implemented on native side and others can be web-based. Routes handling are explicitly handled.

If we were to implement a Expo Router counterpart of Turbo Native properly, we need to:

• be able to load only the content (screen file), excluding the layout file
  • for proper gesture handling and native-feel of screen headers, navigators etc should be implemented on native side with layout files
• proxy setting screen options like header title in WebView to native navigators (e.g. setting data-dependent header title from web to native)
• be able to invoke functions on WebViews from native (e.g. native header right button "Submit" calls form submit action in the WebView)
• be able to invoke functions defined in RN from WebView ("Share" button in WebView opens a Bottom Sheet on RN side)
• have navigation intercepted and automatically handed-over to native/web versions

In summary, most of these needs to be implemented in Expo Router for ideal DX (automatic native/web routing, <Stack.Screen options={{ title: 'title' }} /> inside WebView propagating to upper native navigator, and more), so I think it's outside the scope of solito.

[nandorojo]

This might be a useful library for some screens or components on the fly, but I've never used a mobile website that comes even close to native quality such that this would interest me. It falls outside of the goal and philosophy of Solito, which is to give you the native experience on all platforms and build with little compromise - all while simplifying that process.

I agree there are some pages / screens where this is useful, and I think a better way to use web code on native without having to worry about bundling would be convenient. But I would not spend any time making a framework built on web views instead of RN. Building a worse app because it's easier to test webviews is a huge miss in my opinion.

I would prefer to focus on what bifurcations there are across platforms and address them. There is no reason to prioritize server-driven or web-based implementations.

Of course you're welcome to disagree and build your own web view-based approach outside of Solito, but my take is that it's only a step backwards.

[jkhaui]

Thanks Nate and Fernando for your feedback. I’ve really enjoyed listening to talks from both of you, so it’s interesting to hear your takes on how we should evolve navigation in a universal stack.

Fair bit to unpack in this thread - I’ll start with Nate and collaboration. I’m definitely keen, let me know the best way to get in touch with you.

I’ve been thinking: even if we might all have different visions/goals for where to take this, there’s surely some common work involving Vite + react-navigation that would benefit us all. What comes to mind atm:

1. A common Vite plugin which gets react-navigation & relevant dependencies working with Vite in SSR mode (what I’ve got atm looks to work with Astro & Vike, so should be straightforward to extract this into a standalone Vite plugin).
2. Stack navigator optimisations - and potentially other navigators in future, but react-navigation’s default stack navigator is definitely the lowest-hanging fruit for rebuilding a simpler & performance-optimised version on web.
3. Potentially re-implementing navigation animations with framer-motion (e.g. iOS-style LTR screen transitions, swipe to go back gestures). Framer motion is generally the best option for web today; animations are primarily done in CSS and thus don’t block the main JS thread (also claims to achieve 60FPS on mobile devices).

This way we could theoretically all reap the benefits of sharing underlying web navigation setup while still maintaining the freedom to build the rest of the stack in whatever way we want (RSC/no RSC, single webview vs RN platform-specific approach, vanilla Vite vs. Vite-based framework, etc.). What do you all think?

[natew]

Shoot me a DM on discord username foobully.

I think these sound reasonable. I have react-navigation working pretty much in vxrn, I think there's a ton of work in that repo that could be cleaned up and turned into nicer plugins or libraries.

On web the stack usually turns into a typical browser forward/back, I don't know if having a "web" stack is worth it in terms of UX as mobile Safari is really difficult to do dragging with for example outside of using history. Open to ideas there.

As for animations - Tamagui does a lot of work to provide an abstract animation driver API. It lets you share animation code between Reanimated, react-native Animated, and CSS. You can even do things like useAnimatedNumber and useAnimatedStyle. Reanimated is the closest we have to a "universal" style library. Though swipe back gestures on web is a path I've gone down and bailed out of numerous times, it's maybe impossible to get anything done there with Safari controlling up the left side swipe. Also keeping stacks in memory is basically impossible as it slows down quickly, and things like React Freeze don't really solve it unfortunately. React Offscreen may help here eventually.

Sounds good in terms of collaboration though, look forward to chatting.

[nandorojo]

My take is that stack navigators and the like shouldn’t be rebuilt for web. But if they are, they should be a separate UI library that you can optionally use, fully decoupled from any routing solution. There’s no reason for websites to have to inherit navigation styles. While that’s a common and opinionated practice for native apps, websites should have close-to-the-metal control over CSS styles, including headers, sidebars, and other navigation elements.

If you really did want those opinionated UIs on the web, you could use react-navigation or expo router on web. But I went down that road and it was a mistake. Simple things like scrolling get completely highjacked because the max height of the screen is determined by the stack navigator’s styles.

That’s why Solito treats screens as primitives and each platform implements them how it wants.

If you want to bring things like stack animations to web, go for it. But make sure that it’s a separate component from the routing itself.

[nandorojo]

Thanks Nate and Fernando for your feedback. I’ve really enjoyed listening to talks from both of you, so it’s interesting to hear your takes on how we should evolve navigation in a universal stack.

Glad to hear it!