Dúvida da semana: O que são tecnologias para a Web?

Obs: Este é mais um post imenso feito por alguém sem ter mais o que fazer.

Web. Web. Web.

Afinal, o que é desenvolver uma aplicação para a Web? Aliás, muitos me perguntam qual a diferença entre um site e um sistema na Web. Me envergonho de não saber lhe dizer.

Primeiramente é necessário saber o que é um sistema. Daí saber diferenciá-lo de um site.

Web. Web. Web.

Hoje em dia muitos sites são sistemas. Não são só uma ou mesmo várias páginas, estáticas. Um sistema precisa ter uma lógica. Talvez até uma certa dose de interação com o usuário.

Web. Web. Web.

Não sou um bom programador, admito. Sou do tipo que quer conhecer um pouco de tudo, mas que no fim não sabe nada de nada. E nos últimos tempos me vi na missão de criar sistemas que o usuário acessasse pelo navegador, o que faz com que seja um sistema na Web. Logo eu, que mal HTML sabia! :-)

Mas esta não é a questão. Web. Web. Web.

Nestes dias, estou fazendo um mini-curso de programação em Flex. O nome Flex não é muito bom, já que é algo muito comum. Até carro hoje em dia é Flex. Se não me engano já havia uma aplicação chamada Flex, e se você usa Linux ou outro Unix, execute man flex para saber do que se trata.

Mas o flex aqui é o da Adobe. Trata-se de uma linguagem baseada em XML para criação de aplicações ricas para a Internet (RIA). A sintaxe é similar à XML (na verdade é XML! :-)) para a parte de layout e Action Script para a lógica da aplicação. ActionScript é um irmão do Javascript, e ambos usam a mesma sintaxe (ECMAScript).

Aqui já entra um novo conceito, que não é nem site nem sistema. Agora temos aplicação. Não sei o que é uma aplicação.

Enquanto tanto um site quanto um sistema têm toda sua lógica num servidor e só o visual no cliente, com as RIA a lógica está no cliente – o que não significa que não exista lógica no servidor. Este é o grande trunfo das RIAs: fazer com que o sistemas para Web não tenham mais aquela cara de “site”. No fim das contas a impressão que temos é de aquele sistema, rodando dentro do navegador, é mais uma aplicação instalada no computador, mas rodando dentro do navegador.

Ok (Web, Web, Web), tudo isso é conceito. O conceito é lindo. Volto ao Flex.

Flex é a coisa que mais ouço falar entre colegas de sala. “Porque Flex é fácil”. “Porque Flex é produtivo”. E realmente é! Minha nossa, Flex é fácil e produtivo.

Quem me conhece sabe que eu odeio Flash. Não, não o Herói da DC Comics. A plataforma Flash, da Adobe. E o Flex faz um uso exaustivo desta tecnologia. Flex é uma linguagem compilada: o compilador flex lê um ou mais arquivos MXML, converte (gera arquivos texto) Flash e em seguida usa o compilador Flash para gerar um arquivo binário SWF. Este arquivo SWF é então embutido num arquivo HTML e só aí vira uma aplicação Web. Na verdade pode ser executado num programa chamado Flash Player ou mesmo como uma aplicação Desktop, pelo Adobe Air.

Eis que me vi numa encruzilhada: Gostei muito do Flex mas não gosto de Flash. Frescura, eu sei.

Porque não gosto (é, odiar não é uma boa palavra) de Flash? Bem, talvez eu não odeie Flash. Trata-se de uma tecnologia maravilhosa. Nem ligo tanto o fato de ser proprietária. Há coisas que ainda são muito mais práticas de serem feitas em Flash do que noutra tecnologia. Eu mesmo acesso diariamente sites como o Charges.com.br, que fazem uso intensivo de animações em Flash. Talvez eu odeie a banalização da plataforma. Em que contexto? No contexto da Web, é claro!

