3 ms·
There's other reasons to like node besides the non-blocking IO. For me, its being able to reuse code on the client and the server. Not sure why the node basher
by kylebrown 15y ago
There's other reasons to like node besides the non-blocking IO. For me, its being able to reuse code on the client and the server. Not sure why the node bashers seem to overlook that one.
- the-cakeboss 15y agoSerious question: What might you want to reuse on the client side?
- kylebrown 15y agoThe model. For example, including a backbone.js collection/model definition in the server-side node environment and serving the same model code to the client. The controller-y stuff will be different on each: on the node server the model is persisted by overwriting backbone.sync backbone-redis, and the client could choose to do local caching by extending the sync function with a localstorage plug-in. For the client-server communication, by default backbone.sync on the client uses restful cruddy urls (for rails), which would need to be handled in a node.js router. There's a lot of boilerplate-type stuff out there to help handle routing those urls, building on e.g. express.js. It seems to be more straightforward on rails which already established conventions. That's probably why a lot of the backbone/node demos and tutorials forego the restful server interface. Its simpler to just do client-server communication using a real-time pipe like socket.io (which itself is shared code on the server the client). not restful but comes with an added wow factor.