I have been evaluating architecture solutions for a mobile project that will have a web-service/app in addition to native apps and have been looking at various libraries, frameworks, and stacks like Meteor, this being a sort of “open stack package framework”, is tightly bound with Node.js.
There is a lot of talk about the benefits of using the same language both client and server side, and I’m not getting it. I could understand if you want to mirror the entire state of a web application on both client and server but struggling to find other wins… Workflow efficiency?
I’m trying to understand why client/server language parity is considered to be a holy grail. Why does client/server language parity matter in software development?
11
On the PRO side:
- If schemas and code can be reused by both sides, there is a lot of efficiency in implementing similar logic and data just once.
On the CON side:
- The client may be primarily a view that is well suited for a mark up or script language, while the server may be primarily business logic that is better suited to a different language.
In web development, languages have proliferated, creating powerful tools for specific parts of the system as well as the need for many specialties to be learned by developers or teams of developers. In other areas like transaction processing or embedded systems that follow a systems of systems design approach, there may be savings from a common language.
New Javascript frameworks seem to come at us very fast, and some work is done to bundle APIs for the back end and tools for the front end. It might be smart to keep flexibility and separation of concerns between client and server side code so that you are free to float between them without being too stuck for too long with a particular tool.
Presumably the perceived benefit are:
- you only need to hire developers that know language x rather than x + y (this is probably not really a good idea though if they only know one language)
- it is easier to move developers between server and client development (this can be quite a good thing).
i.e. it makes resource management easier for project managers and has little or no technical benefit (possibly even negative technical benefit if you are hiring a bunch of one trick ponies)
6
The benefit is that you can reuse (to some extend) people’s expertise and code on both sides.
People
The developers need to master a single language and form a single pool. Rather than two pools of expertise. This makes it easier to transfer knowledge among them, and also to allow them switching their work between client and server side more easily. Lastly, it facilitates communication with team members of the “other side” when discussing technical issues because they share the same technical background.
Code
Sometimes it is useful to have some state on the client side, or algorithms, or both. Sometimes, the same is done on both sides. Let’s take the example of a multiplayer game:
you need to represent the game state on both client and server. Also, you need to implement the rules on client side (for responsiveness) and also on server side (to validate a player’s actions). Being able to reuse code for these things can be a great advantage. …in some other applications, you wouldn’t need this at all …it all depends on the case.
…of course there are also downsides, but that’s for another post 😉