Web. Web. Web. O que é uma aplicação que “roda na Web”? Primeiramente, não precisa ser instalada no computador do usuário. A aplicação simplesmente “roda”. Muitas empresas, tais como o Google, apostam nesta idéia. É a tar da computação em nuvem, tio.

A grande sacada do Flex é ter levado conceitos de aplicações para Desktop, como layout, menus, abas, widgets, containers para dentro de uma aplicação Web. Nada mais óbvio. A linguagem HTML ainda é presa à época onde sites não tinham cara de aplicações. Eram no máximo “sistemas”.

Mas o que é uma aplicação para Web? É algo que roda dentro do navegador, não precisa ser instalado, etc. Mas o que é rodar dentro do navegador? Há um plugin que permite abrir documentos PDF dentro do próprio navegador, sem a necessidade de uma janela externa. Aqui uso o Adobe Reader (é, é uma inhaca, demorado pra carregar, etc.). Também tem um plugin no firefox que abre o OpenOffice dentro da janela do navegador. Bem, os programas estão rodando dentro do navegador, mas precisaram ser instalados previamente. Logo não são aplicações Web.

O que é então rodar dentro do navegador? Quando você entra num site com um quadro em Flash, o seu navegador lê e interpreta um arquivo de texto. Este é o HTML. Depois, nos espaços para animações Flash, carrega um programa externo (um player) que se encarrega de interpretar o conteúdo daquela animação, naquele local pré-definido. Aí já não é mais problema do navegador, que nem precisa saber o conteúdo do objeto (normalmente um arquivo binário), embora ainda tenha de interagir de algumas maneiras.

Neste caso, uma aplicação em Flash (que pode ter sido feita no Flex) está rodando no navegador ou está rodando como o Adobe Reader no caso acima? Bem, está rodando dentro do navegador e a aplicação dentro da tag object não está instalado no computador. Acho que é sim uma aplicação para a Web.

Web. Web. Web.

Mas tem um problema: o navegador não tem o controle sobre aquilo que está rodando lá dentro, no caso do Flash (ou mesmo SilverLight ou JavaFX ou um Applet Java). O próprio plugin Flash é algo que deve estar previamente instalado para que o usuário execute aquela aplicação em Flash. Mas isto não invalida uma aplicação em Flash, já que para que uma aplicação Web rode é necessária a instalação prévia de um navegador. Um plugin, neste caso, é uma máquina virtual, e está para aplicação Flash assim como o sistema operacional está para um editor de texto.

Mas para que esta minha implicância e enrolação? Eu sou do tipo chato que acredita que os padrões web estão aí para serem seguidos. “Oh! Mais um escravo do sistema”. Não. Não só seguidos: Seguidos e melhorados.

Flash e outras linguagens vieram para tapar muitas limitações do HTML padrão. Só de uns anos para cá as grandes empresas e comunidades por trás dos padrões Web tem tomado iniciativas para acabar com tais limitações. Ai entram coisas como SVG, HTML5, CSS3, XHTML2, que ainda não, por si próprias, são capazes de prover tudo que as outras tecnologias baseadas em plugins oferecem.

O compilador Flex é open source. Senão me engano o compilador Flash que ele trás também é. Open Source é a nova moda. A Adobe liberou há um tempo as especificações dos arquivos SWF para terceiros. Isto em teoria permitiria a existência de FlashPlayers alternativos. Os únicos que eu conheço são o Gnash e o Swfdec.

Um programa “executável” em Flex é um arquivo comum do Flash, mas com um uso intensivo, mesmo que não declarado pelo programador, de código Action Script 3.0 (AS3). A maioria das aplicações em Flash hoje em dia usam uma versão anterior desta linguagem. Como resultado, hoje em dia o Gnash e o SwfDec são capazes de entender boa parte dos programas em Flash existentes na Web. Mas ainda não suportam AS3. Não se a especificação do ActionScript 3 é pública, tenho que pesquisar mais.Como resultado, não há como executar programas em Flex fora do player da Adobe. O compilador do Flex é open source, mas o runtime (a máquina virtual, o player) não.

