Use Next.js for static exports?

[agoose77]

Context

We have a few issues related to the challenges associated with Remix static exports:

• Light / dark mode does not persist between pages in static export #319
• Rewrite internal links to include .html for static html (based on config) mystmd#950
• Remix v1.18.0 causes infinite reload for static pages #184

We would like to upgrade to the latest Remix, but I'm aware that there may be some challenges there (@rowanc1 investigated recently).

Proposal

I've been following the classic pattern of "choose one solution and make it work for all use cases". Perhaps we need to be more open-minded, and use two tools; one for "dynamic" sites that run on e.g. Vercel, and one for "static" sites that export to RTD / GH Pages.

From a cursory read of the docs, it seems that Next.js at least references static exports (right now, (I think this changes in the new version) Remix doesn't natively support it; we use curl!

There are challenges associated with using two frontends, mainly code-sharing. An optimistic way to look at this is that it might make our themes less Remix-specific, which benefits downstream users.

Tasks and updates

No response

[rowanc1]

We have talked about this a little bit in person. It is encouraging to see @agoose77's efforts on an upgrade to Remix, which will get us SPAs that is a significant upgrade if we can get there. I think that nextjs is going to have the same issues as remix (certainly the link appending .html in CircleCI/RTD). We can also look into how docusaurus works and take over the internals potentially.

Agreeing with one of the Remix devs here (Curl/wget is the original SSG, and the fact that it isn't magical is the point):
https://twitter.com/mjackson/status/1585796053625774080

The majority of our stack will work with nextjs, demonstrated here. The stuff in @myst-theme/site is somewhat dependent on remix, and we can refactor continually to move components "down" to be more useful as general react components.

There is going to be a significant dev effort to both bringing on a new framework and supporting it, which IMO should be considered with a lot of caution based on the overhead for the myst team. Agree that it is sub-optimal at the moment, hopefully prioritizing the fixes gets us most of the way. And hoping that the SPA upgrades to remix actually take us even further.

That being said, there is also the ability to have lots of themes in MyST, including static-first themes that are Jinja-based and also not even in node. We just need something that can dynamically create HTML. It might be interesting to demonstrate how to do that in a python server, and/or integrating to the existing pydata themes. That being said, the react stuff is where all of the novel/new stuff is, and so having a react-first framework makes a lot of sense.