-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use Next.js for static exports? #393
Comments
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 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): The majority of our stack will work with nextjs, demonstrated here. The stuff in 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. |
Context
We have a few issues related to the challenges associated with Remix static exports:
.html
for static html (based on config) mystmd#950We 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
The text was updated successfully, but these errors were encountered: