rendertron VS prerender

Rendertron, quite old now.

Googlebot: SSR a non-responsive mobile version only for the Googlebot User Agent, to get SEO. But do Client-Side Rendering (CSR) for users, to get full responsivity. Could be done with manual user-agent sniffing, or with a GoogleChrome/Rendertron proxy. Though Google may not like being fed something different than users (different initial markup, even though resulting markup after React’s first CSR should be the same). But it might be problematic long-term to SSR only for the Googlebot, since it’s effectively serving the Googlebot something else than what the users get.. Google might crack down on it, since it could be abused.

This might be another one: https://github.com/GoogleChrome/rendertron (not sure if it does everything that prerender does or not).

Still prefer CRA with Dynamic Rendering with rendertron over Next.js and Gatsby...

A demo Rendertron service is available at https://render-tron.appspot.com/. It is not designed to be used as a production endpoint. You can use it, but there are no uptime guarantees.

View on GitHub

I don't know where are you getting "... cannot be changed in the future", it seems you might be asking that on some fanboy forums on a particular stack. Of course you can change anything once you build a project with Livewire, i've built projects with both stacks and used more Livewire because I write less code and my apps are less complex than building it with Inertia.js(vue). First, Livewire has the advantage that it works 100% with SEO, no problems there at all, as it is server side rendered, with Inertia.js you have to make one extra step, don't just listen to people who dismiss it as "oh yeah that is solved easily", JS frameworks DO have a problem with SEO, just go to any SPA built with any JS frameworks and view-source it. The inertia.js documentation states it clearly you can "solve" that problem by using one of Prerender.io, Prerender.cloud or Rendertron.

Google provides rendertron to achieve Dynamic Rendering. And there's a deployment configuration of Google App Engine (GAE) in the repository, so you can deploy it easily to GAE.

Ah, I didn't realize this wasn't solved -- a quick search turns up:

- https://github.com/WICG/webcomponents/issues/788

- https://github.com/w3c/DOM-Parsing/issues/58

- https://github.com/w3ctag/design-reviews/issues/494

- https://web.dev/declarative-shadow-dom

In pre-render they seem to have started in this direction extremely recently:

https://github.com/prerender/prerender/pull/731/files

I don't use prerender so I can't definitively speak to it being solved and hiccup-free, but I think that limitation is going to go away in the future.

it's not quite impossible, there are some more "out there" server-side rendering approaches which would work:

- https://github.com/airbnb/hypernova

- https://github.com/prerender/prerender

Fans of efficiency and simplicity might recoil but if it works and is easy to setup, these far out approaches might just catch.

Using something like: https://github.com/prerender/prerender

Have you used prerender - https://github.com/prerender/prerender ? Seems to be doing the same thing.

I've used both Next.js + Nuxt (for Vue)... but personally found that SSR adds in extra complexity and odd edge cases here and there (especially when adding in 3rd party components that might not have been tested as well with SSR)... and I've decided to go down the "dynamic rendering" path instead with: https://github.com/prerender/prerender

The easiest way without rewriting your app would be to pipe those routes into a prerender service (either a commercial one or selfhost one). Talking about something like prerender

I just used the OSS self-hosted version: https://github.com/prerender/prerender - not really interesting in paying for their service personally.