Para o blogueiro e desenvolvedor Neil McAllister, a padronização em uma única linguagem é uma atitude arriscada.
Quanto mais eu ouço sobre a revisão dos padrões líderes de
web, cada vez mais fico convencido de que não estamos olhando as aplicações web
da maneira certa.
A última movimentação envolve o ECMAScript, padrão
internacional que forma a base da linguagem JavaScript. Recentemente, o comitê
responsável pela linguagem votou pelo abandono
do padrão ECMAScript 4, favorecendo um revisão muito menos ambiciosa, o ECMAScript
3.1.
Se o trabalho tivesse continuado, traria grandes mudanças.
“Programar, de maneira geral, tem sido um problema com linguagens com tipagem
dinâmica (untyped) como JavaScript,” disse Ed Rowe, diretor de engenharia
da Adobe. “É por isso que a Adobe trabalhou no ECMAScript 4… para
introduzir conceitos que são compatíveis com a construção de aplicações de
larga escala.”
> Você conhece o framework gratuito para JavaScrip Prototype?
Mas, mesmo que aplicações de larga escala pareçam boas para Adobe,
isso não é interessante para todos. A história das linguagens tradicionais de
programação de sistemas é uma grande evidência disso.
Para cada metódico e disciplinado programador em Java existe
um hacker em Perl que prefere fazer tudo ‘de ouvido’. Um forte typing, pacotes
e namespaces tornam a manutenção de grandes aplicações mais fácil, mas são
praticamente inúteis para um desenvolvedor web.
Na verdade, o conceito em si de uma linguagem de programação
para todas as necessidades é questionável.
Veja um exemplo. Um grupo de pessoas muito inteligentes que
se reuniram para criar a especificação da melhor linguagem de programação que
já existiu. Era segura, robusta, e tão padronizada que não sobrava nada para
interpretação.
Você se lembra da Ada? Não? Isso provavelmente por que, uma
vez que as especificações ficaram disponíveis, a linguagem era tão restrita e
sem flexibilidade que a maioria dos programadores preferiu codificar em C.
Como ninguém foi capaz de criar a melhor linguagem de
programação para sistemas, por que gostamos de pensar que é possível fazer isso
para a web? Quanto mais falamos sobre criar aplicações web de larga escala, mais
deveríamos perceber que um único estilo de programação não vai resolver todos
os problemas.
Sou fã do modelo de desing Model-View-Controller. Não
funciona para tudo, mas serve como um guia importante para o processo de
criação de uma aplicação. Em um nutshell, um dos desafios principais está em
separar a View – a apresentação dos dados – dos dados em si mesmos (o Model) e
a lógica que os manipula (o Controller).
Então, uma idéia: A janela do seu navegador é a View. Talvez
seja a hora de parar de forçar para que seja também o Controller.
Desde o início dos navegadores já havia o JavaScript. Com o
passar dos anos, nós exigimos mais e mais dele até chegar ao ponto de que
discutimos agora sobre usar o JavaScript para construir aplicações inteiras. A
verdade é que o JavaScript nunca vai ser bom para todas as coisas.
Mais do que atochar mais e mais funcionalidades dentro do
navegador (e passando por todos os procedimentos de padronização que isso exige),
talvez seja o tempo de separar a UI da lógica client-side. Deixe o browser lidar
com a View. Deixa o Controller existir em qualquer outro lugar.
Já existe uma maneira de garantir essa separação: plug-ins
de browser. Claro, a maioria dos desenvolvedores web diz que plug-ins são ruins.
Toda vez em que um usuário é forçado a baixar e instalar um plug-in, dizem, você
joga um monte de entulho na frente do seu código. Mas isso é verdade?
Os primeiros plug-ins para browser foram criados para
entregar conteúdo multimedia. Eles viraram rapidamente veículos para marketing online.
O moderno contra-exemplo é o Google Gears. Instale o plug-in
Gears uma vez e cada aplicação que possui o Gears ganha toda a funcionalidade. Até
agora, a lista de sites inclui o Google Docs, Google Reader, MySpace, Picasa e WordPress
blogs.
O Gears faz mais do que permitir que aplicações web sejam
usadas offline. O módulo WorkerPool
permite que código em JavaScript rode no background, independente do
código na página principal.
Mas, por que JavaScript? Por que não Python, Lisp ou outra
nova linguagem alternativa para aplicações web? Se a aplicação é interessante o
suficiente, o incentivo para instalar um plug-in é alto – especialmente agora
com banda larga.
Já existe um módulo externo de browser capaz executar a
maioria das propostas do ECMAScript 4: É o Adobe Flash plug-in. Outras
plataformas estão disponíveis como plug-ins, incluindo Curl e REBOL.
A tendência é evitarmos essas alternativas. Como é um padrão
da web, nós repetimos para nós mesmos, JavaScript é a opção mais pura.
Mas se queremos ter uma única maneira de fazer as coisas,
por que estamos reinventando a roda? Nós já temos um cliente multipropósito que
é capaz de atuar como front end e em uma grande variedade de aplicações, de
banco de dados até e-mail. Está instalado em milhares de empresas no mundo hoje.
É chamado Lotus Notes.
É neste sentido que estamos indo? Será esse o modelo para o browser
do futuro? Ou é tempo para a comunidade de desenvolvedores web começar a pensar
fora da caixa?
