In 2022, what's the simplest, non-opinionated way to turn a React landing page into a static site?
I'm a backend dev, so forgive me if this question is too stupid:
I have a React app that consists of a landing page with a few routes (signup, login, about, etc) + a dashboard for authenticated users (the bulk of the app). It's all bundled together, so it's quite slow to fetch. I use react-router to navigate between the different routes.
The landing page does not fetch any external data, so if I understand this right, I don't need SSR. What's the easiest way for me to split just the landing page into a separate, pre-rendered app?
The approach I'm tending towards is to first set up two different entrypoints via webpack, then use react-static to pre-render the landing page before deployment (the library is deprecated though).
If anyone knows a better solution, especially if it doesn't involve rewriting the app with an SSR framework, please let me know. Thanks!
Edit: Decided to go with Next.JS,next export turns out to do exactly what I want, with only a little rewrite needed for the routes. AstroJS looks promising too, though I'm too conservative to use a young framework on a real product.
As others have pointed out, the even better solution would have been to skip React altogether and just build a static website from the start. Webflow is also a good choice, though I'm not a fan of their pricing model.
If the landing page can be physically separated, you could have a separate project for the landing page.
Set it up behind a CDN like CloudFront and configure different origins. Depending on the URL path, route the request to a different origin.
So your landing page could be on /... which routes to the S3 bucket with the landing page.
And your dynamic app itself could be behind /app/... - or even on a subdomain. This would be routed to a different origin.
NextJS is a more fancy option, but takes a bit more effort getting set up.
You could try Astro.build
Nextjs is a bit heavy handed, but probably your best bet.
I'd say Next.js is your best bet. It's (currently) a clear market leader and it's so good I even use it for my entirely client-side applications (ex. my app's dashboard).
If you want a truly pure static webpage there's other options, but Next.js can do that functionality and more. It would take a small rewrite, yes, but I'd argue you can knock it out in a day, especially once you get the hang of using Next.js. No router code either, it's at the file system level, which is very clean imo.
Thanks, that's most likely what I'm going to do. The file system routing seems really intuitive, I never really liked React Router to be honest. Maybe I'll convert the dashboard to Next at some point too, though I have nested layouts in some pages, and it doesn't seem straight-forward to achieve that with Next
Yep! Actually nested layouts are coming out-of-the-box in the future as detailed in this RFC. But I agree – not intuitive atm. Here, I found an article that explains how to do nested layouts the way I do them. Hopefully that clears up how you can do nested layouts, took me a while to learn that myself.
When it comes to Frameworks that uses React I'm quite partial to Next.js. I've built my two latest products with that. However, if all you need is user auth for login etc and you are primarily concerned about speed I would use Astro.js, which allows you to bundle the needed JS only for the pages that actually use it, the rest would become completely static.
Another solution is to take the landing page out completely and have a static HTML page that just links to the login page etc. The landing page should be separate from the web app anyway IMO. I wouldn't use React to build a landing page in general. This all really depends on what sort of app you have and how you are dealing with the data.
Thanks for the suggestions. For this project, I think I'll go with Next.js since it's more mature, but Astro.js looks great, I might use it for my portfolio in the future.
I chose React so that I could share some components and theming from the main app, but realistically, the time I saved with that will be less than what I'll have spent researching+ converting it into a static page. Lesson learned!
I researched a little. This seems like the most optimal solution to me: https://vilvaathiban.medium.com/nextjs-convert-client-side-react-app-to-server-side-rendering-in-5-mins-2106ad69f5a5
Not a dig at you OP - I’m guilty of this as well (though getting better at not doing this), but interesting to see that building it static to start out wasn’t the default mindset. It’s telling how JS devs always view every project as a nail that React (or another framework) hammer will solve without actually planning the app architecture before coding. This kind of thing is so much more avoidable with proper planning.
Seems like the very same logic as using axios when the fetch API is more than capable of doing the job when the dev doesn’t even use whatever features of axios that make it worth including in a project.
Yeah, you're right about that. Part of the problem is that there's so much going on in frontend landscape, that people rush to use the latest tech just for fear of missing out or becoming less employable. It doesn't happen just on the frontend, but I feel like it's way worse there.
Not sure, but maybe try react on Github pages?
What you're describing is still SSR.
You'll either need a framework that knows how to run your React render server-side (Next.js is great for this).
Or if the site is really static, you can do a hacky & low-budget approach by running the page in an automated browser, let the client side React do its thing, and then capture the HTML. Here's a blog talking about that approach: https://medium.com/front-end-weekly/building-a-pre-renderer-for-spas-108f956f8b . Note that if you do this, none of the client side handlers (like "onClick") will work.
If SSR means that html is generated on each request, then no, because while I do have event handlers, the page doesn't need to fetch any data to populate the content. I only need to build it when I make changes to the source code, afterwards it looks same for everyone.
Based on other peoples' answer, I'll probably use Next, their
next exportfeature does kinda of what you're saying, while keeping the page functional