I think next.js is overkill for several reasons and should not be adopted unless your team is either inexperienced or uncomfortable working with nodejs and babel:
1. crawl bots like Google (the primary target for apps that have a search engine/advertising/marketing need) are now equipped with JavaScript engines and can parse/render react.js SPAs
- if your initial render is fast enough there will be no difference end what an end user sees and what the crawl bot sees
- this includes an component that needs to execute a fetch on initial mount (
componentDidMount) - for components that do not fetch on initial mount and that render static content it's even more tolerant and better
2. next.js is very obtrusive in that it wants to dictate your directory structure (you should not be so deeply tied to a framework in this manner)
- see after.js the next.js alternative
- i prefer my components have as little knowledge as possible about their encompassing runtime environment (they'll inevitably need some context as some logic must be forked depending on if you're running in a browser or node.js environment but...yea)
- i like this approach because the majority of the component's value will be realized on the browser/client side since that's where it will primarliy be used (the less it knows about the alternative, server based environment the better since that's more of an edge case that's implemented to satisfy crawl bots)
- e.g. when persisting a user token it's best to use a cookie because they can be expressed easily on the server side
- localStorage however is purely browser based so does not map well to the server side (you have to do more faking/emulating as opposed to dealing with an intrinsic HTTP construct/concept)
3. the react.js team is *considering* making Server-Side Rendering (SSR) native to react which would further eliminate the need for a library or custom solution
4. it's quite easy to hand-roll a SSR solution yourself if you're familiar with express.js, babel, and optionally your bundler of choice (e.g. parcel - https://parceljs.org, webpack - https://webpack.js.org)
- if your apps are anything like ours then you have only a small subset of pages that have a real need for SSR (e.g. you need to inject Facebook Open Graph (OG tags) into the head section, you need to set your document's title based on the result of an API call on initial mount, or you have some other social media platform based metadata that needs to be injected into your head section)
- blogs and news sites need just about 100% of their content indexed and rightfully so so it's in their best interest to server render all the things
- do not base your decision solely on the fact that "a bunch of big other sites are doing this therefore we need to follow suit"
- that is a poor reason for taking on technical overhead/churn. make sure SSR is a real need for your team based on the nature of your application
6. it claims to *work* with redux but the examples I've seen inside the repo are contrived and virtually "hello world next.js redux"
- i prefer to learn from the community's experience with next.js and redux rather than trust that it all plays nicely together when it matters most
- integrations that are "open for interpretation" haven't always worked well for me in the past because you're unable to assert with a great deal of confidence that all your uses cases can be met/satisfied
- you could be in for a rude surprise at a later date once you discover that you can't perform some critical function in your code that's crucial to your success because next.js does not provide the proper hook or support (or your attempt at filling the void goes horribly wrong and exposes performance problems or introduces code that's buggy, hard to maintain, or difficult to reason about)
- i prefer a more consverative approach under these circumstances until the community as a whole proves that there's a standard more structured way of handling things like fetch/API requests on initial mount (the place most devs get tripped up the most when attempting to implement SSR universally in my experience)
7. Dan Abramov (the author of redux) has recommended next.js a few times on Twitter but the tweets are older and do not mention redux usage at all and appear to imply that the person raising the problem/question at hand needs most of their app server rendered (so I take these with a grain of salt)
8. even for a more forgiving library like after.js that targets SSR you end up having to override the default configuration which can be a a PITA or nontrivial
- when the default configuration doesn't satisfy my needs it makes me wonder why I used the library/framework to begin with
- immediately I have to go in and override things in a clumsy or inconvenient manner for the benefit of what the framework is attempting to provide overall
- if the bulk of the work I have to do is already primarily configuration based then I figure to take a stab at hand-rolling the remaining bits both from a learning and flexiblity perspective (the project could suddenly become either obselete, unmaintained, or even worse take a major shift in its overall direction like the Google guys did when going from Angular 1 to Angular 2/Angular...all apps had to be rewritten from the ground-up as there was no true upgrade path)
- with this in mind, it's always best to stay as close to what I like to call "true core" as possible and deviate or veer off course when a truly tangible benefit can be manifested/realized