paint-brush
A diferença entre aplicativos da Web e sitespor@webhistory
3,787 leituras
3,787 leituras

A diferença entre aplicativos da Web e sites

por History of the Web6m2023/01/15
Read on Terminal Reader

Muito longo; Para ler

Em 1999, a conversa em torno da web se concentrou em seu poder como uma nova mídia. Mas havia pouco em termos de aplicativos de computação. Koranteng Ofosu-Amaah, da IBM, traçou uma linha crucial na areia. Em uma postagem no blog, ele escreveu sobre aplicativos versus W3C DOM.
featured image - A diferença entre aplicativos da Web e sites
 History of the Web HackerNoon profile picture
0-item

Um site é o mesmo que um aplicativo da web? Essa pergunta é mais antiga do que você pensa


Em 2013, o blog de desenvolvimento web CSS Tricks fez uma enquete com uma única pergunta: “É útil distinguir entre “web apps” e “web sites”? Dezessete mil pessoas responderam. 72% responderam que sim . São coisas diferentes com preocupações diferentes. Os 28% restantes responderam Não. É tudo apenas a web.


Essa pergunta, circulada de diferentes maneiras, tornou-se um refrão comum. A cada poucos anos, ele entra novamente no zeitgeist do desenvolvimento web. No centro, porém, está a mesma questão: a web está dividida? Existe uma web destinada a aplicativos do tipo desktop e outra destinada a conteúdo. Uma teia que serve, e outra que cria.


Na prática, oferece pouco mais do que um experimento mental, embora útil. Pode enquadrar um momento de prática de desenvolvimento web. Igualmente útil é rastrear a conversa até uma das primeiras vezes em que a conversa surgiu, de volta à história do DHTML e de uma empresa chamada Oddpost.


Em 1999, a pequena startup Halfbrain lançou o BrainMatter. BrainMatter era um aplicativo de planilha. Ele imitava a funcionalidade do Excel e os usuários podiam classificar dados, arrastar e soltar linhas e colunas e até mesmo usar funções básicas e macros. O que fez o BrainMatter se destacar foi que ele existia inteiramente na web. Qualquer usuário pode inicializar o BrainMatter diretamente em seu navegador de qualquer lugar do mundo. Embora, na época, o site funcionasse apenas no navegador líder de mercado Internet Explorer, uma escolha consciente da equipe de desenvolvimento devido ao tipo de tecnologia que a Microsoft havia disponibilizado.


No entanto, BrainMatter foi impressionante; funcionou muito melhor do que qualquer um pensava ser possível. Em 1999, a conversa na web se concentrou em seu poder como uma nova mídia – a era do “conteúdo é rei”. As publicações dominaram o cenário dos internautas, mas havia pouco em termos de aplicativos de computação. Halfbrain desafiou essa percepção, aproveitando um lote de tecnologias em evolução agrupadas sob a égide do HTML dinâmico ou DHTML.


Em vez de uma prática ou princípio unificado de programação, o DHTML era uma coleção solta de técnicas que combinavam JavaScript, CSS e algumas tecnologias proprietárias da Microsoft (é por isso que só funcionava em um navegador da Microsoft) para possibilitar sites que pudessem atualizar dados interativos sem a necessidade de recarregar a página. Isso permite que os usuários interajam diretamente com uma página, preencham formulários para adicionar dados, arrastem coisas - e geralmente façam o tipo de coisas que as pessoas costumavam fazer apenas em seus desktops - diretamente na web. Na época do Google Docs e dos aplicativos Electron baseados na web, isso pode parecer comum. Em 1999, era novo.


Não muito depois do lançamento do BrainMatter, o Halfbrain foi comprado pela AlphaBlox, que usou a mesma tecnologia e técnicas para construir software de apresentação na web; PowerPoint em um site. Pouco depois, o AlphaBlox foi adquirido pela IBM.


A essa altura, o mercado de navegadores tinha uma nova estrela em ascensão, o Firefox, da Mozilla. O Firefox tornou o DHTML possível de uma forma que o concorrente anterior da Microsoft e seu antecessor, Netscape, nunca fizeram. Mas não sem dificuldade. Um dos engenheiros da IBM, Koranteng Ofosu-Amaah, posteriormente compilou notas sobre essa mesma complexidade em um post de blog, Applications vs W3C Dom . Nele, Ofosu-Amaah desenha uma linha crucial na areia. Por um lado, estão os aplicativos da Web, possíveis por meio de uma série de hacks, soluções alternativas inteligentes e tecnologias proprietárias disponíveis em um navegador ou outro. Um do outro são sites de conteúdo, possibilitados pelas tecnologias padronizadas da web. Aplicativos orientados a DOM e sites orientados a padrões. Aplicativos da Web e sites.

Halfbrain alum lançaria mais tarde Oddpost, retratado aqui, usando as mesmas técnicas aplicadas ao DHTML

