5 razões pelas quais JavaScript pode ser a próxima grande linguagem

October 30th, 2007 § 19 comments § permalink

Há sempre uma grande quantidade de especulação sobre qual a próxima linguagem que ganhará as mentes e corações dos desenvolvedores. As apostas atuais muito provavelmente tendem na direção do Ruby.

Considerando o sucesso que o Ruby on Rails está experimentando atualmente, eu também me sinto tentado a dizer que Ruby é a próxima grande linguagem. Ruby tem a história perfeita: virtualmente desconhecida em sua primeira década de vida, surgiu com uma estrela no cenário atual de programação, graças a uma killer app cujo mindshare não para de crescer.

Ruby é, através de Rails, responsável pela aceitação de linguagens dinâmicas como ferramentas possíveis na atualidade. Alguém poderia argumentar que a atual revolução dinâmica aconteceria com ou sem a presença do Ruby. Eu tenho que discordar: o sucesso do Ruby fez com que o passo de pesquisa e experimento em linguagem alternativas aumentasse em uma ordem de magnitude nos últimos dois anos. Eu acompanho o cenário de desenvolvimento há mais de uma década e foi somente após a explosão provocada pelo Rails que o cenário mudou.

Ainda assim, eu acredito que Ruby não será a próxima grande linguagem. A despeito de desenvolvimento como JRuby e IronRuby, o lugar no topo não está garantido para essa bela linguagem.

Esse lugar, eu acredito, pertence ao JavaScript.

Se o JavaScript se tornar a próxima grande linguagem, um ciclo completo estará formado. Uma linguagem que nasceu para transformar a parte cliente da Web e sofreu uma queda ignóbil, sendo considerada por anos algo que somente merecia a atenção de candidatos a programadores, está ressurgindo agora com uma fênix, elevada ao panteão de linguagens sérias e merecedoras de atenção.

Aqui estão cinco razões pelas quais JavaScript pode se tornar a próxima grande linguagem tanto no lado cliente quanto do lado servidor das aplicações modernas:

Razão #1: A similaridade com C e Java, simplificada

A verdade é dura: C ainda desfruta de uma enorme popularidade e influência do uso e desenho de linguagens. E com a ascendência do Java, a sintaxe do C se tornou ainda mais dominante. Por si só, isso já é um motivo para garantir uma certa medida de popularidade ao JavaScript.

Mas o motivo real está no fato de que JavaScript simplifica a sintaxe do C e do Java a um nível palatável para o desenvolvedor médio. O uso de características dinâmicas fala mais alto do que qualquer coisa. Se há um ponto em que o Java falhou foi aí: se Java tivesse gerado algo como o Groovy no seus dois primeiros anos e tivesse convertido isso na linguagem padrão para applets, a história da Web teria sido completamente diferente.

Um garbage collector funcional ajuda bastante. Como o Ruby e Python provaram, não é preciso controle granulado sobre alocação de memória para criar programas complexos.

A única desvantagem real do JavaScript, no que tange à sintaxe, pode estar no fato da mesma ser baseada em protótipos e não em classes. Isso deve mudar com o JavaScript 2, mas a decisão final dos desenvolvedores quanto a isso ainda está no futuro. Até o momento, o uso de protótipos não está freando a linguagem, embora esteja limitando determinados usos.

Razão #2: A plataforma é a Web

Não há nada mais ubíquo do que código fonte HTML. JavaScript segue a mesma direção. A despeito de minimizadores de código e obfuscadores, a vasta maioria do código JavaScript em uso atualmente está disponível para adaptação e incorporação em aplicações. De editores de textos ricos a plataformas completas de construção de interfaces passando por bibliotecas utilitárias, há uma enorme quantidade de código documentado e acessível.

Esse código, além de tudo, roda em uma plataforma aberta e extremamente acessível, que é a própria Web. Isso dá ao JavaScript um grau de liberdade em termos de experimentação que não está disponível a basicamente nenhuma outra linguagem. Com o crescimento de ferramentas de apoio, o custo de desenvolvimento inicial está caindo até um ponto em que qualquer programador pode se dar ao luxo de desenvolver aplicações mais complexas sabendo que terá suporte amplo para isso.

O fim das grandes diferenças de compatibilidade entre os vários navegadores também está contribuindo para que a Web se estabeleça cada vez mais como uma plataforma sólida para aplicações suficientemente sofisticadas que se confundem com o desktop

E um último ponto: o JavaScript está intrinsecamente mesclado em duas arenas que paralelizam a Web.

A primeira dessas arenas é a de aplicações ricas na forma de tecnologias como Adobe Air e Siverlight. Essas plataformas não só estão adotando o JavaScript como ferramenta primária como estão também aumentando o seu passo de desenvolvimento, oferecendo melhores interpretadores e compiladores.

A segunda arena é a de aplicações offline. Com o aumento de aplicações com o serviço, o uso de uma linguagem comum é necessária para aplicações que queiram deixar o confinamento do navegador e se tornarem cidadãs de um desktop extendido. JavaScript já é a linguagem candidata perfeita para isso.

Razão #3: Ajax

