¿Por qué los sitios web grandes usan diferentes idiomas para el backend y el frontend?

Según entiendo, las pequeñas aplicaciones MVC es que tiene el front-end, que trata con HTML, JS, jQuery, etc., y tiene el back-end, que consiste en sus controladores y modelos.

Sin embargo, cuando hablo con desarrolladores de grandes empresas, a menudo mencionan tener un nivel de interfaz y un nivel de fondo. Entonces, a veces, podría escuchar que tienen una interfaz con C # y un back-end con Java. ¿Por qué una empresa querría un backend y frontend en diferentes idiomas? ¿Ayuda esto a que el sitio web grande escale mejor?

Cuando la gente dice que su interfaz está construida en C #, ¿significa esto que están usando un marco para la interfaz (como .NET) y un marco adicional en el back-end (como Spring)? ¿O significa algo completamente diferente?

"Front-end" y "Back-end" pueden ser términos nebulosos, particularmente en aplicaciones empresariales. "Front-end" puede significar la interfaz de usuario, o puede ser la aplicación completa. "Back-end" puede usarse para referirse a lo interno, o podría ser la base de datos o los servicios externos que se consumen. El significado de los términos a menudo depende completamente de con quién está hablando. Entonces, ¿quizás preguntaste "oye, qué quieres decir con eso?"

Cuando ingrese al desarrollo de grandes empresas, tendrá muchos equipos escribiendo mucho código. Estos equipos se desarrollarán en diferentes idiomas, utilizando diferentes paradigmas, desde diferentes ubicaciones. Parte de este código deberá funcionar en conjunto y gran parte de él no.

Yo trabajo para un gran banco. Mi equipo desarrolla nuestra aplicación en C #. Todo ello. Pero consumimos servicios web que están escritos en gran medida en Java, y esos servicios se comunican con otros servicios que se comunican con otros servicios que obtienen los datos de la cuenta desde y hacia los almacenes de datos apropiados, y quién sabe qué idiomas se usan con ellos.

Versión corta: las personas usan las herramientas que hacen el trabajo.

Creo que necesita ampliar un poco la pregunta: ¿por qué los grandes proyectos de software utilizan más de un lenguaje de programación?

Hay muchas respuestas posibles, las más notables son:

• Las aplicaciones grandes consisten en muchas partes relativamente independientes; a menudo, cada parte es construida por un equipo diferente o incluso un contratista externo diferente. El beneficio de ir con la mejor oferta suele ser mayor que el beneficio de tener todo en el mismo idioma.
• Los idiomas van y vienen, y a veces un componente de un gran sistema sobrevive al ecosistema. Un ejemplo del mundo de Microsoft es cuántas empresas ahora usan C # para todos los proyectos nuevos, pero todavía tienen una base de código VB considerable. El costo de reescribir un proyecto solo por hacerlo en el último lenguaje de programación prácticamente nunca se justifica.
• Interfaz con componentes de terceros. Si su ecosistema C # necesita realizar una tarea específica para la que solo existen soluciones Java, entonces tiene dos opciones: implementar la solución usted mismo, o usar la solución Java y desarrollar un poco de pegamento para integrarla en su sistema. Este último es casi siempre más barato para cualquier tarea no trivial.

Las consideraciones de rendimiento prácticamente nunca son la razón, excepto en aplicaciones extremadamente críticas para el rendimiento, como el comercio de alta frecuencia; en esas áreas, puede ser beneficioso escribir el motor central crítico en un lenguaje con un mejor rendimiento en tiempo de ejecución (por ejemplo, C ++), pero los sistemas de soporte (UI, informes, etc.) en algo de nivel superior como Java o C #.

Es relativo en una gran empresa.
En mi compañía, la pila es aproximadamente

(html/javascript)--> (JSP on Tomcat and Java based WebCMS) -> (.Net SOA)  

Entonces, para el equipo de desarrollo web, el frontend es HTML / JS y el backend es Java. Para la empresa, el frontend es Java y el backend es .Net.

De hecho, la capa .Net tiene que funcionar con una aplicación COBOL / UNIX para Facturación y Reclamaciones y, por lo tanto, en esta perspectiva .Net es frontend y COBOL es backend.

Y sí, como otros han mencionado, tenemos equipos de diseñadores UX, desarrolladores HTML / JS, desarrolladores Java, Web Middleware, desarrolladores .Net, desarrolladores SQL, desarrolladores COBOL que trabajan en cada porción de la pila.

De hecho, en cualquier empresa suficientemente grande se trata de tortugas hasta el fondo.

Semántica confusa

Es un problema de semántica. Cuando alguien dice que es un desarrollador front-end o Java front end, generalmente está hablando de la persona que sabe mucho sobre los lenguajes de plantillas y quizás marcos que nunca deberían usarse nunca más como los formularios web que se usaron para tratar de ocultar el tirar cosas sobre un muro http (es decir, "desarrollo web") por parte de desarrolladores de aplicaciones que no quisieron o al menos se supuso que no querían aprender sobre toda esa basura. En el caso de .NET y Java mixtos, no estoy seguro, pero solo podría suponer que, en el sentido MVC de las cosas, tienen a Java actuando para todas las cosas del modelo de negocio y .NET manejando todo lo demás que se describiría mejor como "nivel medio" pero sigue siendo todo del lado del servidor.

