I think you might miss both the point of sharing code and the way to go about it. Of course you don't have one single, massive Node project.
First, why. To your point about DRY but with design decisions instead of lines of code, that's how software development has always been; that's what the Gang of Four is. Isomorphic JavaScript allows you to literally not repeat yourself. You write code to solve a problem and you never need to worry about that problem again. Building a system that has every problem solved (at least) twice in (at least) two different languages is what makes architecture harder to understand, and more importantly maintain.
Ok, how. You create lots of little modules that each do one thing well. They declare their dependencies on your other modules, so it's actually much harder to introduce coupling between components. You use the modules appropriate to whichever part of the system you're building.
A practical example: you want to validate user input. You have a series of business rules that must be checked before you allow an update. Of course you want to check them on the client, so you can provide valuable feedback as quickly as possible. But you also must check them on the server, to prevent a wily user from circumventing your rules.
How do you architect this system? If you're sharing code, you just write a function to check the rules and call it in both places. If you're not, you end up reimplementing the rule in both places. But of course you'd like to at least share the rule definitions, so you end up writing the rules in JSON or something and then building parallel rule loaders in both places. Or if you're me you just give up and use Node instead.
Isomorphic JavaScript allows you to literally not repeat yourself. You write code to solve a problem and you never need to worry about that problem again.
If only that were true, but that's where my doubts are. You write:
If you're sharing code, you just write a function to check the rules and call it in both places.
But you can only use that function if you can use Node on your front end. Most fronts today (native iOS apps, etc.) won't be able to reuse that function, and you'll have to reimplement it anyway.
I would only go with Node if I absolutely knew that incompatible front end won't be required for the project in foreseeable future—but I'd need to be a CTO to decide on that. Besides, what about when browsers get an additional runtime, with better tools than JavaScript? (Okay though, this one may not count as ‘foreseeable future’.)
I'd rather reimplement the function every time if I know I may need to reimplement it an unknown number of times. Perhaps in that case I'd try coming up with some language-agnostic specs instead so that validation function can be reimplemented on other platforms without breaking UX consistency.
Comments
I think you might miss both the point of sharing code and the way to go about it. Of course you don't have one single, massive Node project.
First, why. To your point about DRY but with design decisions instead of lines of code, that's how software development has always been; that's what the Gang of Four is. Isomorphic JavaScript allows you to literally not repeat yourself. You write code to solve a problem and you never need to worry about that problem again. Building a system that has every problem solved (at least) twice in (at least) two different languages is what makes architecture harder to understand, and more importantly maintain.
Ok, how. You create lots of little modules that each do one thing well. They declare their dependencies on your other modules, so it's actually much harder to introduce coupling between components. You use the modules appropriate to whichever part of the system you're building.
A practical example: you want to validate user input. You have a series of business rules that must be checked before you allow an update. Of course you want to check them on the client, so you can provide valuable feedback as quickly as possible. But you also must check them on the server, to prevent a wily user from circumventing your rules.
How do you architect this system? If you're sharing code, you just write a function to check the rules and call it in both places. If you're not, you end up reimplementing the rule in both places. But of course you'd like to at least share the rule definitions, so you end up writing the rules in JSON or something and then building parallel rule loaders in both places. Or if you're me you just give up and use Node instead.
If only that were true, but that's where my doubts are. You write:
But you can only use that function if you can use Node on your front end. Most fronts today (native iOS apps, etc.) won't be able to reuse that function, and you'll have to reimplement it anyway.
I would only go with Node if I absolutely knew that incompatible front end won't be required for the project in foreseeable future—but I'd need to be a CTO to decide on that. Besides, what about when browsers get an additional runtime, with better tools than JavaScript? (Okay though, this one may not count as ‘foreseeable future’.)
I'd rather reimplement the function every time if I know I may need to reimplement it an unknown number of times. Perhaps in that case I'd try coming up with some language-agnostic specs instead so that validation function can be reimplemented on other platforms without breaking UX consistency.