Por que sites grandes usam idiomas diferentes para o back-end e o front-end?

Meu entendimento de pequenas aplicações MVC é que você tem o front end, que lida com HTML, JS, jQuery, etc, e o back-end, que consiste em seus controladores e modelos.

No entanto, quando falo com desenvolvedores de grandes empresas, eles geralmente mencionam ter uma camada de front-end e uma de back-end. Então, às vezes, posso ouvir que eles têm uma interface com C # e uma interface com Java. Por que alguma empresa deseja um back-end e front-end em diferentes idiomas? Isso ajuda o site grande a escalar melhor?

Quando as pessoas dizem que seu front-end é construído em C #, isso significa que eles estão usando uma estrutura para o front-end (como o .NET) e uma estrutura adicional no back-end (como o Spring)? Ou isso significa algo completamente diferente?

"Front-end" e "Back-end" podem ser termos nebulosos, principalmente em aplicativos corporativos. "Front-end" pode significar a interface do usuário ou o aplicativo inteiro. "Back-end" pode ser usado para significar os internos, ou pode ser o banco de dados ou serviços externos que são consumidos. O significado dos termos geralmente depende inteiramente de quem você está falando. Então você perguntou "ei, o que você quer dizer com isso?"

Quando você entra no desenvolvimento de grandes empresas, terá muitas e muitas equipes escrevendo muito e muito código. Essas equipes estarão se desenvolvendo em diferentes idiomas, usando diferentes paradigmas, de diferentes locais. Parte desse código precisará trabalhar juntos e grande parte dele não.

Eu trabalho para um grande banco. Minha equipe desenvolve nosso aplicativo em C #. Tudo isso. Porém, consumimos serviços da Web que são amplamente escritos em Java, e esses serviços conversam com outros serviços que conversam com outros serviços que obtêm os dados da conta de e para os armazenamentos de dados apropriados, e quem sabe quais idiomas são usados ​​com eles.

Versão curta: as pessoas usam as ferramentas que fazem o trabalho.

Eu acho que você precisa ampliar um pouco a pergunta: por que projetos de software grandes usam mais de uma linguagem de programação?

Existem muitas respostas possíveis, sendo as mais notáveis:

• Grandes aplicações consistem em muitas partes relativamente independentes; frequentemente, cada parte é construída por uma equipe diferente ou mesmo por um contratante externo diferente. O benefício de aceitar o melhor lance é geralmente maior do que o de ter tudo no mesmo idioma.
• Os idiomas vêm e vão, e às vezes um componente de um grande sistema sobrevive ao ecossistema. Um exemplo do mundo da Microsoft é quantas empresas agora usam C # para todos os novos projetos, mas ainda possuem uma base de código VB considerável. O custo de reescrever um projeto apenas com o objetivo de fazê-lo na linguagem de programação mais recente praticamente nunca se justifica.
• Interface com componentes de terceiros. Se o seu ecossistema C # precisar executar uma tarefa específica para a qual existem apenas soluções Java, você terá duas opções: implementar você mesmo a solução ou usar a solução Java e desenvolver um pouco de cola para integrá-la ao seu sistema. Este último é quase invariavelmente mais barato para qualquer tarefa não trivial.

As considerações sobre desempenho praticamente nunca são o motivo, exceto em aplicativos extremamente críticos para o desempenho, como negociação de alta frequência - nessas áreas, pode ser benéfico escrever o mecanismo do núcleo crítico em um idioma com melhor desempenho em tempo de execução (por exemplo, C ++), mas os sistemas de suporte (UI, relatórios, etc.) em algo de nível superior, como Java ou C #.

É relativo em uma grande empresa.
Na minha empresa, a pilha é aproximadamente

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

Portanto, para a equipe de desenvolvimento web, o front-end é HTML / JS e o back-end é Java. Para a empresa, o front-end é Java e o back-end é .Net.

De fato, a camada .Net precisa trabalhar com um aplicativo COBOL / UNIX para cobrança e declarações e, portanto, nessa perspectiva .Net é front-end e COBOL é back-end.

E sim, como outros mencionaram, temos equipes de designers de UX, desenvolvedores de HTML / JS, desenvolvedores de Java, desenvolvedores de Java, Web Middleware, desenvolvedores de .Net, desenvolvedores de SQL, desenvolvedores de COBOL trabalhando em cada parte da pilha.

De fato, em qualquer empresa suficientemente grande, são tartarugas até o fim.

Semântica Confusa

É uma questão semântica. Quando alguém diz um desenvolvedor front-end .NET ou Java front-end, geralmente está falando sobre a pessoa que sabe muito sobre linguagens de templates e talvez estruturas que nunca devem ser usadas novamente como formulários da web usados ​​para tentar ocultar o arremessar coisas através de um muro http (isto é, "desenvolvimento da web") de desenvolvedores de aplicativos que não queriam ou pelo menos se supunha que não queriam aprender sobre toda essa porcaria. No caso de .NET e Java misto, não tenho certeza, mas só posso supor que, no sentido MVC, eles têm o Java agindo para todas as coisas do modelo de negócios e o .NET lidando com tudo o que seria melhor descrito como "camada intermediária", mas ainda está do lado do servidor.

