A central de whitepapers de tecnologia da COMPUTERWORLD
Tecnologia
Apostar apenas em JavaScript para aplicações web é um erro?
Para o blogueiro e desenvolvedor Neil McAllister, a padronização em uma única linguagem é uma atitude arriscada.
Infoworld, EUA
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?
Cloud computing é difícil?
O ITBOARD materializa a nova plataforma de conversas do Século XXI. Concentra o diálogo sobre tecnologia e inovação movido a tweets de quem está imerso nesses assuntos. ENTRE NA CONVERSA