A questão é: faria diferença se fosse open source? Muita gente confunde tecnologias abertas (tal como (X)HTML) com código aberto. Como HTML não é um código, mas sim uma linguagem, que é por definição implementável independente de sistema operacional, navegador, arquitetura de processador, dispositivo, etc., não existe relação entre ser uma tecnologia aberta e ser de código aberto. Por conseqüência, o fato de uma implementação de uma linguagem ser de código aberto (como o Moonlight, versão open source do Silverlight e o Gnash e SwfDec) não faz com que ela seja uma tecnologia aberta.

No caso oposto, é perfeitamente viável a existência de implementações de programas que interpretam HTML/JS/CSS, mas são proprietários. Exemplos? Navegadres como Safari (embora sua engine seja LGPL), Internet Explorer, Opera.

A próprio Google, empresa que investe pesado nos padrões Web, percebe a falta de recursos na tecnologia padrão e cria coisas como o O3D, uma API para a criação de aplicações 3D interpretadas pelo próprio navegador.  Mas, como se trata de algo além do alcance dos navegadores, é implementado na forma de um plugin, embora seja acessível pelo mesmo código javascript. Não é uma API padrão, mas já abre espaço para a futuras revisões do WebGL, esta sim definida como padrão Web. Mas o plugin do Google por enquanto é preso à plataforma Intel 32bit e limitado à certos navegadores e sistemas operacionais. Eu mesmo não consegui rodar numa distribuição 64 bit.

É uma tecnologia experimental, e o Google sabe disso. Tanto que nunca vi nenhum site em “produção” que o utilizasse. Mas certamente influenciará o próprio WebGL e outras tecnologias que estão por vir.

Por falar em WebGL, o WebKit (do Chrome, Safari, etc), e Firefox já estão começando a implementar o WebGL, embora só nas versões em desenvolvimento.

É claro que estes argumentos (quais?) não são suficientes para convencer alguém a usar padrões abertos. Tentarei falar das vantagens dos plugins proprietários. Vou dar como exemplo o Flash.

Flash é uma tecnologia proprietária da Adobe. É uma tecnologia consolidada e o plugin que executa Flash talvez esteja, assim num chute, em 95% dos computadores do mundo. Ou seja, criar uma aplicação em Flash te dá certeza de que irá funcionar em praticamente todos computadores do mundo. É uma tecnologia repleta de recursos, tanto que é referência e preferência da maioria dos desenvolvedores de RIAs. Com Flash é fácil fazer coisas hoje impossíveis com padrões Web, como por exemplo aplicações de video-conferência pela Internet, já que é capaz de acessar a câmera, microfone e sistema de com do computador. As versões mais recentes suportam aceleração gráfica por hardware e o plugin oficial está disponível para os sistemas operacionais mais utilizados (embora restrito à no máximo duas arquiteturas de processador).

Hé tecnologias como Flex que trabalham “em cima” do Flash, facilitando a vida dos desenvolvedores.

Existem outras tecnologias para criação de RIAs, como o Silverlight e o JavaFX, mas não tentarei falar deles, já que pouco conheço. Mesmo do Flash posso falar com mais autoridade somente como usuário, pois não estou familiarizado com desenvolvimento usando ele em si. Mas alguns dizem que o Silverlight é muito melhor que Flash, e é provável que seja mesmo (alguns até dizem que flash e silverlight não são a “mesma coisa”, e provavelmente estão certos).

Aqui entra a dúvida: o que é melhor? Como eu disse, as tecnologias proprietárias hoje fazem muito mais que o conjunto de tecnologias definidas atualmente como padrão Web. Programadores Flash dizem que Flash é o máximo em perfeição, já que faz tudo que eles precisam. Embora Silverlight seja recente, aqueles que a usam dizem ser o máximo. Os defensores dos padrões Web frequentemente são tratados da mesma forma que os “xiitas” do software livre. Para que se prender à algum limitado como os padrões Web se podemos ter algo melhor, que são as tecnologias proprietárias citadas?

