What I was trying to (clumsily) say is that when people develop "isomorphic" code they tend to forget that some of it runs on the client and some of it runs on the server and the interface between the two cannot be trusted.

Form validation is a common example of where things can break, like someone injects malicious data that's already been validated by the client-side code and then the server assumes that the code has already been validated by the client.

And if you don't even know which code is running where, that makes it even more dangerous.

Hmm I guess since it's advice to young developers they might make that mistake but any slightly experienced developer knows not to trust anything client side. Not validating data from the client isn't exclusive to isomorphic code.

Think of transpilers like GWT, where you write java that's converted to in-browser Javascript; or the current trend of server-side Javascript.

(For what it's worth, both are really really cool technologies!)

Edit: But I also suspect this relates to a temptation to write browser-side Javascript without thinking about the server-side or database; IE, browser-side Javascript that just loads objects willy-nilly via fetch / AJAX and creating lots of round trips.

Guessing he means when the code shared does important things like validation.

Maybe they are thinking of services like firebase where much of the traditional server logic is now handled in the same js libraries that the frontend uses? But I'm also not sure what exactly the author is referring to.

meteor