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
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.