La separación real es lo que sucede en el servidor y lo que sucede en el cliente o el navegador. Puede combinar fácilmente la creación del HTML que se enviará o la representación del front-end con "desarrollo de front-end", por lo que prefiero evitar confusiones utilizando los términos cliente y servidor en lugar de front y back-end cuando analice lo que normalmente hago, (generalmente trabajo del lado del cliente).

Idiomas del lado del cliente

La razón por la que usamos el mismo conjunto de idiomas en el navegador es porque el navegador está en el extremo receptor y, en su mayor parte (ha habido una resistencia mayoritaria de Microsoft y Adobe en esto), nadie quiere enviar tres diferentes versiones del mismo lado del cliente para satisfacer a cada cliente potencial o requerir que se instale un complemento propietario para que la web funcione. Además, los tres idiomas realmente encapsulan las preocupaciones del lado del cliente bastante bien, lo que nos permite construir y modificar rápidamente los front-end de la aplicación web manteniendo un acoplamiento flexible entre la estructura del documento, cómo se ve todo y cómo se comporta todo. Puede cambiar uno sin cambiar los otros dos con bastante facilidad.

Idiomas del lado del servidor

La razón por la que tiene miles de millones de opciones en la web del lado del servidor, por supuesto, es porque puede hacerlo. Es tu servidor. Todo lo que tiene que hacer es comunicarse a través de http / ssl y el resto depende de usted. Por cierto, JavaScript es ahora una opción, pero eso plantea una pregunta interesante. Si aún trata una aplicación web como si realmente fueran dos aplicaciones a cada lado de ese muro HTTP. Soy de la opinión informada a través del dolor de que sí, sí deberías y me encanta Node.js.

En resumen, donde tiene proyectos grandes, también tiene varios equipos de desarrolladores trabajando en el proyecto, y esos equipos tienden a especializarse en diferentes capas de la aplicación.

Si se está centrando en la interfaz de usuario web y tiene flexibilidad en su elección de implementación, es mucho más probable que use un lenguaje dirigido a la interfaz de usuario web, como JScript o Flex, en lugar de C #.

Del mismo modo, si se encuentra en el extremo del almacén de datos transaccionales de la aplicación y se ocupa de muchas acciones simultáneas a la vez, los lenguajes especializados como erlang tienden a utilizarse. (O productos de terceros que se implementan en parte en estos idiomas)

La razón es el equilibrio del riesgo empresarial.

Digamos que eres un empleador gigante en una ciudad. Tienes que contratar a muchos desarrolladores para crear muchos servicios diferentes. Digamos que su evaluación inicial es que el lenguaje A se adapta mejor a sus intereses y desea comenzar con él.

Si te comprometes con una tecnología, podrías agotar el grupo de talentos. ¿Estás seguro de que quieres contratar a un Langauge A decente cuando hay una estrella de Language B a la vuelta de la esquina? ¿Qué pasa si mañana los frameworks de Langauge A se apoyan en el desarrollador principal? ¿Qué pasa si mañana hay un lenguaje C increíble? ¿Deberías ignorarlo porque te comprometiste con el lenguaje A hace cinco años?

Idealmente, lo que desea es un sistema heterogéneo con diferentes idiomas que refleje el grupo actual de talentos y las tendencias tecnológicas. Desea que este equilibrio cambie lentamente a medida que el grupo de talentos y las tendencias cambian para que en cualquier momento todos sus sistemas sean viables y pueda contratar a las personas para mantenerlos.

... y eso es lo que hacen las empresas.

Es útil pensar en su front-end y back-end como aplicaciones separadas que usan la misma fuente de datos.

Incluso para sitios más pequeños, puede pensar que el front-end es con lo que el cliente interactúa y el back-end como algo así como un CMS. Estas pueden ser fácilmente aplicaciones MVC separadas. El front-end aún necesita modelos y controladores para ejecutarse; después de todo, el controlador es el punto de entrada para los visitantes de su sitio y los modelos serán la forma en que obtendrá datos de su base de datos para el usuario.

Me gusta usar Django / Python como CMS en el back-end y usar Rails, CodeIgniter o Spring MVC en el front-end. A menudo no hay elección; el cliente ya tiene un sitio heredado configurado en algún idioma en el front-end y solo quiere una solución CMS. La mayoría de los clientes ni siquiera sabrían que el CMS ejecutaba un lenguaje o marco diferente si no se les informara.

Realmente se trata de encontrar lo que funciona mejor para el sitio que desea construir. Los front-end y back-end realmente solo necesitan compartir la base de datos, por lo tanto, siempre y cuando ambos puedan trabajar con eso, no dude en elegir las mejores opciones para la tarea en cuestión.

Un ejemplo de lenguaje de fondo es PHP, que es un lenguaje de script. Cuando se solicita una página PHP, el servidor lee el código PHP y presenta el marcado. El resultado es HTML que se le envía. Usted, el visor de la página web, nunca ve una línea de código PHP. Suponiendo que el administrador del servidor web haya hecho su trabajo correctamente, el servidor lo haría y nunca podría mostrarle el código PHP real. Se analiza cuando se sirve la página y el resultado de esa traducción de código es HTML.