Alternative to using Next.js for SEO with react-native-web?

[mayank-budhiraja]

I need SEO for the web app but without next.js I can do it. Is there any other alternative? or just simply use a wrapper above screens for basic SEO

[cglacet]

Did you tried server side rendering? I think the question is related. Maybe some people here have experience with SSR?

I'm also very interested by this SEO question.

[Freddy03h]

I'm using Razzle for my RNW app

[MiguelNiblock]

Looking at it that way I agree, you could do server-side data loading only for the few screens that really need ssr/ssg which are a few public routes. For the rest, the authenticated routes, you will continue to do client side loading and rendering.
@Freddy03h did you actually end up using the react-navigation container for SSR? https://reactnavigation.org/docs/server-rendering/

that is one of the main reasons why i was interested in razzle, using this instead of file-system based routing configuration.

[Freddy03h]

No I'm not using react-navigation on web.

(It's off topic, but I'm using rescript, so a variant type, pattern matching and the default small Router in rescript-react is enough)

[flsilva]

@MiguelNiblock Remix looks awesome, it seems to simplify a lot of things out of the box and in a very nice way, but I agree it's not flexible regarding its bundle pipeline configuration, and it seems 100% focused on web apps (for now at least). It might take a while for it to start being used with React Native for serious apps, if at all, but I wish they take that path, supporting cross-platform and RNW apps seamlessly. If that was the case, I'd build my next RNW app on top of it for sure. But for now Next.js seems like a very good solution to me.

@Freddy03h I'm not a fan of the page logic and routing based on files and folders on Next.js either, it'd be much more flexible if it was based on simple JS configuration. So I can see why it makes sense for you to use something more flexible like Razzle, since you already had a React Native-only app with its own file and folder structure, and the web app came later. One important thing though: even though you're right that SSR will work only for the first visit, users might visit (open) your web app many times a day, several days a week, so that's a lot of "first visits", and adds up to a far from ideal user experience. Per what you mentioned, I'm assuming you're CSR (Client-Side Rendering) your app when a user logs in. That's what we've been doing for ages now in the SPA land, I did that a lot of times in the past too, but by doing that our apps usually take several seconds to bootstrap and render. I think it's time for us to improve that on every app we write.

I strongly recommend you to read Remix vs Next.js from Ryan Florence (Remix co-founder), to understand why he states that "...server rendering is about better performance, too, not just SEO.". When a logged in user visits a web app, the web app can make several requests right away to bootstrap a user's dashboard, etc. When you CSR it takes a lot more time to FCP (First Contentful Paint) i and TTI (Time to Interactive) than when you SSR. Ryan does a great job explaining it in that post. Another huge benefit is that your code can be much simpler if SSR is your only rendering implementation (as is the case with Remix). It even replaces the need for SSG if you run on the edge, as he explains, and cache content in a CDN (for requests that makes sense caching, which might include dynamic requests like product searches that he explains). So you kind of get the best of both (three?) rendering worlds. That looks very promising and a superior solution than Next.js to me. But since cross-platform apps using RNW are very appealing to me as an engineer, saving a lot of time and money for my clients (those who of course benefit from an app deployed to those three platforms), I'm still using Next.js, but I'd love to give Remix a try when they make it possible without hacking their platform.

@mayank-budhiraja For web-only apps, Remix is probably better (per what I've read), but for cross-platform RNW apps I still think Next.js is the best and most flexible solution since Remix doesn't support RNW (at least not without some hacking and probably some other issues and limitations).

Let me know your thoughts.

[Freddy03h]

@flsilva

One important thing though: even though you're right that SSR will work only for the first visit, users might visit (open) your web app many times a day, several days a week, so that's a lot of "first visits", and adds up to a far from ideal user experience.

It's not how it work. As I mentioned the app works offline, it mean the app shell is stored locally, so when the user make a 2nd visit. The app shell is loaded from the cache, the SSR server is not requested. It work like a mobile app you installed on your device.

[abdulragib]

@flsilva

One important thing though: even though you're right that SSR will work only for the first visit, users might visit (open) your web app many times a day, several days a week, so that's a lot of "first visits", and adds up to a far from ideal user experience.

It's not how it work. As I mentioned the app works offline, it mean the app shell is stored locally, so when the user make a 2nd visit. The app shell is loaded from the cache, the SSR server is not requested. It work like a mobile app you installed on your device.

Which local database you use for web and mobile

[getlocaladmin]

I suggest checking out Solito https://solito.dev/.