Em uma de suas notas, ele deixa isso explícito: A compatibilidade do navegador é um grande obstáculo para os aplicativos W3C DOM . Ofosu-Amaah reconheceu que alguns sites exigiam recursos e tecnologias que não eram universalmente acessíveis e, portanto, excluíam totalmente alguns usuários da experiência (pessoas que usam navegadores mais antigos, por exemplo). E no estado de desenvolvimento da web por volta do ano 2000, isso era verdade. A questão de aplicativos da Web versus sites na época se concentrava principalmente nesse fato, de que era quase impossível oferecer a mesma experiência interativa e dinâmica em todos os navegadores e dispositivos.


A quantidade de engenheiros web trabalhando em 1999 era relativamente pequena. Engenheiros bem versados em DHTML, ainda menores que isso. Entre este seleto grupo estavam dois engenheiros Halfbrain, Ethan Diamond e Iain Lamb. Em 2002, eles estavam prontos para passar do Halfbrain para seu próximo aplicativo da Web desenvolvido com DHTML. Desta vez por e-mail. Chamava-se Oddpost.


Oddpost estreou em junho de 2002. Sua página inicial dizia simplesmente “Eis! Oddpost. E-mail incomparável. As últimas notícias e blogs. Tudo em um só lugar.” A principal função do Oddpost era o e-mail. Ele modelou os populares aplicativos de e-mail de desktop da época, como o Microsoft Outlook e o Eudora. Mas também tinha um leitor de feed integrado para agregar conteúdo de sites de notícias e blogs.

Como BrainMatter, no entanto, Oddpost funcionou inteiramente na web, usando tecnologias nativas da web. Ele poderia ser acessado de qualquer computador que tivesse um navegador moderno (embora, novamente, apenas o Internet Explorer), que era a maioria dos computadores. Por US$ 30/ano, estava em um território com preços razoáveis antes que o conceito de e-mail gratuito fosse a norma.


Em termos de interfaces de e-mail, não era muito inovador. Janela de três painéis. Mensagens organizadas por data, encadeadas por remetente. Sua interface era simples, com apenas os recursos mais essenciais. Isso foi planejado. Oddpost foi impressionante porque parecia ágil e dinâmico, embora, para o usuário comum, não passasse de um URL da web.


Tal era o poder do DHTML. Quando o Oddpost foi lançado, outros aplicativos da web semelhantes foram sendo lançados em vários bolsos da web. Isso reorientou a conversa sobre a possibilidade e a promessa da web, e as pessoas começaram a discutir sites que eram mais do que sites. Sites que eram, como disse Ofosu-Amaah, de fato aplicativos da web.


Em 2002, Ethan Diamond deu uma entrevista ao popular blog de Joshua Kaufman , Unraveled . O Oddpost, como o BrainMatter antes dele, não rodaria de forma alguma dentro do Mozilla. Kaufman pressionou Diamond nesse ponto, questionando a decisão de bloquear um grupo potencialmente grande de usuários. A resposta de Diamond trouxe à tona a distinção entre aplicativo e site.

“Oddpost não é uma página web, é um aplicativo de software [ênfase adicionada]. As páginas da Web, sejam dedicadas a festas do pijama totalmente sem pijamas ou à Declaração dos Direitos do Homem, apresentam informações, e há uma crença sólida e amplamente aceita de que as informações devem estar disponíveis para todos... Aplicativos de software, por outro lado, são ferramentas, e é um absurdo aplicar a elas o padrão de liberdade de informação da web. Além disso, os aplicativos de software, com toda a incrível sofisticação que esse rótulo implica, exigem custos e esforços tremendos para serem desenvolvidos para qualquer plataforma única. Para aplicativos da Web como Oddpost, os padrões do W3C atenuam, mas absolutamente não negam essa verdade. Este é um ponto que muitas vezes temos que fazer, mas nunca para alguém com um mínimo de experiência em aplicativos da Web entre navegadores.

Em sua resposta, ele evocou um argumento familiar. Embora os aplicativos da web fossem possíveis na web, Diamond argumentou, os aplicativos da web não estavam necessariamente disponíveis para todos os usuários da web.


Essa entrevista gerou outra rodada de conversa, vários anos após o lançamento do BrainMatter. Uma resposta, de Joyce Park, do Dojo Toolkit, afirmou claramente . “Na minha experiência, leva pouco tempo marginal para fazer algo funcionar tanto no Mozilla quanto no IE… E embora o número geral de usuários não-IE seja pequeno, a porcentagem de primeiros usuários de tecnologias baseadas na web dentro desse grupo é super alta … então você pensaria que o plano de negócios para algo como Oddpost precisaria levar isso em consideração.”


E isso geralmente está no centro do debate. O esforço marginal do suporte entre navegadores é um pré-requisito e não uma opção? A abertura da web é algo tão intrínseco, tão fundamental, que não pode ser ignorado. Ou estamos amaldiçoados por ter uma versão da web que vive na vanguarda, com exclusão de alguns, na tentativa de oferecer experiências que ninguém pensou serem possíveis. Essas perguntas permanecem sem resposta, mas uma coisa é certa. Eles definitivamente serão questionados novamente.


Fontes


Publicado pela primeira vez aqui .