Hello Andrea,
I tried to do the same thing but just felt I shouldn't use next.js if I don't let it handle the routing and SSR things. How do you think about it? Could you still feel any benefits of using next.js after doing this?
In my own experience in a large entreprise express app, sometimes you cannot afford to migrate your app to next all at once, but you still need to ssr some pages. The solution might not seem sexy, but it can be a path in the scenario
This was our case as well, except multiple apps owned by different teams. The fact that you can use react-router inside a Next app means one less hurdle to overcome, which makes it easier to get buy-in from each team.
Getting more pages together in the same app makes it so much more productive to share code across pages 😁
Given the sour reaction I had from one of next.js maintainers for documenting this approach, I would definitely suggest to use next.js only the way they want it to be used.
I wouldn't spend anymore time to provide feedbacks to the project.
What do you mean "a sour reaction" ? That's seem to be pretty intense reaction for a simple blog post. I guess that we are all free as engineers to share approach and ideas. If an approach is not efficient enough, or whatever disagreement it can be, we should stay no matter what respectful and answer only based on facts. anyway keep up the good work.
Zeit's business model is in hosting Next.js sites, so it's in their best interest to reduce the customization they allow to end users. Tons of people would rather use react-router (just see the github issues), and it's entirely possible to preserve all the other next features in doing so. But supporting such a different way of routing would mean way more headaches for their business than they seem to think is worth it. I don't blame them, but I also prefer "toolkit"-style libraries over opinionated monoliths, so I'm trying to move away from Next after a brief experiment while react-static was on hiatus.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hello Andrea,
I tried to do the same thing but just felt I shouldn't use next.js if I don't let it handle the routing and SSR things. How do you think about it? Could you still feel any benefits of using next.js after doing this?
In my own experience in a large entreprise express app, sometimes you cannot afford to migrate your app to next all at once, but you still need to ssr some pages. The solution might not seem sexy, but it can be a path in the scenario
This was our case as well, except multiple apps owned by different teams. The fact that you can use react-router inside a Next app means one less hurdle to overcome, which makes it easier to get buy-in from each team.
Getting more pages together in the same app makes it so much more productive to share code across pages 😁
That was exactly my case.
Given the sour reaction I had from one of
next.jsmaintainers for documenting this approach, I would definitely suggest to usenext.jsonly the way they want it to be used.I wouldn't spend anymore time to provide feedbacks to the project.
What do you mean "a sour reaction" ? That's seem to be pretty intense reaction for a simple blog post. I guess that we are all free as engineers to share approach and ideas. If an approach is not efficient enough, or whatever disagreement it can be, we should stay no matter what respectful and answer only based on facts. anyway keep up the good work.
Zeit's business model is in hosting Next.js sites, so it's in their best interest to reduce the customization they allow to end users. Tons of people would rather use react-router (just see the github issues), and it's entirely possible to preserve all the other next features in doing so. But supporting such a different way of routing would mean way more headaches for their business than they seem to think is worth it. I don't blame them, but I also prefer "toolkit"-style libraries over opinionated monoliths, so I'm trying to move away from Next after a brief experiment while react-static was on hiatus.