A verdadeira separação é o que acontece no servidor e o que acontece no cliente ou no navegador. Você pode facilmente confundir a criação do HTML a ser enviado ou representar o front-end com "desenvolvimento de front-end". Por isso, prefiro evitar confusão usando os termos cliente e servidor em vez de front-end e back-end ao discutir o que normalmente faço, (geralmente trabalho do lado do cliente).

Idiomas do lado do cliente

A razão pela qual usamos o mesmo conjunto de idiomas no navegador é porque o navegador está no lado de recebimento e, na maioria das vezes (agora há uma resistência quase mortal da Microsoft e da Adobe nisso), ninguém quer enviar três versões diferentes do mesmo lado do cliente para satisfazer todos os clientes em potencial ou exigir que um plug-in proprietário seja instalado para que a Web funcione. Além disso, os três idiomas realmente encapsulam as preocupações do lado do cliente, permitindo que construamos e modifiquemos rapidamente os front-ends de aplicativos da web, mantendo um acoplamento flexível entre a estrutura do documento, como tudo parece e como tudo se comporta. Você pode alterar um sem alterar os outros dois com bastante facilidade.

Idiomas do lado do servidor

A razão pela qual você tem inúmeras opções na Web do lado do servidor é porque você pode. É o seu servidor. Tudo o que precisa fazer é se comunicar via http / ssl e o resto é com você. O JavaScript agora é uma opção, a propósito, mas isso traz uma pergunta interessante. Você ainda deve tratar um aplicativo Web como se fosse realmente dois aplicativos em ambos os lados desse muro HTTP. Sou da opinião informada de que sim, sim, você deveria e eu amo o Node.js.

Em resumo, onde você tem grandes projetos, também possui várias equipes de desenvolvedores trabalhando no projeto, e essas equipes tendem a se especializar em diferentes camadas do aplicativo.

Se você estiver focado na interface do usuário da Web e tiver flexibilidade na sua escolha de implementação, é muito mais provável que você use uma linguagem de destino da interface do usuário da Web, como JScript ou Flex, em vez de C #.

Da mesma forma, se você estiver no final do aplicativo de armazenamento de dados transacionais, lidando com muitas ações simultâneas ao mesmo tempo, idiomas especializados como erlang tendem a se acostumar. (Ou produtos de terceiros implementados em parte nesses idiomas)

O motivo é o equilíbrio de riscos nos negócios.

Digamos que você seja um empregador gigante em uma cidade. Você precisa contratar muitos desenvolvedores para criar muitos serviços diferentes. Digamos que sua avaliação inicial seja que o Lanuage A se adapte melhor aos seus interesses e você deseja começar com ele.

Se você se comprometer com uma tecnologia, poderá secar o pool de talentos. Tem certeza de que deseja contratar um funcionário decente do Langauge A quando houver uma estrela do idioma B ao virar da esquina? E se amanhã as estruturas do Langauge A se apoderarem do suporte do desenvolvedor principal? E se amanhã houver uma linguagem C incrível, você deve ignorá-la porque se comprometeu com a linguagem A há cinco anos?

Idealmente, o que você deseja é um sistema hetrógeno com diferentes idiomas que reflita o pool de talentos e as tendências tecnológicas atuais. Você deseja que esse equilíbrio mude lentamente à medida que o conjunto de talentos e as tendências estão mudando, para que a qualquer momento todos os seus sistemas sejam viáveis ​​e você possa contratar pessoas para mantê-los.

... e é isso que as empresas fazem.

É útil pensar no seu front end e back-end como aplicativos separados que usam a mesma fonte de dados.

Mesmo em sites menores, você pode pensar no front end como o que o cliente faz interface e no back-end como algo como um CMS. Eles podem ser facilmente aplicativos MVC separados. O front-end ainda precisa de modelos e controladores para executar - afinal, o controlador é o ponto de entrada para os visitantes do site e os modelos serão a maneira como você obtém dados do banco de dados para o usuário.

Eu gosto de usar o Django / Python como um CMS no back-end e o Rails, CodeIgniter ou Spring MVC no front-end. Freqüentemente não há escolha; o cliente já possui algum site herdado configurado em algum idioma no front-end e deseja apenas uma solução CMS. A maioria dos clientes nem saberia que o CMS estava executando um idioma ou estrutura diferente se não fossem informados.

É realmente sobre encontrar o que funciona melhor para o site que você deseja criar. O front-end e o back-end realmente precisam apenas compartilhar o banco de dados, desde que ambos possam trabalhar com isso, fique à vontade para escolher as melhores opções para a tarefa em questão.

Um exemplo de uma linguagem de back-end é o PHP, que é uma linguagem de script. Quando uma página PHP é solicitada, o servidor lê o código PHP e renderiza a marcação. O resultado é um HTML enviado a você. Você, o visualizador de páginas da web, nunca vê uma linha de código PHP. Supondo que o administrador do servidor da Web tenha feito seu trabalho corretamente, o servidor faria e nunca poderia mostrar o código PHP real. É analisado quando a página é exibida e o resultado dessa tradução de código é HTML.