3 ms·

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

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-290882395 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 9y ago
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 9y ago
  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 9y ago
    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 9y ago
  Instead of fetch, I'm using feathersjs that layers over axios and socketio.

kbody 9y ago

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 9y ago
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 9y ago
  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 9y ago
Instead of fetch, I'm using feathersjs that layers over axios and socketio.