Por que as bases de código no desenvolvimento de n camadas têm uma quantidade igual, se não mais, de código JavaScript agora?

Faço programação web há muito tempo e, em algum lugar, perdi a noção de por que estamos fazendo o que estamos fazendo hoje (ou como chegamos a fazer as coisas dessa maneira)?

Comecei com o desenvolvimento básico da Web ASP e, desde o início, a lógica de exibição e de negócios foi misturada na página. O desenvolvimento do lado do cliente variou bastante (VBScript, diferentes tipos de JavaScript), e tivemos muitos avisos sobre validações do lado do servidor (e, portanto, fiquei longe da lógica do lado do cliente).

Então mudei para o ColdFusion por um tempo. O ColdFusion foi provavelmente a primeira estrutura de desenvolvimento web que separou a lógica de exibição e de negócios usando suas tags. Pareceu-me muito claro, mas muito detalhado, e o ColdFusion não estava em alta demanda do mercado e, portanto, segui em frente.

Então pulei no vagão de banda do ASP.NET e comecei a usar sua abordagem MVC. Também percebi que o Java parecia ser uma linguagem de torre de marfim dos sistemas corporativos e também tentei sua abordagem MVC. Posteriormente, o ASP.NET desenvolveu esse padrão de design do MVVM e o Java (precisamente, J2EE ou JEE) também teve dificuldades e saiu com suas abordagens MVC2.

Mas hoje, o que eu descobri é que a programação de back-end não é mais onde a emoção e o progresso estão. Além disso, as práticas MVC baseadas no servidor parecem obsoletas (as pessoas realmente usam mais o JSTL?). Hoje, na maioria dos projetos em que participei, descobri que as estruturas JavaScript e o desenvolvimento do cliente são onde estão sendo realizados todos os progressos emocionantes e inovadores.

Por que esse movimento do servidor para o desenvolvimento do lado do cliente ocorreu? Fiz uma contagem simples de linhas de um dos meus projetos JEE e há mais linhas de código em JavaScript que Java (excluindo bibliotecas de terceiros). Acho que a maioria do desenvolvimento de back-end usando linguagens de programação como Java ou C # é simplesmente produzir uma interface semelhante a REST, e que todo o esforço de exibição, visualização, entrada / saída de dados, interações do usuário, etc. via estrutura do lado do cliente, como Angular, Backbone, Ember, Knockout, etc ...

Durante a era pré-jQuery, vi muitos diagramas em que havia uma linha clara e conceitual entre M, V e C no MVC no desenvolvimento de n camadas. Pós-jQuery, onde essas linhas são desenhadas? Parece que o MVC e o MVVM estão todos lá no código JavaScript, no lado do cliente.

O que eu quero saber é: por que fizemos essa transição (da ênfase da programação do servidor para a do cliente, do favorecimento de linguagens compiladas para linguagens de script, do imperativo para a programação funcional, tudo isso parece ter ocorrido simultaneamente ) e que problemas essa transição / mudança resolveu?

Mudar a carga de computação entre o servidor e o cliente é um fenômeno cíclico, e isso ocorre há algum tempo.

Quando eu estava na faculdade da comunidade, o Computador Pessoal estava apenas começando. Mas a Ethernet ainda não era amplamente utilizada e ninguém tinha uma rede local. Naquela época, a faculdade possuía um mainframe que tratava dos registros dos alunos e servia de plataforma para as aulas de programação. A administração tinha terminais que eram conectados ao mainframe em uma base de compartilhamento de tempo, mas os estudantes precisavam perfurar cartões para concluir suas tarefas de programação, um processo árduo. Eventualmente, eles colocaram em um laboratório onde os alunos pudessem se inscrever para trabalhar em um terminal, mas ainda demorou cerca de meia hora para obter a impressão espessa de erros de meia polegada. Todo o trabalho de processamento foi realizado no mainframe (o servidor).

Mas os mainframes eram caros, então as empresas começaram a instalar redes locais, e a carga de processamento mudou do servidor para as máquinas clientes individuais, que eram poderosas o suficiente para executar aplicativos individuais de processamento de texto, planilha e linha de negócios, mas não suficientemente poderosas para compartilhar seu poder de processamento com outras pessoas. O servidor era uma máquina semelhante com recursos semelhantes (talvez mais memória e espaço no disco rígido), mas era usado principalmente para compartilhar arquivos. Isso foi chamado de cliente / servidor. A maior parte do processamento foi transferida para os computadores clientes.

Uma das desvantagens de fazer todo o processamento nas máquinas clientes foi que você ficou preso nesse ciclo perpétuo de instalação e atualizações de software e todas as dores de cabeça que o acompanham. O modelo de programação dessas máquinas (interfaces de usuário baseadas em código e baseadas em eventos) incentivou a criação de programas confusos e difíceis de manter (grandes bolas de barro). A maioria dos usuários finais não possuía as habilidades necessárias para manter seu hardware e software adequadamente, necessitando de exércitos do pessoal de manutenção de TI.