Não quero misturar padrões abertos com código aberto, mas abrirei um “parentis”.

Sobre a questão do que é melhor ou não, vou fazer uma referência ao “guru” do Software Livre, Richard Stallman, que diz que um software livre SEMPRE é melhor que um software proprietário, mesmo que seja tecnicamente inferior. Para ele, qualquer software livre, mesmo que não funcione muito bem, é melhor do que um proprietário que faça mil maravilhas, já que qualquer coisa é melhor que ser escravo (software proprietário). Mas é possível ir mais além, já que um software livre pode ser melhorado sempre, mesmo que nunca chegue ao nível de uma determinada aplicação proprietária. Exemplos aqui são desnecessários.

É claro que é muito fácil discordar dele, e a maioria certamente o faz. Paira no ar então outro cheiro, que ao meu ver é o essencial da história toda: Potencial X Recursos.

O que Stallman acredita para o software livre e que os defensores dos padrões Web acreditam para o desenvolvimento na Web é no potencial de uma tecnologia padrão e não necessariamente no que ela provê no momento.

Já tecnologias proprietárias normalmente se baseiam no que o usuário-desenvolvedor precisa no momento e oferece à ele. Oferece recursos, deixando um pouco de lado a potencialidade da tecnologia. Por isso que, onde as pessoas precisam de algo “para ontem”, opta-se por tecnologias proprietárias.

Hoje a especificação do HTML5 ainda está em estado de rascunho. A do WebGL, idem. Enquanto em Flash acessar a WebCam do usuário é padrão da linguagem, os desenvolvedores do HTML5 ainda estão pensando na especificação dos métodos para tal tarefa.

O documento do HTML5 está previsto para sair como revisão final e estável em 2022 (!!!, mas o rc1 sai em 2012), enquanto Flash e Silverlight hoje “fazem tudo” que o HTML5 pretendem fazer em 2012, e é provável que quando o HTML5 saia, estas tecnologias proprietárias estejam mais avançadas. CSS3? Sem previsão de um documento estável. Para que esperar mais de uma década se posso ter para hoje? Não sei.

Como não existe um documento padrão do HTML5/CSS3, os desenvolvedores dos navegadores improvisam, baseados nos rascunhos dos respectivos documentos, recursos para os navegadores atuais. E isto gera alguns problemas de incompatibilidades.

Em CSS, existem os chamados estilos proprietários, que funcionem em determinados navegadores. Aqui não importa se são código-aberto ou não. Atributos de estilos iniciados com -khtml são para o Konqueror, do projeto KDE. Os iniciados com -webkit para os baseados em WebKit, os iniciados em -moz para Gecko (Firefox, SeaMonkey, etc.), e os iniciados em -opera para Opera. Resultado: enquanto que, por exemplo, CSS3 defina que um elemento possa ter uma borda arredondada, existe um atributo diferente para cada um destes tipos de navegadores. E ainda há o fato como WebKit suportar formas mais avançadas de atribuição de bordas.

Por que isso acontece? Pois enquanto que, em tecnologias proprietárias a empresa que cria o plugin define a API da linguagem, as tecnologias abertas são feitas “ao avesso”. Ou seja, os navegadores implementam determinados recursos, mais ou menos previstos na linguagem, e dependendo se forem bons ou não, podem ser incluídos na especificação. Aí é implementado em todos os navegadores. Porque? Pois quem desenvolve os padrões não é uma empresa, mas um consórcio de empresas, instituições e comunidades interessadas. Assim quem está por trás do HTML5 são empresas como Google e Apple. O próprio recurso Canvas, talvez uma das maiores inovações do HTML5, surgiu inicialmente no navegador Safari, da Apple, e foi depois incluído na especificação da linguagem.

