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?

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
Makita
  • 239
  • 1
  • 5
  • 12
    I'd argue this isn't necessarily a great thing, especially when JavaScript is the language in question. – Latty Oct 25 '12 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 '12 at 10:37
  • Ok whoever wants to downvote please let me know why. Is this is stupid question? Not suitable for programmers.stackexchange? – Makita Oct 25 '12 at 10:49
  • 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 '12 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 '12 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 '12 at 11:22
  • 1
    Can you explain more why you think this is a "holy grail"? Are there web sites or books that have led you to believe this? In my experience this isn't a commonly held belief. – Bryan Oakley Oct 25 '12 at 14:00
  • @BryanOakley as maple_shaft has identified, this topic usually comes up in the context of node.js discussion. There are other stated features/benefits of node.js, but client/server language parity is the one I have trouble with. – Makita Oct 25 '12 at 14:16
  • It is not *important*. It is practical. I mostly use [Haxe](http://haxe.org) for my day to day development. The most appealing part is IMHO, that [RPC becomes transparent](http://haxe.org/doc/remoting/0_introduction). – back2dos Oct 25 '12 at 15:27
  • Javascript running on the server side ? It would be a grim world. – Tulains Córdova Oct 25 '12 at 18:56
  • I just wanted to say thank you to the posters and to the editors. I appreciate the insights on the original topic and also (thanks to the edits) tips on how to better frame future questions. – Makita Oct 26 '12 at 06:41

3 Answers3

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)

jk.
  • 10,216
  • 1
  • 33
  • 43
  • 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 '12 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 '12 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 '12 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](http://clojure.org/), which in fact is the language used in the SICP course praised by Joel's blog post. – back2dos Oct 25 '12 at 15:22
  • @back2dos hopefully that clarifies it – jk. Oct 25 '12 at 16:16
  • While it can be argued that knowing only one language can hamper one's growth as a developer and while I tend to agree, I do not think that is the point that "The Perils of JavaSchools" makes. – back2dos Oct 25 '12 at 16:53
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.

DeveloperDon
  • 4,958
  • 1
  • 26
  • 53
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 ;)

dagnelies
  • 5,415
  • 3
  • 20
  • 26