4 ms·
>Using the same language at both the client and server end has some serious benefits. The functionality implemented is mutually exclusive. This canard needs to
by alnayyir 15y ago
>Using the same language at both the client and server end has some serious benefits.
The functionality implemented is mutually exclusive. This canard needs to die.
- akdubya 15y agoI'm working on a distributed app that shares code between the client and server, and there are already a multitude of open-source libraries that are designed to run in any JS environment.
- jessedhillon 15y agoThat doesn't mean it's useful to do so, or that there are significant advantages to be gained from doing so.
- alnayyir 15y agoThis. Also I appreciate you picking up where I left off, I've been making a major lifestyle change and am almost completely sapped of energy. This has improved my concision considerably wrt code and conversation. Cheers, let me know if you find yourself in SF, I'll get you a round on me.
- deleted 15y ago[deleted]
- ricardobeat 15y agoLike, say, sharing hashing functions, templating, encoding or math libraries? Not useful at all.
- jessedhillon 15y agoActually yeah, that doesn't sound very useful. Math (significant math), encoding and hashing being done on the client sounds like a poorly designed application. Same for templating on the server -- which I assume you mean manually compiling templates using a library, and sending the result to a client, perhaps as a property of a JSON object.
- moe 15y agoThe functionality implemented is mutually exclusive Sorry, but what is that supposed to mean? The functionality on either end of a client/server application is usually not "mutually exclusive". They're two sides of the same coin and could indeed benefit tremendously from code sharing. Just because the potential has barely been realized so far doesn't mean it doesn't exist.