À medida que os computadores se tornaram cada vez mais poderosos, divisões de trabalho se tornaram possíveis. Agora você pode ter servidores de arquivos, servidores de banco de dados, servidores web, servidores de impressão e assim por diante. Cada máquina pode ser um pouco otimizada para a tarefa que foi fornecida e mantida por alguém com a experiência necessária. Poderiam ser criados programas executados no navegador da Web, para que as instalações do cliente não fossem mais necessárias. Isso foi chamado de multicamada ou n-camada. Os navegadores eram essencialmente usados ​​como terminais burros, como nos dias de mainframe, embora o método de comunicação com o servidor fosse mais sofisticado, menos proprietário e baseado em mecanismos de interrupção, em vez de compartilhamento de tempo e pesquisa. O processamento voltou para o (s) servidor (es).

No entanto, o desenvolvimento da web veio com um novo conjunto de dores de cabeça. A maioria dos aplicativos de linha de negócios criados para o navegador eram formulários e relatórios estáticos. Havia muito pouca interatividade disponível na interface do usuário. O Javascript ainda não havia encontrado o seu segundo vento, e houve grandes problemas com incompatibilidades do navegador que desencorajaram sua ampla adoção. No entanto, as coisas melhoraram muito. HTML5 e CSS3 fornecem novos recursos substanciais ao modelo de programação do navegador, o jQuery surgiu e ajudou toda uma geração de programadores a descobrir o quão útil o Javascript poderia ser. Surgiram novas estruturas de interface do usuário front-end. Tornou-se possível escrever interfaces de usuário altamente interativas no navegador, até jogos completos. O processamento voltou ao cliente novamente.

Hoje, você pode comprar poder de processamento na nuvem, o quanto você quiser, e executar programas no servidor. Eu diria que agora estamos em um lugar onde, como desenvolvedor de software, você tem muitas opções sobre onde pode executar seu poder de processamento, tanto no cliente quanto no servidor.

Você parece estar misturando dois conceitos muito diferentes:

1. Separar apresentação e lógica de negócios (MVC) => aumentar a capacidade de manutenção
2. Atribuindo execução a um nó => aumentar a eficiência

Naquela época, a computação de cliente / servidor era muitas vezes confusa para implicar a primeira, porque os clientes geralmente não ofereciam muito poder de computação, em comparação com os servidores. Por isso, parecia natural mover a computação da lógica de negócios "pesada" (M) para os servidores, mantendo o processamento de exibição "leve" (V) para os clientes. Por sua vez, você teve que implementar algum tipo de árbitro (C) para traduzir entre os dois.

Agora, com os clientes apresentando facilmente as proezas do processo que antes implicavam algum hardware de servidor caro, as linhas ficaram borradas quanto ao local onde executar a lógica de negócios - do lado do cliente ou do servidor. Realmente, a resposta depende do seu caso de uso específico e da escolha de trocas, por exemplo:

• latência do cliente versus complexidade: o processamento do lado do servidor mantém os sistemas mais simples porque nenhum código precisa ser implantado / baixado no cliente; no entanto, isso implica o custo da latência do lado do cliente durante o cálculo.

• complexidade versus carga do servidor: a computação do cliente pode aumentar a complexidade do sistema, mas também pode ajudar a reduzir a carga do servidor.

• resiliência descentralizada de aplicativos versus execução central: em um mundo de aplicativos para dispositivos móveis, pode ser importante manter os clientes trabalhando, apesar de uma desconexão da rede. No entanto, isso tem o custo de gerenciar várias versões implementadas da lógica de negócios.

Esta é uma lista não exaustiva de muitas trocas.

Como os usuários sempre desejaram a mesma funcionalidade, tocam com seus aplicativos da Web (não apenas sites) que tinham com os aplicativos de desktop. Fazer tudo isso ser executado em um navegador (na verdade, vários navegadores) não é como nos velhos tempos em que era possível vincular um formulário VB a um banco de dados com pouco código. Isso é mais fácil de ser realizado quando você não precisa fazer viagens de volta ao servidor.

O maior desenvolvimento de back-end usando linguagens de programação como Java ou C # é simplesmente produzir uma interface semelhante a REST, e que todo o grande esforço de exibição, visualização, entrada / saída de dados, interações do usuário etc. estrutura lateral como Angular, Backbone, Ember, Knockout, etc ...

