Por que a web ganhou o espaço de aplicativos remotos e o X não?

O X Window System tem 25 anos e teve seu aniversário ontem (dia 15).

Como você provavelmente já sabe, um dos recursos mais importantes é a separação do lado do servidor e do cliente de uma maneira que nem os sistemas de janelas da Microsoft, Apples ou Wayland.

Naquela época (desculpe pelo fraseado ambíguo), muitos acreditavam que o X dominaria outras formas de criar janelas devido a essa separação de servidor e cliente, permitindo que o aplicativo fosse executado em um servidor em outro lugar enquanto o usuário clica e digita nela. próprio computador em casa.

Obviamente, esse uso ainda existe, mas é marginalizado na melhor das hipóteses. Quando escrevemos e usamos programas executados em um servidor, quase sempre usamos a web com seu html / css / js.

Por que a web venceu e o X não? As tecnologias usadas para a web (html / css / js) são uma bagunça. Combinado com todas as estruturas de back-end (Rails, Django e tudo), é realmente uma selva para navegar. Ainda assim, a web prospera com criatividade e progresso, enquanto os aplicativos X remotos não.

Parece totalmente óbvio e fundamental agora, mas a inovação matadora da rede mundial de computadores era o hiperlink. Mesmo que o X não fosse completamente inutilizável em um link de modem, sua incapacidade de iniciar um processo completamente novo em um servidor completamente novo por meio de um único clique dificultaria sua adoção para esse tipo de caso de uso.

Como o X exige que você tenha um diploma de CS para escrever um aplicativo. Embora a Web exija que você tenha a capacidade de digitar (nem isso).

Especialmente nos primeiros dias em que a web era apenas html. Você pode abrir um terminal e criar uma tela de trabalho em 10 minutos e depois melhorar interativamente com feedback instantâneo. Essa barra de entrada baixa estimulou a aceitação maciça do usuário. Construir um aplicativo X-Server, por outro lado, é uma tarefa não trivial, mesmo para programadores experientes.

Levou 10 anos para a Web ser um concorrente direto do aplicativo X em termos de funcionalidade e fornecer as mesmas habilidades de GUI. Essa funcionalidade foi adicionada à pilha de idiomas ao longo do tempo, permitindo que os desenvolvedores dominassem um conjunto de recursos antes que o próximo fosse adicionado; portanto, essa expansão gradual da complexidade tecnológica manteve a fasquia baixa (para pessoas que já estão no campo e há muitas). Saltar para o campo agora é muito mais difícil do que era há 10 anos, mas ainda é possível e o feedback instantâneo da Web torna o aprendizado mais gratificante (os seres humanos precisam de gratificação rápida para reforçar seus esforços).

O custo é outro fator. O custo real de aprender habilidades de programação suficientes para desenvolver um X-Server é significativo. Além disso, a disponibilidade de servidores para executar seu aplicativo aumentou o custo. Aprender a escrever HTML praticamente não era nada para obter a página "Hello World" em funcionamento e os provedores de serviços de Internet forneciam hospedagem gratuita para inspirar você a obter uma conexão com a web. Então você pode praticar de graça. Quando você acabou precisando de hospedagem de negócios, a disponibilidade de empresas de hospedagem aumentou e o custo sempre foi relativamente baixo.

A resposta é que "muitas tecnologias são adotadas por razões históricas ou sócio-políticas arbitrárias, e não por razões técnicas". A melhor solução para um determinado problema nem sempre se torna a tecnologia dominante. (De fato, raramente acontece.)

Em 2012, onde os servidores HTTP estão sendo usados ​​para criar aplicativos interativos, a par dos aplicativos Desktop, a comparação entre HTTP e X é interessante. Em retrospectiva, o X é provavelmente uma tecnologia melhor para desenvolver aplicativos ricos e interativos implantados em rede. Os aplicativos interativos do tipo área de trabalho não são bem mapeados para uma tecnologia sem estado e orientada a documentos como HTTP, e essa incompatibilidade historicamente resultou em todo tipo de solução alternativa (hacks) para criar estado, como cookies, sessões etc.

Mas o objetivo original do HTTP não era desenvolver aplicativos stateful do tipo Desktop. Era para recuperar documentos e exibir informações - informações que podiam ser vinculadas a outros documentos que também podiam ser exibidos instantaneamente. A idéia de uma coleção vinculada de documentos remonta aos anos 1960 com o " Projeto Xanadu " de Theodore Nelson . A Web deveria ser uma implementação do conceito de hipertexto de Nelson , que era uma tentativa de informatizar a página impressa - como a enciclopédia ou o jornal - permitindo ao usuário "pular" instantaneamente de um artigo para outro com um único clique.

