3 ms·

Sharing the utility libraries are a huge win though and should not be underestimated. For example on one project alone: - Input Validation - Asynchronous loo

Sharing the utility libraries are a huge win though and should not be underestimated. For example on one project alone: - Input Validation - Asynchronous loop patterns - Promise pattern implementations - markup logic & output - A* pathfinding More and more use cases will pop up over time, and it's really unique to the node.js environment. This alone would not make me pick node.js over another solution but I feel it is still an advantage. I spend about 50% of my dev time on writing / working with utility libraries as writing these libraries takes far more effort than writing handlers, models, etc.

technomancy 15y ago
Ian Bicking does a great job of debunking the many of the alleged advantages of code sharing: http://blog.ianbicking.org/2011/03/30/js-on-server-and-client-is-not-a-big-deal/ http://blog.ianbicking.org/2011/03/30/js-on-server-and-clien... Validation on the client is primarily a user experience concern, where you focus on bringing attention to problems with a form, and helping the user resolve those problems. Once the form is submitted, if you’ve done thorough client-side validation you can also avoid friendly server-side validation. Of course all your client-side validation could be avoided through a malicious client, but you don’t need to give a friendly error message in that case, you can simply bail out with a simple 400 Bad Request error. At that point there’s not much in common between these two kinds of validation — the client is all user experience, and the server is all data integrity.
- cloudhead 15y ago
  That's some nice theory, and it's obvious the author hasn't had much experience implementing real applications where sharing code is possible.
- jules 15y ago
  With the right abstractions the code for validating on the client and for validating on the server can be identical. For example take a look at Luna/Lunascript. This is not easy by just using Node, and it's not necessary that the language you use is Javascript. A better approach IMO is that you have a language X that is nicer than Javascript, and compiles both to server side code and client side Javascript. For the case of validation here is a hypothetical language (ignore the bad regex): <form action="/foo/bar"> <input type="text" name="email" /> <%= if not email ~ "[a-z]+@[a-z]+.[a-z]+": invalid("Email is not valid") %> <submit> </form> From this code you could generate real time JS validation and server side validation.

technomancy 15y ago

Ian Bicking does a great job of debunking the many of the alleged advantages of code sharing: http://blog.ianbicking.org/2011/03/30/js-on-server-and-client-is-not-a-big-deal/ http://blog.ianbicking.org/2011/03/30/js-on-server-and-clien... Validation on the client is primarily a user experience concern, where you focus on bringing attention to problems with a form, and helping the user resolve those problems. Once the form is submitted, if you’ve done thorough client-side validation you can also avoid friendly server-side validation. Of course all your client-side validation could be avoided through a malicious client, but you don’t need to give a friendly error message in that case, you can simply bail out with a simple 400 Bad Request error. At that point there’s not much in common between these two kinds of validation — the client is all user experience, and the server is all data integrity.

cloudhead 15y ago
That's some nice theory, and it's obvious the author hasn't had much experience implementing real applications where sharing code is possible.
jules 15y ago
With the right abstractions the code for validating on the client and for validating on the server can be identical. For example take a look at Luna/Lunascript. This is not easy by just using Node, and it's not necessary that the language you use is Javascript. A better approach IMO is that you have a language X that is nicer than Javascript, and compiles both to server side code and client side Javascript. For the case of validation here is a hypothetical language (ignore the bad regex): <form action="/foo/bar"> <input type="text" name="email" /> <%= if not email ~ "[a-z]+@[a-z]+.[a-z]+": invalid("Email is not valid") %> <submit> </form> From this code you could generate real time JS validation and server side validation.