Talvez a programação / serviços de back-end pareça a mesma coisa antiga, mas é o coração do aplicativo. As práticas de codificação podem ser mais eficientes nessas áreas. As ferramentas, idiomas, navegadores e estruturas ainda estão evoluindo, por isso é difícil desenvolver a UI / UX. São as novidades que o antigo ASP não possuía. Se pudéssemos nos safar de interfaces de usuário com formulários simples e tabelas html, também não haveria muito interesse / hype nessas áreas, mas os usuários querem arrastar e soltar, animações, transições, pop-ups etc.

Hoje, na maioria dos projetos em que participei, descobri que as estruturas JavaScript e o desenvolvimento do cliente são onde estão sendo realizados todos os progressos emocionantes e inovadores.

Por que esse movimento do servidor para o desenvolvimento do lado do cliente ocorreu?

Na verdade, existem duas perguntas aqui:

1. Por que a programação do lado do cliente está acontecendo progresso?
2. Por que os aplicativos são escritos para serem executados no cliente e não no servidor?

Os dois são realmente distintos.

Por que a programação do lado do cliente está acontecendo progresso?

Como o tempo de execução, o ambiente e o ecossistema amadureceram substancialmente nos últimos três anos, e isso abriu novos nichos que os inovadores esperavam explorar.

O desenvolvimento front-end costumava ser difícil . Você tinha que programar para navegadores - sempre um ambiente hostil - usando os recursos restritos do ECMAScript 3, em um ecossistema que não possuía arte ou ferramentas para criar aplicativos de clientes espessos. Não havia carregadores de módulos. Você não conseguiu lidar com dependências corretamente. Havia uma escassez de ferramentas de fiapos. As estruturas eram imaturas e a má reputação do front-end distanciava os inovadores que poderiam resolver esses problemas.

À medida que esses fatores mudam gradualmente, eles criaram uma massa crítica para o desenvolvimento rápido de aplicativos rich client e para executá-los de forma consistente.

Em resposta à sua pergunta, então, não é tanto o fato de as novas tecnologias front-end impulsionarem o progresso, mas também liberam gargalos e permitem que os clientes atendam às aspirações dos usuários.

Por que os aplicativos são escritos para serem executados no cliente e não no servidor?

Existem muitas causas próximas, mas a mais distinta dos últimos anos é a ascensão dos smartphones.

Os smartphones tornam a computação moderadamente poderosa barata, onipresente e útil. Eles pertencem a bilhões de pessoas em todo o planeta e trouxeram a computação para as classes médias das economias emergentes. Mas as redes móveis são lentas, irregulares e restritas por problemas geográficos, de engenharia e políticos. Nesse ambiente, é inevitável que os aplicativos armazenem o estado localmente e corrijam os dados para cima com relutância e em operações sem estado.

Como poderia ser diferente? Imagine se o seu smartphone fosse apenas um terminal idiota. Toda mutação de estado teria que ser assíncrona e falível. Cada carregamento de conteúdo custaria centavos preciosos. Você precisaria investir em enormes farms de servidores com tempo de atividade de cinco a nove. Os custos de computação seriam incorridos diretamente por você; portanto, um aumento repentino de popularidade poderia realmente prejudicar seus negócios.

Os aplicativos do lado do cliente permitem lidar com o estado pertencente ao usuário individual de maneira rápida e síncrona. Eles permitem que você baixe seus custos de computação para seus usuários. Eles permitem que você evite tempo de inatividade e baixa conectividade de rede. Eles tornam o código do servidor tão tolo que pode ser armazenado em cache na própria infraestrutura de rede - arquivos HTML e JS estáticos ou respostas em lata para aplicativos móveis.

Em termos muito amplos: o desenvolvimento do lado do cliente explora os baixos custos da computação pessoal de média potência e evita os altos custos da computação centralizada de alta potência.

Você fez várias perguntas, algumas das quais já têm boas respostas. Alguns ainda não tiveram suas respostas:

O que eu quero saber é: por que fizemos essa transição (da ênfase da programação do lado do servidor para o lado do cliente, ... tudo isso parece ter ocorrido simultaneamente) e que problemas essa transição / mudança resolveu?

Robert Harvey deu uma excelente resposta.

... de favorecer linguagens compiladas para linguagens de script,

As linguagens de script oferecem muitas vantagens ( também ) sobre as linguagens compiladas, por exemplo:

• são mais fáceis de aprender e usar
• eliminar tempo de compilação (desenvolvimento mais rápido)
• fornecer mais recursos (controle de aplicativos de última geração)
• permitir alterações rápidas na execução do código
• etc.

... da imperativa à programação funcional,

Aqui está uma boa comparação, mas eu resumiria dizendo que, em software distribuído (pense em computação em nuvem), gerenciar mudanças de estado (sincronização em muitos nós) pode ser um grande problema. Na programação funcional, a necessidade de lidar com mudanças de estado é muito menor.