¿Qué tan importante es usar el mismo idioma para el cliente y el servidor?

He estado evaluando soluciones de arquitectura para un proyecto móvil que tendrá un servicio / aplicación web además de aplicaciones nativas y he estado buscando en varias bibliotecas, marcos y pilas como Meteor , que es una especie de "marco de paquete de pila abierta" , está estrechamente ligado con Node.js .

Se habla mucho sobre los beneficios de usar el mismo idioma tanto del lado del cliente como del servidor, y no lo entiendo. Podría entender si desea reflejar todo el estado de una aplicación web tanto en el cliente como en el servidor pero luchando por encontrar otras victorias ... ¿Eficiencia del flujo de trabajo?

Estoy tratando de entender por qué la paridad del lenguaje cliente / servidor se considera un santo grial. ¿Por qué es importante la paridad del lenguaje cliente / servidor en el desarrollo de software?

En el lado PRO:

• Si los esquemas y el código pueden ser reutilizados por ambos lados, hay mucha eficiencia en la implementación de lógica y datos similares solo una vez.

En el lado CON:

• El cliente puede ser principalmente una vista que es adecuada para un lenguaje de marcado o script, mientras que el servidor puede ser principalmente una lógica de negocios que se adapta mejor a un idioma diferente.

En el desarrollo web, los idiomas han proliferado, creando herramientas poderosas para partes específicas del sistema, así como la necesidad de que los desarrolladores o equipos de desarrolladores aprendan muchas especialidades. En otras áreas, como el procesamiento de transacciones o los sistemas integrados que siguen un enfoque de diseño de sistemas, puede haber ahorros con un lenguaje común.

Parece que los nuevos marcos de Javascript nos llegan muy rápido, y se realiza un trabajo para agrupar las API para el back-end y las herramientas para el front-end. Puede ser inteligente mantener la flexibilidad y la separación de preocupaciones entre el código del lado del cliente y del servidor para que pueda flotar entre ellos sin estar demasiado atrapado durante demasiado tiempo con una herramienta en particular.

Presumiblemente los beneficios percibidos son:

• solo necesita contratar desarrolladores que conozcan el lenguaje x en lugar de x + y ( probablemente esta no sea una buena idea si solo conocen un idioma )
• es más fácil mover a los desarrolladores entre el desarrollo del servidor y del cliente (esto puede ser bastante bueno).

es decir, facilita la gestión de recursos para los gerentes de proyecto y tiene poco o ningún beneficio técnico (posiblemente incluso un beneficio técnico negativo si está contratando un grupo de ponis trucos)

El beneficio es que puede reutilizar (hasta cierto punto) la experiencia y el código de las personas en ambos lados.

Personas

Los desarrolladores necesitan dominar un solo idioma y formar un solo grupo. En lugar de dos grupos de experiencia. Esto facilita la transferencia de conocimiento entre ellos y también les permite cambiar su trabajo entre el lado del cliente y el servidor con mayor facilidad. Por último, facilita la comunicación con los miembros del equipo del "otro lado" cuando discuten cuestiones técnicas porque comparten la misma formación técnica.

Código

A veces es útil tener algún estado en el lado del cliente, o algoritmos, o ambos. A veces, lo mismo se hace en ambos lados. Tomemos el ejemplo de un juego multijugador: debe representar el estado del juego tanto en el cliente como en el servidor. Además, debe implementar las reglas en el lado del cliente (para la capacidad de respuesta) y también en el lado del servidor (para validar las acciones de un jugador). Poder reutilizar el código para estas cosas puede ser una gran ventaja. ... en algunas otras aplicaciones, no necesitarías esto en absoluto ... todo depende del caso.

... por supuesto, también hay inconvenientes, pero eso es para otra publicación;)