Mas há gente que não sabe brincar e cria coisas como behaviors e ActiveX, ambos tecnologias do navegador Internet Explorer.

O problema disso é a falta de segurança em se utilizar hoje HTML5 quando não se tem certeza de sua cara em 2012. Não existe exatamente um “chão para pisar”, como acontece com tecnologias proprietárias. Mas, ao contrário destas, padrões abertos não podem mudar “de uma hora para outra”, o que faz com que o acesso à um objeto de vídeo hoje não será muito diferente do método de acesso final.

Penso que o HTML é a “linguagem de máquina” da Internet. Ou seja, assim como hoje, embora seja possível escrever aplicações pra computador usando Assembly ou mesmo linguagem de máquina, a maioria das pessoas não acha isso produtivo. Por isso são desenvolvidas linguagens, frameworks, etc., em alto nível e com facilidades para o usuário, mas que no fundo usam a linguagem de máquina. Da mesma forma vislumbro que no futuro quem quiser criar uma RIA com Ajax poderá escrever “em baixo nível”, usando a API do HTML5, mas que terão à sua disposição frameworks e linguagens em alto nível, como OpenLaszlo, Jquery, AmpleSDK, etc.

Fazendo uma referência à este último, AmpleSDK, trata-se de um framework para desenvolvimento de aplicações ricas para Internet baseado em padrões Web. Até um tempo atrás era proprietário, mas hoje seu código é aberto. Uma das coisas engraçadas que ele faz, embora ainda não de maneira completa nem 100% compatível, é implementar a linguagem XUL para aplicações Web.

XUL é uma tecnologia proprietária (mas software livre) desenvolvida pela Mozilla há vários anos, mas ainda hoje muito utilizada em seus produtos. É em teoria uma linguagem de construção de Interfaces. Usa sintaxe XML e oferece ao usuário recursos para a construção de Interface tais como widgets (botões, menus, sliders, etc.), containers (hbox, vbox, etc.). Hoje o produto que faz uso do XUL mais famoso é o Firefox e suas extensões. O programa que estou usando para escrever este post foi inclusive escrito em XUL (scribefire).

Outras tecnologias como o XUL são o Flex e o XAML, da Microsoft.

Ah sim, voltando ao AmpleSDK, o que ele faz é, num elemento script num documento HTML, interpretar, pelo próprio Navegador, código XUL, gerando uma interface em HTML. A Interface deve fazer um uso intensivo de elementos como imagens, divs e tabelas, mas o código desenvolvido pelo usuário é XUL puro.

Na verdade estas linguagens (XUL, Flex e XAML) são no fundo o mesmo XML, e XHTML suporta a mesma sintaxe que elas. Logo não deve ser muito bizarro pensar que uma implementação do Flex que gera, ao invés de um objeto SWF, uma página (ou várias) HTML. XML/XHTML suporta namespaces, o que torna esta ideia viável num futuro. Outras tecnologias para Desktop usam XML para descrever Interfaces, tais como Qt (os arquivos do Designer são XML) e Glade (muito usado em aplicações Gtk+). Não me parece inviável que no futuro não criem um “Qt4Web ou Gtk4Web”. Tá, foi viagem, confesso, mas não é inviável.

Hoje nem todos os navegadores suportam namespaces em XML, e posso citar um que eu testei e que pelo visto não suporta, que é o konqueror (khtml).  Um outro problema das tecnologias abertas é a inexistência de um framework ótimo que satisfaça todas suas necessidades. Certamente será necessário o uso de um ou mais frameworks/linguagens para a parte visual da aplicação, outra para a persistência de dados, outro para a lógica… Enquanto isso em Flash ou Flex está tudo num só lugar, pronto para ser usado.

Além do mais, o HTML, como linguagem “nativa” dos navegadores, não está restrita à funcionar num espaço limitado da página (mesmo que visualmente ocupe toda a tela da página). Sites como o Chrome Experiments mostram que as possibilidades são muito maiores, podendo haver mesmo interações entre diferentes janelas do navegador.

