This might be a really bad question that is just as applicable to Node.js in general, but doesn't this get confusing distinguishing between the server-side and client-side aspects?
back
2 comments
Not really. Compared to using separate languages on the server and client, I feel that using the same language makes it a bit easier because I don't need to switch "mode" when jumping back and forth in the code. Like, when working on iOS apps, I sometimes write `self` instead of `this`.
I have sometime seen the argument for Node of using the same code on client and backend simultaneously, but in practice I haven't found any use for that. The only big thing I can think of is form/model validation, but if you do ajax, you can just as well do all that on the server anyway.
Isomorphic apps. I've been playing around with React+Flux, and it's perfect. You can write your API in any language you want (even keeping it as part of node if you wish!), but the client is React. This means you can re-use almost exactly the same code for the frontend and backend. You get server-side rendering that delegates to the client once it has loaded.
I recently re-wrote my blog (https://blog.cesarandreu.com/) to take this approach. Repo: https://github.com/cesarandreu/trois-blog
The client bootstrap code that's used on the server is in client/middleware.js. Aside from that it reuses the exact same code.
I could see that with node-cgi if you're mixing html+server side+client side in a single file.. that would be confusing.
In practice though (and if you're using the nodejs), you would have better organization... for ex, all of your nodejs code for in a directory, and then a directory with your templates (which is also where the inline client side js would go). Making it much easier to think about them separately.