Muitas iterações dessa idéia surgiram e desapareceram, como o Hypercard da Apple , que implementou o conceito de hipertexto / hiperlinks, mas nunca foi implantado em redes. A World Wide Web foi a implementação do conceito de hipertexto baseada em rede do CERN e provavelmente decolou porque Tim Berners-Lee lançou sua biblioteca de códigos do navegador gratuitamente, permitindo que outros experimentassem. Isso acabou levando ao navegador Mosaic de Marc Andreesen, o antecessor do Netscape. E o resto é história.

Mas ... como em tantas tecnologias, começaram a surgir novas possibilidades que os designers originais de HTTP ou hipertexto não pensavam muito. A web tornou-se comercializada e as pessoas começaram a desenvolver sites que apresentavam interatividade estável, como carrinhos de compras e logins. Tornou-se cada vez mais evidente que a natureza do HTTP sem estado e orientada a documentos não era muito adequada para aplicativos do tipo Desktop. Mas naquele momento, era tarde demais. Todo mundo já estava usando HTTP. Então, aqui estamos hoje, com vários aplicativos AJAX hacky tentando ao máximo fingir que são aplicativos de área de trabalho.

As tecnologias podem tentar resolver problemas semelhantes agora, mas com certeza não o fizeram no passado.

A pilha HTML atual evoluiu ao longo do tempo, passando de transferências de documentos de texto realmente simples, passando por documentos "visuais" com pouco script, para uma plataforma de aplicativos com todos os recursos.

No momento em que o HTML começou, ninguém poderia sonhar em se conectar a um computador remoto e executar aplicativos gráficos lá. Somente depois que a Internet obteve melhor latência e taxa de transferência, isso se tornou possível. No entanto, naquela época, o HTML já estava presente. Todos sabiam que essa era uma maneira de fornecer aos clientes e usuários acesso a aplicativos gráficos, executados na máquina remota.

E, como em todo sistema "gratuito", tornou-se impossível "redefinir" a coisa toda e começar de novo a fazê-lo melhor desta vez. É por isso que precisamos calar a boca e usar HTML / CSS / JS e apenas desejar que as pessoas que o suportam finalmente o entendam e o enterrem junto com seu legado de anos.

Isso responde à pergunta "Por que a web ganhou?". Não houve competição, a web venceu antes de tudo começar.

Concordo que, em princípio, os dois são semelhantes. Se você fizer a pergunta "como podemos executar o código em um servidor, mas fornecer visualização em um cliente remoto?", É razoável pensar que equipes independentes possam criar uma dessas soluções.

Suspeito que a razão de uma ser mais popular que a outra em certos aspectos seja porque as duas abordam o mesmo problema de perspectivas completamente diferentes. X é uma solução técnica para um problema técnico, mas a Web evoluiu conforme a necessidade de resolver um problema social - como posso pegar recursos de um servidor remoto e exibi-lo na minha máquina local, e fazê-lo de uma maneira fácil e conveniente?

A web "ganhou" porque resolveu um problema experimentado por mais pessoas. Pense na analogia de um carro: tanto os carros de luxo quanto os caminhões resolvem os mesmos problemas: como transportar algo de um lugar para outro.

O caminhão resolveu o problema técnico de literalmente como transportar algo do ponto A ao ponto B, e para isso funciona muito bem. O carro de passageiro evoluiu conforme a necessidade de as pessoas se sentirem confortáveis ​​enquanto viajam e de transportar mais pessoas e menos adubo. Tornou-se uma necessidade que exigia conveniências. Assim, com o tempo, o número de carros de passageiros superou em muito o número de picapes na estrada (suponho que, com base na observação do tráfego de Chicago, talvez seja diferente no Texas? :-)

Assim, como a analogia carro / caminhão, a Web e o X11 resolvem o mesmo problema técnico, mas servem a propósitos completamente separados.

Você está comparando maçãs com peras. O X windows trata da separação da renderização do conteúdo da tela em um cliente local, que pode ser conectado por um fio fino à origem do conteúdo. É realmente uma extensão do modelo computacional da era "glass tty" para o domínio de gráficos de alta qualidade. O X se originou na época em que os PCs ainda eram muito fracos e a maior parte da computação real era feita em caixas unix ou mainframe. A idéia era aproveitar o poder de "terminais X" relativamente baratos e redes relativamente lentas para disponibilizar graficamente esses sérios recursos computacionais.

A razão pela qual isso não venceu em Macs e PCs é que seu desenvolvimento sempre foi impulsionado pelo desejo de oferecer suporte a gráficos de ponta em aplicativos locais , incluindo jogos, editores e gráficos de negócios. O suporte a aplicativos residentes na rede é uma reflexão tardia recente.