O problema é que isso exige uma visão à longo prazo. Tecnologias proprietárias conseguem satisfazer o imediatismo de muitos. Mas quanto mais se investe numa tecnologia proprietária, mais dependente dela você fica e mais complicado abandoná-la é.

Mas fica no ar outra questão: “Se não posso usar tecnologias proprietárias, como criar aquele sistema de VideoChat pela Internet que meu cliente necessita hoje, e não em 2012?”. Falar em “não poder” é radical demais. Eu simplesmente não sei responder esta pergunta. Todo este texto provavelmente não passa de um delírio meu. Fica a seu critério, meu amigo.

Mas porque implicar com Flash se não existe, por exemplo, um padrão de linguagem para a criação de aplicações para Desktop, por exemplo? Porque a sintaxe e os componentes do C++/Qt são diferente do C/Gtk+ ou C++/FLTK? Uma aplicação para Desktop é diferente de uma aplicação para Web, como eu comentei no começo deste texto. Minha aplicação em QT exige que o usuário tenha instalado no seu sistema operacional as bibliotecas e arquivos necessários, ou o instalador da minha aplicação pode vir com elas. Na Internet estas dependências, principalmente em se tratando de “linguagem de máquina”, são mais complicadas de serem resolvidas.

Isso torna Flash ruim? Nunca use? Absolutamente não! Se você está desenvolvendo um sistema para seu cliente, e tem certeza de que ele está usando o plug-in Flash em navegadores e sistemas operacionais compatíveis, não há “mal” algum em utilizá-las.  Seu cliente/usuário tem plena noção do que é necessário para que possa executar o sistema, assim como no caso de um programa para Desktop para Windows ou Linux.

Mas para uso na Web, para um público genérico, acredito ser uma péssima escolha utilizar estas tecnologias proprietárias. Por isso que digo que abomino sites em Flash. Para mim podem até funcionar (embora o plugin para Linux seja uma droga e trave toda hora), mas para alguém que esteja utilizando um sistema (computador, dispositivo, e-book, celular, geladeira) não suportado (quantos SOs existem no mundo? Dezenas ou centenas), numa arquitetura de hardware diferente, a visualização do site se torna inviável. “Mas esta pessoa não existe!”, mas sua existência é necessária.

Como disse acima, estou fazendo um curso de Flex. Um dos argumentos apresentados a favor do desenvolvimento de aplicações em Flex foi o fato de que funcionará igualmente em qualquer sistema que tenha o flash plugin. “Não tem que ficar se preocupando em fazer hacks para um navegador ou outro”, certamente fazendo referência ao Internet Explorer. É claro que este problema não existe, já que é uma tecnologia monopolizada por só uma (mono = um) empresa, enquanto HTML não é código, mas um documento, e quem implementa são os desenvolvedores dos navegadores. Isto gera concorrência (porque os desenvolvedores do Opera brigam tanto com a Microsoft?) justa entre desenvolvedores de navegadores, o que resulta em mais benefícios aos usuários: velocidade, estabilidade, etc. Algo que tecnologia proprietária alguma é capaz de prover.

Continuo pensando ser só uma questão de visão à longo vs. curto prazo. Mas que enjoa esperar até 2022 para ter HTML5 pronto, isso enjoa :-)

A resposta para todas estas questões? Eu sei, mas não vou falar pra ninguém! :-)

Ah sim. Web Web Web

Anúncios

2 Comments

  1. lokitakkk
    Posted dezembro 31, 2009 at 21:15 | Permalink

    ixi… muito grande, mas eu lerei.

  2. rafael
    Posted outubro 21, 2010 at 0:54 | Permalink

    parabéns!

    O Flex/flash é uma droga, só não pode viciar e virar dependente!

Comente

Required fields are marked *

*
*

%d blogueiros gostam disto: