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


19

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.


6
Os dois não são nem remotamente comparáveis. As conexões do servidor X me permitem executar um aplicativo remoto e visualizá-lo localmente, o que é um caso de uso completamente diferente de permitir que eu carregue recursos remotos em um cliente local.
Martijn Pieters

3
Não concordo que haja uma diferença. Quando conecto meu cliente da web (navegador) a um servidor (local ou remoto), posso visualizar a GUI do meu aplicativo (web). Assim como eu posso ver a GUI do meu aplicativo com uma sessão X.
Martin Josefsson

4
Tente escrever um programa X11 e compare-o com uma página HTML - compare também a largura de banda necessária. Além disso, a WWW não substituiu o X11, substituiu o Gopher.

2
Pieters: Claro, a página é renderizada no cliente e o JS é executado no cliente, mas isso é apenas detalhes técnicos. Na maioria das vezes, o código é executado no lado do servidor (php, java, .net, python, ruby, qualquer que seja). Na prática, ambas são interfaces para os aplicativos executarem em um servidor e serem mostrados em um cliente. X e web fazem isso de maneiras diferentes, mas essa é a essência.
Martin Josefsson

14
Como a tecnologia não passou na validação pela indústria de entretenimento adulto, uma etapa necessária na adoção convencional de uma tecnologia (é uma maneira elegante de dizer que fotos de mulheres nuas não se tornaram disponíveis nos sistemas X com rapidez suficiente).
dasblinkenlight

Respostas:


22

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.


1
Esta pode muito bem ser a resposta correta. Além disso, os clientes da Web também rodavam nos sistemas operacionais Apple e Microsoft.
Martin Josefsson

O hiperlink não era uma inovação da World Wide Web. Ele foi implementado muitas vezes antes, como no Hypercard, da Apple, um programa popular nos anos 80 e 90 com muitas semelhanças estranhas a um navegador da Web. O conceito de hipertexto e hiperlinks remonta aos anos 60, com o Projeto Xanadu, e foi implementado várias vezes em vários formatos antes de Tim Berners-Lee finalmente criar sua própria implementação de hipertexto baseada em rede no CERN no início dos anos 90.
Charles Salvia

3
@CharlesSalvia: O avanço dos hiperlinks HTML ocorreu devido ao URL. Em particular, seu aspecto universal: global, com autoridade central suficiente para funcionar e não vinculado a um tipo ou tecnologia específica de mídia. Suas tecnologias anteriores eram muito, muito menos universais.
MSalters

17

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.


1
Você assume que, para escrever um aplicativo usado sobre o X, você precisa entender a API do X. Mas, assim como você não precisa entender o HTTP para escrever um aplicativo da Web, não precisa entender o X para escrever um aplicativo que é executado no X. Você pode escrevê-lo em um idioma, o de sua preferência e basta ter uma biblioteca GTK no topo. Muito mais fácil do que aprender html e css e js e uma linguagem no servidor. O essencial: assim como você não precisa escrever um servidor http para publicar um site, não precisa escrever um servidor X para servir um aplicativo X.
Martin Josefsson

Eu discordo de sua análise lá. Embora você tenha razão em escrever que um aplicativo da Web moderno agora é quase tão complexo quanto escrever um aplicativo X há 10 anos. Escrever um aplicativo X ainda não é um processo trivial. É como escrever um aplicativo do Windows. Muito além da capacidade de qualquer pessoa que não tenha experiência significativa em programação. Por outro lado, colocar uma página HTML é trivial e pode ser feito em 10 minutos (mesmo para iniciantes). Assim, leva a uma rápida repressão e a capacidade de experimentar rapidamente. Isso torna a barra muito mais baixa para a entrada.
Martin York

O GTK não estava disponível até bem depois da criação da web.
user16764

@ user16764: Isso não é verdade. Eu estava usando o GTK em 1997 (não sei quando eles começaram, mas antes disso). A web (como em HTML / HTTP) pode ter sido criada na época, mas bem estabelecida, nem tanto. Quero dizer, o navegador da Web estava apenas sendo trazido para o stream principal em 92 (a primeira vez que vi um). O X tem vários outros gerenciadores de janelas que eram utilizáveis ​​antes disso. Lembro-me de usar o twm (o gerenciador de janelas de tom, eu acredito) e um outro nível um pouco mais alto (o que eu esqueço), mas havia muito por onde escolher (muitos) em 90 (e eles estavam disponíveis antes disso (eu acho)).
Martin York

@LokiAstari: Você está confundindo gerenciadores de janelas e bibliotecas de GUI. Embora exista uma sobreposição definitiva (GNOME / Gtk, KDE / Qt), eles certamente não são idênticos. Mesmo com os gerenciadores de janelas, você ainda tinha mundos de dor.
MSalters

11

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.


3

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.


1
No momento em que o HTML começou, já havia computação no servidor, com o servidor HTTP NSCA e seu SGI. A maioria dos aplicativos entregava texto, mas eu lembro de um que foi capaz de renderizar mapas personalizados em preto e branco, um ancestral do google maps.
Mouviciel 16/09/12

Os mapas de imagens datam dos primeiros anos da última década do século anterior.
precisa saber é o seguinte

1

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.


1

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.