You can still use NextJS - just get it to prerender the entire site statically. Then you get the plus sides of using NextJS, but can take your static ZIP file of files to any host you like, or self host.
You then get, for example, an HTML file, with all the elements ready on page load, which can be 'rehydrated' when React kicks in for deep functionality and interactivity.
I have a netxjs based discussion forum in development. Is it as straightforward as issuing a command to pre-render and then the site re-hydrates via Apollo on it's own ?
Say you have a useEffect that calls an API: maybe firebase or parse. That useEffect only gets run on the client. For the server side render: it runs the react code based on the initial props and takes that first rendering and creates the static html from that. When that static html is run on the browser it will run react and subsequent renders can update the dom.
Yes this only works when you use JS to implement anything dynamic, user specific, requiring up to date (up to the second) data and so on. You can keep the static content fairly up to date.
For HN for example, you could prerender much of the content including latest
comments and get Next to keep it up to date, cache invalidating as necessary. Basically have it rebuild static pages as posts are made. Then use fetch calls or maybe sockets to get the very latest posts and keep it up to date, even live updates if you wish.
It is a bit like a mirror of what HN does. HN will use caching so that if you are logged out you get fast renders of pages. Instead of caching, you are pregenerating and keeping it up to date.
You can still use NextJS - just get it to prerender the entire site statically. Then you get the plus sides of using NextJS, but can take your static ZIP file of files to any host you like, or self host.
You then get, for example, an HTML file, with all the elements ready on page load, which can be 'rehydrated' when React kicks in for deep functionality and interactivity.