Não só a Web é a plataforma, mas o uso de Ajax está trazendo toda uma nova comunidade de desenvolvedores para o JavaScript. O Ajax está fazendo hoje o papel que o view source fez na Web de dez anos atrás.

Enquanto antigamente o JavaScript era relegado a funções como criar rollovers, simular transições e efetuar procedimentos minimalísticos similares em aplicações Web, aplicações atuais rotineiramente carregar centenas ou milhares de kilobytes de JavaScript para transformar a experiência do usuário.

Hoje espera-se que um desenvolvedor saiba utilizar plenamente JavaScript em suas aplicações. Seja qual for a linguagem que ele use para desenvolver–Ruby, Python, C# ou Java–uma linguagem permanece constante: o JavaScript.

Como é improvável que outras linguagens ganhem utilização em um navegador, a tendência é que o JavaScript se torne cada vez mais adaptada a criar uma experiência completa de desenvolvimento e execução em um ambiente que não ficará nada a dever aos atuais O Ajax está fazendo hoje o papel que o run-times.

Razão #4: Protocolos e ferramentas

JSON é hoje basicamente um padrão de transmissão e transformação de dados na Web. Compacto e compactável, substituiu rapidamente o XML como protocolo de transporte e tem liderança indiscutível por estar baseado na única linguagem cliente disponivel.

Esse desenvolvimento, apoiado em outros como o CouchDb estão dando ao JavaScript uma legitimidade enorme em termos de aplicação real. Nem mesmo o mundo corporativo foi capaz de resistir à mudança desencadeada por esse pequeno protocolo e, atualmnte, transformações baseadas em JavaScript são comuns. Tecnologias como o CouchDb, com sua integração direta ao JavaScript e com um uso eficiente e lógico de uma arquitetura REST só trazem benefícios à linguage.

Além disso, ferramentas e ambientes de desenvolvimento mais sofisticados estão proliferando. Ambientes de desenvolvimento estão intrinsecamente ligados ao sucesso de uma linguagem–isso, inclusive, é algo que a comunidade Ruby está percebendo agora. Esses ambientes fornecem um trampolim para desenvolvedores inexperientes e uma base sólida para desenvolvedores já experimentados.

Esse tipo de legitimização pode ser mais um dos passos que vai conduzir o JavaScript ao ponto em que outras linguagens igualmente dinâmicas não podem chegar.

Razão #5: Distribuição ubíqua

O JavaScript não está mais só nos navegadores. Como mencionado anteriormente, tanto o Adobe Air quanto o Silverlight incorporam funcionalidades baseadas em JavaScript–e de maneira muito significativa.

Mas a evolução do JavaScript não para aí. Máquinas virtuais stand-alone já existem e podem ser usadas para basicamente qualquer tipo de desenvolvimento necessário com JavaScript. A mera integração com o Java permite o acesso a uma quantidade enorme de bibliotecas que transformam o desenvolvimento de novas aplicações um passo trivial.

O processo atual de desenvolvimento do JavaScript está formando um círculo virtuoso de desenvolvimento que está colocando a linguagem em uma posição de franca ascenção. Desdobramentos como a liberação do Tamarin são avanços que repercutiram em breve na comunidade de desenvolvimento.

Olhando para a combinação acima, eu não duvido que em breve surja um framework Web baseado em JavaScript, funcionamente equivalente ao Rails ou Seaside, capaz de ser rodado em basicamente qualquer plataforma possível, dada a profileração do JavaScript, e com a capacidade de integrar-se intimamente com outras ferramentas baseadas em JavaScript. É só uma questão de tempo.

Conclusão

Prever o futuro é uma atividade essencialmente frágil. Mas especular sempre é interessante quando o passo de modificações em uma determinada área parece chegar em um certo nível onde tudo parece posssível. Esse é o caso do JavaScript agora, em minha opinião, e as cinco razões acima são uma reflexão desse pensamento.

Eu volto então à minha aposta: e se eu tivesse que apostar agora, eu apostaria no JavaScript.

Screencast: Configurando um ambiente para o Seaside

September 4th, 2007 § 11 comments § permalink

A pedidos, gravei um screencast mostrando como fazer a configuração básica de um ambiente Squeak e como começar o desenvolvimento com o Seaside.

Você pode baixar em dois formatos:

É um vídeo bem básico, mas acredito que ajuda um pouco no sentido de pelo menos indicar o proverbial caminho das pedras para o desenvolvimento Seaside.

Peço desculpas antecipadas por qualquer erro grosseiro verbal, mental ou similar no vídeo: ja atribuo a culpa antecipada ao horário. E antes que alguém pergunte, sim, o som ficou baixo–aumente um pouco para conseguir escutar.

Quaisquer dúvidas, fiquem à vontade para postar nesta entrada e eu tentarei responder.

Palestra Seaside disponível

September 3rd, 2007 § 4 comments § permalink

A gravação da palestra que eu dei no último sábado sobre Seaside já está disponível no site da e-Genial. No momento, você pode baixar a apresentação em formato SWF, mas logo ela estará disponível também via streaming.

