[onestone]

I evaluated Next.js recently, and while it looks excellent on the surface, there were a couple of red flags:

- Devs insisting (incorrectly) that they _have_ to ship the component source code _inline_ in the server-rendered HTML. I commented on this issue here: https://github.com/zeit/next.js/issues/427#issuecomment-2908...

- The same transpiled code is used both server-side and client-side. Code which should be strictly server-only, e.g. getInitialProps(), is visible client-side as well.

[kbody]

I can only comment about `getInitialProps()`. Of course it's should be on client-side as well, that's the whole point of universal rendering. In combination with isomorphic-fetch you can use your (Rest) API and have nothing to change on the code. I think it's an excellent design decision to makes components actually independent and easily composable.

[onestone]

You are right about that, I admit.

Still, using the same transpiled code both client-side and server-side is suboptimal at least. E.g. if I target Node 7.x on the server, I don't need to transpile async functions for example (and screw stacktraces in the process).

[onestone]

Also, I might still want to do some things differently server-side in getInitialProps(), despite most of the code being shared. For example, clients might access the API through a load-balanced frontend, while on the server I might want to prefer talking to an API process on the same machine. Authentication might also be different. Of course these things (e.g. the API endpoint) shouldn't be hardcoded, but even then you need to get them somewhere, most likely a configuration file or an environment variable. And sharing these details (names of environment variables for example) with the client is not something I particularly like.

[Can_Not]

Instead of fetch, I'm using feathersjs that layers over axios and socketio.