Quelle est l'importance d'utiliser la même langue pour le client et le serveur?

J'ai évalué des solutions d'architecture pour un projet mobile qui aura un service / application Web en plus des applications natives et j'ai examiné diverses bibliothèques, frameworks et piles comme Meteor , ce qui est une sorte de "framework de package de pile ouverte". , est étroitement lié avec Node.js .

Il y a beaucoup de discussions sur les avantages d'utiliser le même langage côté client et côté serveur, et je ne comprends pas. Je pourrais comprendre si vous voulez refléter l'état entier d'une application Web à la fois sur le client et le serveur, mais que vous avez du mal à trouver d'autres gains ... Efficacité du flux de travail?

J'essaie de comprendre pourquoi la parité linguistique client / serveur est considérée comme un Saint Graal. Pourquoi la parité de langage client / serveur est-elle importante dans le développement logiciel?

web-applications server-side client-side

— Makita
source

Je dirais que ce n'est pas nécessairement une bonne chose, surtout lorsque JavaScript est le langage en question.

— Latty

Je dois admettre que je n'ai pas encore atteint le moment épiphanie avec JS et que je n'ai donc pas compris pourquoi vous voudriez écrire du code serveur avec, mais c'est un autre sujet ..

— Makita

Merci d'avoir rédigé votre premier message sur Stack Exchange Programmers. Pour plus d'informations sur la maximisation des votes positifs et la réduction des votes négatifs, lisez la FAQ. Votre vote a peut-être été rejeté, car votre question relève davantage d'un sujet de discussion que d'une réponse spécifique. Cela peut prendre un certain temps pour s'habituer au format ici. Les réponses brèves sans détails sont rejetées. Il en va de même des réponses qui débattent d'un sujet. Il existe un terrain d'entente où une question ou une réponse est spécifique mais assez universelle et touche un sujet avec la bonne quantité de détails.

— DeveloperDon

Je m'y opposerais même. En utilisant la même langue à la fois pour le serveur et le client, vous courez le risque d'enchevêtrement et de fonctionnalités spécifiques à la langue dans la communication.

— Pieter B

@Makita Je pense que c'est une question valable, mais les gens ont tendance à être satisfaits des votes négatifs lorsqu'ils demandent des exemples. J'ai supprimé certaines parties de la question d'origine et concentré votre question sur l'importance de la parité de langue client / serveur.

— maple_shaft

Réponses:

Côté PRO:

Si les schémas et le code peuvent être réutilisés des deux côtés, il y a beaucoup d'efficacité à implémenter une logique et des données similaires une seule fois.

Côté CON:

Le client peut être principalement une vue bien adaptée à un langage de balisage ou de script, tandis que le serveur peut être principalement une logique métier mieux adaptée à un autre langage.

Dans le développement Web, les langages ont proliféré, créant des outils puissants pour des parties spécifiques du système ainsi que le besoin de nombreuses spécialités à apprendre par les développeurs ou les équipes de développeurs. Dans d'autres domaines comme le traitement des transactions ou les systèmes embarqués qui suivent une approche de conception de systèmes de systèmes, il peut y avoir des économies grâce à un langage commun.

Les nouveaux frameworks Javascript semblent arriver très rapidement, et un certain travail est fait pour regrouper les API pour le back-end et les outils pour le front-end. Il peut être judicieux de conserver la flexibilité et la séparation des problèmes entre le code côté client et le côté serveur afin que vous soyez libre de flotter entre eux sans être trop coincé trop longtemps avec un outil particulier.

— DeveloperDon
source

On présume que les avantages perçus sont:

vous n'avez qu'à embaucher des développeurs qui connaissent la langue x plutôt que x + y ( ce n'est probablement pas vraiment une bonne idée si ils ne connaissent qu'une seule langue )
il est plus facile de déplacer les développeurs entre le développement serveur et client (cela peut être une bonne chose).

c'est-à-dire qu'il facilite la gestion des ressources pour les chefs de projet et a peu ou pas d'avantages techniques (peut-être même un avantage technique négatif si vous embauchez un tas de poneys astucieux)

— jk.
source

C'est un avantage si vous développez vous-même, car il n'y a pas de basculement "mental" entre serveur et client. Si vous voulez faire quelque chose et avoir une énorme expérience en JavaScript, vous obtenez probablement des résultats meilleurs et plus rapides de cette façon, mais c'est probablement tout ...

— K ..

Diriez-vous également qu'il n'y a aucun inconvénient technique, peut-être un avantage à utiliser une langue différente pour chaque sous-système?

— Michael Borgwardt

@MichaelBorgwardt en supposant que chaque langue correspond bien au sous-système, je dirais que oui, pas de désavantage technique (peut-être pas beaucoup d'avantage non plus), mais cela pourrait avoir un impact important sur la dynamique de l'équipe et l'embauche. bien sûr, la majorité des sous-systèmes seront assez facilement implémentables dans n'importe quelle langue, donc je ne m'attendrais pas à voir cet extrême.

— jk.

La remarque selon laquelle il s'agit d'une mauvaise idée est injustifiée. Il existe de nombreuses langues pouvant être compilées en JavaScript et une langue côté serveur, y compris Lisp , qui est en fait la langue utilisée dans le cours SICP saluée par le blog de Joel.

— back2dos

@ back2dos j'espère que cela clarifie les choses

— jk.

L'avantage est que vous pouvez réutiliser (dans une certaine mesure) l'expertise et le code des utilisateurs des deux côtés.

Personnes

Les développeurs doivent maîtriser une seule langue et former un seul pool. Plutôt que deux bassins d'expertise. Cela facilite le transfert de connaissances entre eux et leur permet également de basculer plus facilement leur travail entre le client et le serveur. Enfin, il facilite la communication avec les membres de l'équipe de «l'autre côté» lors de discussions sur des questions techniques car ils partagent le même bagage technique.

Code

Parfois, il est utile d'avoir un état côté client, ou des algorithmes, ou les deux. Parfois, la même chose se fait des deux côtés. Prenons l'exemple d'un jeu multijoueur: vous devez représenter l'état du jeu sur le client et le serveur. De plus, vous devez implémenter les règles côté client (pour la réactivité) et également côté serveur (pour valider les actions d'un joueur). Pouvoir réutiliser du code pour ces choses peut être un grand avantage. ... dans certaines autres applications, vous n'en aurez pas du tout besoin ... tout dépend du cas.

... bien sûr, il y a aussi des inconvénients, mais c'est pour un autre post;)

— dagnelies
source