Se você assistiu a palestra e tem alguma dúvida, fique à vontade para usar esta entrada como área de perguntas. Prometo tentar responder todas, embora talvez não imediatamente.

Palestra sobre Seaside no sábado

August 29th, 2007 § 2 comments § permalink

Só para lembrar os interessados, a palestra que eu vou dar sobre Seaside acontece no sábado próximo às 14h:30 (horário oficial).

Como mencionado anteriormente, a mesma será feita usando a estrutura do TreinaTom e basta acessar o site do evento do dia para entrar no ambiente.

Vídeos da maratona de palestras

August 23rd, 2007 § 3 comments § permalink

Os vídeos da maratona de palestras promovidas pela e-Genial no sábado passado já estão disponíveis para download e streaming direto.

São oito palestras diferentes com aproximadamente uma hora de duração com tópicos bem diversos e interessantes. Vale a pena dar uma conferida.

Palestra de linguagens de programação hoje

August 18th, 2007 § 1 comment § permalink

Só lembrando os interessados, a palestra sobre linguagens de programação que eu vou dar no ciclo de palestras da e-Genial é hoje.

O que você queria saber

July 2nd, 2007 § 6 comments § permalink

Como mencionado aqui alguns dias atrás, o Eduardo Fiorezi me convidou para uma entrevista em seu Tudo que Quero Saber. Batemos um papo longo na sexta-feira passada e o resultado está no oitavo episódio do podcast.

Falamos de Rails, CakePHP, Seaside e um série de outras assuntos que estão mudando a área de desenvolvimento Web. Como eu temia, o sotaque mineirês ficou patente até para meus próprios ouvidos–eu não tinha idéia de que eu cortava tanto as palavras. De qualquer forma, espero que vocês gostem. :-)

O que você quer saber?

June 19th, 2007 § 0 comments § permalink

O Eduardo Fiorezi me convidou para o próximo episódio do Tudo que Quero Saber, que, para quem não conhece, é um podcast entrevistando várias figurinhas da comunidade de programação do Brasil sobre assuntos que cobrem basicamente toda área.

As entrevistas já feitas foram excelentes e me sinto realmente honrado de participar. A idéia é falar de Rails, CakePHP, Seaside e tudo o que pudermos relacionado a estes frameworks que estão mudando a área de desenvolvimento Web. Se você tem perguntas, mande para o Eduardo. Só não se importem com o sotaque mineirês depois.

Phaux

April 25th, 2007 § 4 comments § permalink

Pelo visto, as heresias estão começando a se espalhar no mundo de desenvolvimento Web. A novidade é o Phaux, um framework parecido com o Seaside para PHP, que como este último, abstrai as particularidades desnecessárias trazidas da camada mais baixa que é o HTTP.

Para exemplos, veja o contador e o teste de formulário, que são bem parecidos com o que seria feito em Seaside. Vale a pena dar uma conferida.

Desenvolvendo heresias

March 9th, 2007 § 7 comments § permalink

Avi Bryant, criador do Seaside, o framework to rule them all, escreveu ontem uma entrada interessante em seu blog sobre as heresias frameworks para desenvolvimento Web não tem coragem de cometer, mesmo os mais modernos como o Django e o Rails.

O argumento de Bryant é que o conhecimento utilizado para criar todos esses frameworks é baseado em decisões que faziam sentido há décadas atrás mas que realmente não possuem mais validade em nosso contexto atual de desenvolvimento. Esse é um argumento que faz muito sentido e com o qual eu concordo bastante.

Recentemente, os desenvolvedores por trás do Rails gastaram meses introduzindo suporte a REST no mesmo, suporte esse que, além de complicar a vida do desenvolvedor (é a primeira vez em que eu vejo uma funcionalidade no Rails que está no lado oposto da regra 80/20), é baseado em premissas um tanto ou quanto duvidosas, como, por exemplo, uma necessidade de particionar o fluxo de uma aplicação Web em pequenos itens de funcionalidade que sejam mais gerenciáveis pelo desenvolvedor. Essa premissa vem de um raciocínio circular causado pela falta de estado no protocolo HTTP que faz sentido para o protocolo mas que não faz o menor sentido para aplicações Web. O resultado é uma luta entre os desenvolvedores e o protocolo que se traduz em decisões nas bibliotecas de desenvolvimento que tentam burlar o fato de que a base toda está errada.

Rails, Django, CakePHP e similares funcionam porque existe uma necessidade intermediária de aplicações que é suprida pelas decisões comuns de simplicação tomadas por esses frameworks. Os desenvolvedores agradecem, é claro, mas, para a maioria das aplicações, há sempre uma lista daquilo que deve ser feito que difere do comum quando a situação realmente começa a se deslocar para o mundo real. Isso não quer dizer, é claro, que esses frameworks não funcionem. Ao contrário, eles são um passo necessário para que as heresias, como Bryant as chama, comecem a se tornar dominantes.

Heresias sempre foram o foco de avanço em qualquer área do pensamento humano. E não vai ser diferente no desenvolvimento Web.

Where Am I?

You are currently browsing the Seaside category at Superfície Reflexiva.