It's not mega tricky. But it does get a bit of getting used to. Such as remembering which lifecycle methods are called on where. Eg if you have things you only do on the client use componentDidMount you can also test for webpack's process.browser.
In short, you just have to think a little bit more about where your code is going to run.
Regarding blocking, agreed, rendering a react app to a string is hectic resource intensive, but you can use next as a handler in express and render to string and cache the result. Also, if you're using next as a renderer you can also do use node in whatever server you're running to spawn / fork processes if need be.
Node isnt the best at doing blocking tasks (rendering a massive template is blocking).
Not Next specific but a general "isomorphic" JavaScript is losing track of whether you're in the client or the server.
It's not mega tricky. But it does get a bit of getting used to. Such as remembering which lifecycle methods are called on where. Eg if you have things you only do on the client use
componentDidMountyou can also test for webpack'sprocess.browser.In short, you just have to think a little bit more about where your code is going to run.
Regarding blocking, agreed, rendering a react app to a string is hectic resource intensive, but you can use next as a handler in express and render to string and cache the result. Also, if you're using next as a renderer you can also do use node in whatever server you're running to spawn / fork processes if need be.
Yep the question was about the negatives, the fact that I only had 2 gripes is actually a sign of how well thought out Next is.
Yeah, it is pretty good for an "off the shelf" framework.