12

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?

Improve this question
11
  • 12
    I'd argue this isn't necessarily a great thing, especially when JavaScript is the language in question.
    – Latty
    Oct 25, 2012 at 10:35
  • 4
    I must admit I have yet to reach the epiphany moment with JS and therefore haven't grasped why you would want to write server code with it, but that's another topic..
    – Makita
    Oct 25, 2012 at 10:37
  • 1
    Thanks for making your first post on Stack Exchange Programmers. For more information about maximizing the up votes and minimizing the down votes, read the FAQ. You may have been down voted because your question is more of a chat topic than something with a specific answer. It can take a while to get used to the format here. Short answers that are devoid of details are down voted. So are answers that debate a topic. There is some middle ground where a question or an answer is specific but universal enough and hits a topic with the right amount of detail.
    – DeveloperDon
    Oct 25, 2012 at 11:00
  • 1
    I would even argue against it. With using the same language for both server and client you run the risk of entanglement and language specific features in the communication.
    – Pieter B
    Oct 25, 2012 at 11:21
  • 3
    @Makita I think it is valid question, but people tend to get happy with downvotes when asking for examples. I removed certain parts of the original question and focused your question around why client/server language parity matters.
    – maple_shaft ♦
    Oct 25, 2012 at 11:22

3 Answers 3

Reset to default
5

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.

Improve this answer
14

Presumably the perceived benefit are:

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)

Improve this answer
6
  • 1
    It's a benefit if you're developing on your own, because there is no "mental" switch between server and client. If you want to do something and have a huge experience in JavaScript, you probably get better and faster results this way, but that's probably all...
    – K..
    Oct 25, 2012 at 11:06
  • Would you also say that there is no technical disadvantage, possibly an advantage in using a different language for every single subsystem?
    – Michael Borgwardt
    Oct 25, 2012 at 12:25
  • 1
    @MichaelBorgwardt assuming each language is a good fit for the subsystem I'd say yes, no technical disadvantage (maybe not much of an advantage either though) but there could be a big impact on the team dynamics and hiring. of course the majority of subsystems will be pretty easily implementable in any language so I wouldn't expect to see this extreme.
    – jk.
    Oct 25, 2012 at 12:47
  • The remark about this being a bad idea is unjustified. There's plenty of languages that can compile to JavaScript and a server-side language, including Lisp, which in fact is the language used in the SICP course praised by Joel's blog post.
    – back2dos
    Oct 25, 2012 at 15:22
  • @back2dos hopefully that clarifies it
    – jk.
    Oct 25, 2012 at 16:16
2

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 ;)

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.