Category Archives: Web Design

Eu e o Angular

Semana passada colocamos no ar a nova versão do /dev/All que mudou radicalmente sua arquitetura (detalhes não técnicos neste link): dentre as principais mudanças está o fato de que agora a interface com o usuário é um SPA. Este é o primeiro post no qual compartilho com vocês algumas das coisas que aprendi no processo.

Note que esta é a visão de alguém que tinha como ferramenta principal para o desenvolvimento de aplicações SPA o Vue.js. Sendo assim minhas impressões em sua maior parte fazem uma comparação com ele. Leve em consideração que são “novas novas impressões” a respeito do Angular. Muita coisa pode mudar conforme minha experiência progride.

Por que não gostava

Uma das principais razões pelas quais aprendi Vue.js, confesso, foi para não usar o Angular. Além do trauma da quebra de compatibilidade da versão 1 para a 2, naquele momento ele me parecia muito mais complexo do que eu precisava. E o fato da versão 2 ser essencialmente TypeScript e não mais JavaScript também me incomodava (que ironia, eu, que amo Grails, dizer isto…). Também me incomodava horrores a documentação oficial que peguei na época: era horrível.

Eu já havia experimentado o Angular em projetos legados e, acredito, isto contribuiu também para minha péssima impressão original do framework. Vue.js era para mim como um copo d’água para quem estava no inferno. O tempo passou e acabei dominando o Vue, que se tornou até agora minha ferramenta favorita para o desenvolvimento de SPAs, aplicações híbridas e qualquer projeto que envolvesse interatividade mais rica. Até agora.

Mas o grande lance é que minha visão a respeito do Angular estava errada. Enquanto o Vue é essencialmente focado na camada de visualização (e essencialmente apenas nela), não havia ainda atinado o Angular como um framework, mas sim como uma biblioteca.

Resumindo, minha aversão ao Angular era resultado destes fatores:

  • A documentação de anos atrás que era bem ruim.
  • O trauma da quebra de compatibilidade da versão 1 para a 2 do Angular (acaba que sempre penso nos projetos a médio e longo prazo).
  • O fato de se mostrar mais complexo do que minha real necessidade na época.
  • A adoção do TypeScript como linguagem e não JavaScript.
  • Eu estar ignorando o aspecto essencial do Angular: o deste ser um framework (este doeu) para aplicações maiores.

Por que estou gostando

O que me fez realmente gostar do Angular foi criar vergonha na cara e perceber que já havia passado da hora de aprender o framework a fundo.

Chegou um dia no qual quis finalmente transformar a interface do /dev/All em um SPA e me peguei adotando o Vue.js sem sequer me questionar a respeito. Por que apenas Vue.js estava no meu radar? Era hora de sair da zona de conforto, o que me fez passear pelo React e… Angular novamente.

Um bom livro e uma melhor documentação

Dado que a documentação oficial do Angular que conhecia até então era um lixo, optei por desta vez escolher um bom livro ao invés da documentação oficial, e acertei. Comprei o “Angular in Action”, de Jeremy Wilken, publicado pela editora Manning. Sem sombra de dúvidas foi uma das melhores leituras do ano: é um excelente ponto de partida pra quem está começando, e como foi publicado em março de 2018, eu podia ter certeza de que estava lidando com uma das últimas versões do framework (olha o trauma se manifestando!).

Logo na sequência resolvi visitar novamente a documentação e, que surpresa! Está MUITO melhor. Segui o tutorial de uma ponta a outra e, numa experiência que começou em uma sexta-feira a noite e terminou no domingo, já havia devorado uns 90% da documentação oficial. Esta foi a primeira mudança: um bom livro e uma documentação muito melhor.

O ferramental

Mas mais do que a documentação, me encantou o ferramental do Angular. Quando comecei, muitos anos atrás, ainda não havia a ferramenta de linha de comando (ao menos eu não a conhecia). E caramba, como ela ajuda! Foi graças a ela que o aspecto framework do Angular ficou nítido pra mim (e até agora me pergunto: por que ignorei o essencial por tanto tempo???). Não só isto: o VS Code também oferece um suporte maravilhoso ao Angular e TypeScript (claro, é criação da Microsoft). Este foi o segundo fator: o ferramental do Angular é incrível e está muito à frente do que eu tinha no Vue.js.

Aliás, diga-se de passagem, minha experiência com o VS Code trabalhando no /dev/All foi tão boa que este acabou substituindo meu editor favorito até então, que era o Atom.

Ionic framework

É importante mencionar aqui outra razão importante que me motivou a estudar o Angular: Ionic. Apesar de haverem planos de no futuro este suportar o Vue.js, hoje ele suporta BEM mesmo é o Angular. De todos os frameworks híbridos que analisei, de longe Ionic foi o que, de novo, apresentou o melhor ferramental (isto merece um post no futuro).

(e olha que na itexto existe um framework que desenvolvemos para aplicações híbridas, baseado em Vue.js, que é simplesmente incrível)

TypeScript

Motivos irracionais me levaram a postergar o Angular por causa do TypeScript, confesso. Mas quando me atinei que uso Groovy no mundo Java esta irracionalidade foi aniquilada. Pouco a pouco fui aprendendo TypeScript e me encantando com a linguagem. Percebi que alguns dos erros comuns que cometemos com JavaScript não ocorrem no TypeScript: só isto já era razão para que a linguagem fosse adotada.

Devo confessar que parte da minha crescente adoção da linguagem se deu por causa do VSCode. Como ele me oferece um excelente suporte à linguagem (code complete, detecção de erros), ele me ajudou HORRORES a aprender os detalhes da linguagem e como ela funciona.

Sinceramente, não sei se o TypeScript terá lá uma grande longevidade dado que o JavaScript pouco a pouco vai se tornando um “TypeScript padrão”. Entretanto, hoje, e pelo menos pelos próximos três ou quatro anos, a linguagem se manterá, o que em si já justifica sua adoção.

(agora, sua documentação oficial, achei bem ruinzinha viu)

O framework em si

Quando comecei a entender mais a fundo como o Angular organizava e orquestrava seus elementos me apaixonei por ele. O conceito de módulos, por exemplo, achei incrível. De repente encontrei uma maneira muito mais interessante de modularizar código reutilizável entre projetos. É como um OSGi, só que no mundo JavaScript.

Os serviços também são muito interessantes: enquanto no Vue.js temos o Vuex para estado compartilhado, o que pode virar facilmente uma zona conforme o projeto cresce de tamanho, no Angular tenho serviços gerenciados por injeção de dependências e que podem ser singletons. Pronto: é como o Spring, só que no mundo JavaScript.

(OSGi… Spring… duas coisas que gosto no Java… agora do lado JavaScript/TypeScript da cerca…)

O modo como os arquivos que definem um componente são organizados também gostei bastante. No caso do Vue.js, temos os arquivos .vue do Vue Loader. É uma solução bacana, mas como tenho estilo, marcação e lógica no mesmo arquivo, conforme estes aumentam em complexidade, dificulta-se a manutenção (eu sei que o ideal é termos estes caras pequenos, mas eles crescem).  Gostei de ter arquivos em separado.

(Aliás, conto um segredo aqui: muito tempo atrás, quando comecei a aprender Vue.js, implementei o meu próprio “vue-kico-loader”, que era quase igual ao esquema adotado pelo Angular (sua manutenção ficou complexa, vi que o ideal era o Vue Loader, e aí abandonei o projeto))

Sabe do que não gostei? Da sintaxe dos templates: ter de usar coisas como [(ngModel)], *ngFor, coisas assim achei um saco. Neste aspecto o Vue.js é bem mais interessante.

Resumindo: para projetos maiores, a manutenção do código Angular se torna algo muito mais simples em relação ao Vue.js na minha experiência até agora.

Curva de aprendizado e produtividade

Aprende-se Vue.js muito mais rápido que Angular. Já tive experiências na itexto de pessoas sem nenhum conhecimento de desenvolvimento web que em quatro horas já se tornavam produtivas com o Vue.js. Aliás, este foi o fator que mais me encantou no Vue até hoje.

No caso do AngularJS, em minha primeira experiência, não observei isto. Levava um bom tempo até entender os controladores, o modo como eram as interações entre os elementos do framework e até mesmo alcançar uma produtividade mínima com ele.

No caso do Angular 6, que foi meu alvo, percebi que em um dia eu já estava conseguindo fazer alguma coisa com ele. Repare: “alguma coisa”. Ainda não me sentia confortável com a ferramenta. Mas passada uma semana de prática constante, hoje digo que sou bem mais produtivo com Angular que com o Vue.js. Em grande parte devido ao ferramental e do TypeScript.

No caso do Vue.js, usando o Vue.cli posso usar templates prontos que me dão um scaffolding similar ao do Angular, mas ele em si ainda não é tão evoluído, o que é natural, dado ser uma solução mais nova. Entretanto prevejo que no futuro este jogo vire, pois Vue.js ainda é mais fácil de dominar em pouco tempo, na minha experiência.

Como está sendo até agora

Está sendo ótimo. O grande teste é ter um sistema em produção no qual seja necessário dar manutenção de forma ágil. O projeto é o novo /dev/All, e sim, estou conseguindo realizar mudanças em minutos com um framework que ainda não domino inteiramente e com qualidade. Passou no teste.

Apesar de muita gente estar indo para o Vue.js e saindo do Angular, do ponto de vista corporativo, apostaria no Angular, pois a manutenção e o aspecto “framework” da ferramenta é realmente muito interessante. É fácil dar manutenção em uma aplicação Angular.

No final das contas o aspecto “ferramental” também conta bastante: é boas IDEs que ofereçam suporte decente ao framework adotado, e no caso do Angular, devido à sua própria história, isto fica evidente.

Esta tem sido minha experiência com o framework até este momento: aprendi algumas outras coisas que pretendo compartilhar com vocês em um futuro próximo conforme vou narrando aqui a jornada que entramos ao lançarmos o novo /dev/All, pois muitas das minhas concepções mudaram e estão mudando no processo.

Até lá. ;)

PS:

ainda me confundo um pouco com os termos Angular e AngularJS.

Exprimentando Vue.js – aplicando no /dev/All

Recentemente comecei a buscar frameworks JavaScript para serem aplicados em nossos projetos na itexto. Publiquei algum tempo atrás minha experiência de aprendizado envolvendo o Angular.js: chegou a hora de falar sobre o Vue.js.

Como fui parar no Angular.js

 

angular-js_600x400

Aprender Angular foi uma experiência muito enriquecedora para mim pois me pos em contato mais profundo com diversas ferramentas usadas no ambiente JavaScript, tais como o Gulp e o NPM.

O que mais gosto no Angular é a ideia de templates renderizados do lado cliente. Apesar de na esmagadora maioria dos nossos projetos boa parte da renderização ser realizada do lado servidor (diversas razões para isto, o que, por si só, já daria um post), em alguns casos a renderização do lado cliente nos parece a solução ideal.

Um dos nossos projetos em que os templates do Angular cairam como uma luva foi o /dev/All que, até a versão 1.8 usava este framework do lado cliente.  Não conhece o site? Abaixo você pode ver um print do mesmo:

devall_vue

Com o passar do tempo a arquitetura do /dev/All foi sofrendo algumas modificações, dentre elas a criação de uma API na qual estamos trabalhando aos poucos. Entre as chamadas desta API está a nossa busca, que é usada atualmente na interface do site com o usuário final.

A primeira versão do /dev/All era 100% renderizada do lado servidor. Com isto, sempre que o usuário paginava os posts ou realizava uma busca, todo o conteúdo da página era carregado novamente (ignorando os cacheamentos de JavaScript e CSS).

Este problema foi a razão pela qual na versão 1.8 do /dev/All passamos a usar o Angular na confecção da nossa interface gráfica. O resultado foi muito bom: os usuários agora baixavam uma única vez o código da página e em todas as chamadas subsequentes o Angular fazia o trabalho de atualização da interface.

Como encontrei o Vue.js

vuejs

Tivemos esta experiência bem sucedida com o Angular mas fiquei com a impressão de que ele era uma solução muito complicada para as nossas necessidades. A curva de aprendizado do Angular é muito íngreme: são muitos conceitos para que você comece a se tornar produtivo: controladores, módulos, injeção de dependências, inversão de controle, diretrizes. Minha única preocupação era a view: eu só queria um template que fosse renderizado do lado cliente e que tirasse proveito da nossa API.

Eu também queria algo com o qual pudesse reaproveitar conhecimentos que já dominava, como o jQuery: misturar Angular e jQuery é complicado para dizer o mínimo (sei que é possível, mas mesmo assim é mais complexo que o necessário).

Nisto passei por algumas soluções interessantes: Mustache, Rivets, Tangular (apenas 2Kb!) e mais algumas alternativas, dentre as quais estava o Vue.js, cujo primeiro contato foi feito totalmente por acaso através de um vídeo do Vedovelli.

Resolvi experimentar o Vue.js: o primeiro passo foi ler o seu guia para desenvolvedoresA leitura do guia me fez esquecer o Angular. Achei a documentação do Vue.js uma das melhores que já li: rápida, direta e curta. Terminada sua leitura você já consegue criar coisas interessantes com o framework.

(o guia do Vue.js devia ser usado como exemplo de documentação bem feita: virei fã)

A impressão que tive do Vue.js foi a de se tratar de um “Angular” fácil de aprender. Em aproximadamente três horas de estudo você já consegue criar aplicações com o Vue.js: no caso do Angular levou pelo menos uma semana para começar.  Vi esta experiência de aprendizado se repetir com Lucas, nosso estagiário na itexto.

A versão 1.9 do /dev/All, publicada no dia 19/6/2016 substituiu o Angular pelo Vue.js (usamos a versão 1.0). Quantas linhas de código JavaScript precisamos escrever para criar toda a interface do site? 30 (!), incluindo o boiler plate padrão do jQuery ($(document).ready).

O jQuery faz as chamadas ao servidor e o Vue.js renderiza o resultado para nós. É simples assim. :)

Outras coisas que gostei no Vue.js

Além da excelente documentação e facilidade de ser usado com outras bibliotecas (jQuery), houve outras razões pelas quais este framework me ganhou.

API fácil

A API do Vue.js é muito simples: essencialmente você só precisa conhecer o construtor Vue. E não só o guia é fácil de ler: a documentação da API também é excelente!

Levou um tempo até que eu me habituasse com o modo como a injeção de dependências é realizada no Angular (especialmente os problemas que podem surgir durante a minificação e “uglyficação” do código). No caso do Vue, como é focado apenas na view e não há controladores, tudo fica muito mais fácil.

Tem o que gostei no Angular

A sintaxe dos templates do Vue é muito parecida com a do Angular. Tanto é que não precisei reescrevê-los ao migrar para o Vue.js: a grosso modo bastou trocar as diretrizes “ng-*” por “v-*”.  A mesma sintaxe “mustache” se mantém.

Também há diretrizes, como o Angular, assim como filtros. A diferença está na facilidade de aprendizado.

Outra similaridade importante: também implementa o data binding bidirecional. Este recurso é muito interessante, especialmente quando se quer construir interfaces de cadastro mais complexas como, por exemplo, formulários do tipo mestre-detalhe ou mesmo simulação de planilhas (para estes dois casos já estamos projetando soluções baseadas no Vue.js na itexto).

Por falar em data binding, o modo como lida com formulários é também essencialmente o mesmo que temos no Angular.

Criação fácil de componentes

Assim como o Angular, o Vue.js também te permite criar componentes. No caso, o Vue é muito inspirado na spec Web Components do W3C. Note que é inspirado e não uma implementação desta spec.

A vantagem é que você pode escrever sua biblioteca de componentes reaproveitáveis com o Vue e, caso deseje abandoná-lo no futuro, o trabalho de reescrita (em teoria) deve ser bem menor.

Concluindo

Para situações nas quais só me interessa a renderização do lado cliente e a aplicação não é muito complexa (como o /dev/All), creio que Vue.js seja uma solução mais interessante que o Angular.

Se você ainda não o conhece, sugiro que leia seu guia e brinque um pouco com ele: é uma experiência muito interessante.  Na excelente documentação oficial há uma seção interessante na qual o comparam com outros frameworks, recomendo sua leitura, apesar de naturalmente se tratar de um texto tendencioso.

Creio que, apesar de ter preferindo o Vue, estudar Angular é essencial: tenho certeza de que boa parte da facilidade que tivemos em aprendê-lo (Vue) se deve aos conceitos que precisamos aprender em nosso estudo do Angular.

Se você gosta de vídeos, o Fabio Vedovelli tem uma série a respeito que vale muito à pena assistir (como tudo o que ele faz).

Modularizando JavaScript com Spring MVC e Jawr

javascript-logoEste post inicia uma série na qual vou expor técnicas que visam aumentar a manutenibilidade de código Javascript. Convenhamos: é uma linguagem de programação legal, porém muitas vezes o hype que a envolve nos impede de ver seus aspectos negativos. Neste post tratarei de uma das cicatrizes da linguagem que é a dificuldade que enfrentamos na modularização do código.

O problema: modularizar JavaScript usando Spring MVC

Se você tem a sorte de trabalhar com Grails tem à sua disposição uma solução maravilhosa que é o plugin resources que nos permite definir “módulos Javascript”. Infelizmente do lado Spring da cerca não temos algo tão popular. O que é um módulo Javascript?

Uma unidade de código que funciona em conjunto.

Muitas vezes esta unidade não é apenas um arquivo, mas vários, e é neste ponto que o problema começa a se manifestar. Imagine um módulo composto por dois arquivos: biblioteca.jsbiblioteca2.js. Sua equipe pode ter achado interessante dividi-lo em dois arquivos para paralelizar o esforço e com isto evitar todos aqueles incômodos relacionados ao merge de arquivos. Nesta situação, toda vez que você precisa usar este módulo, irá inserir em suas páginas código similar ao exposto a seguir:


<script type="text/javascript" src="/resources/js/biblioteca.js"></script>
<script type="text/javascript" src="/resources/js/biblioteca2.js"></script>

Ou então você poderia ter algum script que unisse os dois arquivos. O problema é que seria necessário modificar o seu processo de build e também fornecer garantias de que o arquivo gerado fosse sempre o mais atualizado possível (não é uma solução tãão bacana assim).

Agora, voltemos ao nosso exemplo. Imagine que este nosso módulo dependa do jQuery. Neste caso teríamos sempre de escrever o seguinte código em nossas páginas:


<!-- jQuery sempre irá ser carregado primeiro -->
<script type="text/javascript" src="/resources/js/jQuery.js"></script>
<script type="text/javascript" src="/resources/js/biblioteca.js"></script>
</span><script type="text/javascript" src="/resources/js/biblioteca2.js"></script>

Ainda pior: imagine que a ordem de carregamento dos arquivos biblioteca.jsbiblioteca2.js seja importante. Agora sua equipe precisa ser informada a respeito. Se for uma aplicação de uma única página, não será lá um grande problema, mas imagine uma aplicação maior, com mais de um template, etc. A coisa começa a se complicar.

A imagem a seguir expõe bem a situação do nosso projeto. Temos uma biblioteca composta por dois arquivos que depende de uma terceira:

jawr_dependencias

Não seria bacana se houvesse uma ferramenta que nos permitisse resolver os problemas a seguir de uma forma simples?

  • Documentar as dependências entre os nossos arquivos Javascript de tal forma que seja fácil para a equipe entender a organização interna do projeto.
  • Garantir que os arquivos sejam sempre carregados na ordem correta.
  • De alguma maneira otimizar o modo como estes arquivos são enviados ao browser: compressão via gzip, talvez até mesmo um merge dos arquivos.

Jawr entra em cena

logoJawr

Jawr é uma ferramenta que tem como objetivo resolver os três problemas que expus acima e mais alguns. Neste post irei tratar de uma parte bem pequena deste projeto: aquela que lida com Javascript. A grosso modo Jawr é um servlet que iremos inserir em nosso projeto fictício. Este servlet organizará nossos módulos Javascript em bundles.

O que é um bundle? É um módulo, tal como expus acima. Mais do que isto, um bundle alguns atributos fundamentais do nosso módulo:

  • Que arquivos compõem o nosso módulo
  • Em que ordem estes arquivos devem ser carregados
  • Quais as dependências do nosso bundle, isto é, que código este precisa para funcionar?

Voltando ao nosso projeto percebe-se que há dois bundles: biblioteca e jQuery, que podemos representar gráficamente tal como na imagem a seguir:

Nossos bundles

Nossos bundles

Poderíamos pensar em um bundle único composto pelos nossos arquivos da biblioteca e o do jQuery. O problema é que sabemos que jQuery será usado por diversos outros pontos da nossa aplicação: sendo assim é interessante que modularizemos esta parte a fim de que seja reaproveitada em outras partes do projeto.

Incluindo Jawr em nosso projeto

Nosso projeto é baseado em Maven. Sendo assim, para incluirmos o Jawr basta adicionar a dependência no arquivo pom.xml tal como no exemplo a seguir:

<dependency>
    <groupId>net.jawr</groupId>
    <artifactId>jawr</artifactId>
    <version>3.3.3</version>
</dependency>

Como disse logo acima, Jawr é essencialmente um servlet. Sendo assim temos também de alterar o arquivo web.xml para que fique similar ao exposto a seguir:

<!-- Servlet para lidar com Javascript -->
<servlet>
   <servlet-name>JavascriptServlet</servlet-name>
   <servlet-class>net.jawr.web.servlet.JawrServlet</servlet-class>

		<!-- Aonde se encontra o arquivo de configuracao -->
   <init-param>
       <param-name>configLocation</param-name>
       <param-value>/jawrJavascript.properties</param-value>
   </init-param>
   <init-param>
       <param-name>mapping</param-name>
       <param-value>/bundle/js/</param-value>
   </init-param>
   <load-on-startup>1</load-on-startup>
</servlet>
<!-- O mapeamento de URL -->	
<servlet-mapping>
   <servlet-name>JavascriptServlet</servlet-name>
   <url-pattern>/bundle/js/*</url-pattern>
</servlet-mapping>

Preste muita atenção no mapeamento de URL. Na documentação oficial do Jawr este é configurado para que lide com todos os recursos que terminem com a extensão .js. O problema com esta abordagem é que muitas vezes não queremos que todos os nossos arquivos Javascript sejam carregados como bundles. Talvez você queira ir adotando aos poucos a ferramenta em seu projeto (esta é a principal razão que vejo). Em nosso caso, Jawr só irá lidar com aqueles recursos Javascript que se encontrem na url /bundle/js/*. Nota importante: repare no parametro de inicialização mapping. Se for usar uma configuração como esta, este obrigatóriamente deve estar definido.

Configurando os bundles

No mapeamento do servlet foi incluído um parâmetro chamado configLocation. Em nosso projeto baseado em Maven este arquivo se encontra em /src/main/resources/jawrJavascript.properties. É neste arquivo que iremos definir todos os nossos bundles. Abaixo está um exemplo deste arquivo:

# Altere aqui caso esteja no seu ambiente de desenvolvimento
jawr.debug.on=false

# Devemos enviar os bundles compactados?
jawr.gzip.on=true

# De quantos em quantos segundos o servlet deve verificar se as configuracoes foram
# alteradas. Extreammente util em tempo de desenvolvimento!
jawr.config.reload.interval=30

# Primeiro bundle de exemplo: jQuery
# O identificador do bundle sempre é o que aparece antes do ‘.id’
# neste caso, é jquery
jawr.js.bundle.jquery.id=/bundle/js/jQuery.js
jawr.js.bundle.jquery.mappings=/resources/js/jquery-2.1.0.min.js

# Incluindo uma dependencia
jawr.js.bundle.biblioteca.id=/bundle/js/biblioteca.js
jawr.js.bundle.biblioteca.mappings=/resources/js/biblioteca.js, /resources/js/biblioteca2.js
jawr.js.bundle.biblioteca.dependencies=jquery

Um bundle Javascript é definido no arquivo com o prefixo jawr.js.bundle.[identificador do bundle]. A primeira linha, que termina com .id define como será a URL que define o nosso bundle. O bundle jQuery, por exemplo, sempre será carregado quando a URL /bundle/js/jQuery.js for acionada, enquanto o bundle biblioteca, pela URL /bundle/js/biblioteca.js.

Voltemos nossa atenção para o bundle biblioteca. A segunda linha da sua definição (mappings), define quais os arquivos que o compõe e a ordem na qual devem ser carregados. A terceira linha define quais as suas dependências. Neste caso, apenas uma: o bundle jquery.

Tendo feito isto temos todos os bundles em nosso projeto prontos para serem usados. O próximo passo é trabalhar no arquivo JSP.

Alterando o arquivo JSP

O projeto Jawr vem com uma biblioteca de tags bastante útil. Abaixo podemos ver um exemplo de sua aplicação:

<%– A declaração da biblioteca de tags –%>
<%@ taglib uri="http://jawr.net/tags" prefix="jwr" %>

<%– Carregando o bundle biblioteca –%>
<jwr:script src="/bundle/js/biblioteca.js"/>

E o que ocorre quando carrego a página? Obtenho o resultado a seguir:

<script type="text/javascript" src="/itexto/bundle/js/gzip_N1063700552/bundle/js/jQuery.js" ></script>
<script type="text/javascript" src="/itexto/bundle/js/gzip_N745101183/bundle/js/biblioteca.js" ></script>

Primeiro será inserida a dependência do bundle biblioteca e, em seguida, o código fonte do bundle biblioteca. Repare nas URLs: o Jawr irá automáticamente cachear os recursos Javascript. E sabem o que é mais legal? Ele também envia o Javascript comprimido (se o modo de depuração estiver desativado (veja as notas no arquivo que expus acima)). E não é só o conteúdo Javascript comprimido. Os dois arquivos que compõem o módulo biblioteca também são mesclados em um só, diminuindo assim o número de requisições necessárias. Simples assim. :)

Concluindo

Nese post apresentei uma pequena parte do projeto Jawr. Há mais neste servlet, que também pode ser usado para gerenciar recursos CSS e imagens. É importante salienar que a documentação do projeto é excelente: bem escrita e fácil de ser consultada.

Claro que a questão da modularização não termina aqui. Esta é apenas uma das soluções possíveis. Recentemente topei com um ebook online (e gratuito) chamado Writing Modular JavaScript with AMD, CommonJS & ES Harmony que trata da questão de uma forma muito mais profunda. Entra aí também o modo como escrevemos JavaScript (que não tratei neste post) e alguns outros pontos sobre os quais pretendo escrever mais a respeito em um futuro próximo.

O código fonte deste post pode ser acessado no meu GitHub: https://github.com/loboweissmann/jawr-testes

Por que resolvi largar o Flash e partir pro HTML 5 :)

HTML5_logo_and_wordmark.svgNada como algumas rotações da Terra pra mudar as coisas né? No dia 3/1/2010 publiquei aqui um texto chamado “Por que resolvi largar o HTML e partir pro Flash” que é um dos posts mais acessados deste blog desde então. Mas quando olho pro meu histórico percebo que na realidade nem deu tempo de largar o HTML 5 e a esmagadora maioria das frustrações que eu tinha com este até então não existem mais (aliás, nem sei se ainda restou alguma destas limitações).

Foi tudo muito rápido. No mesmo ano comecei o desenvolvimento de jogos em… HTML 5 usando canvas. Em dezembro eu já tinha uma versão do Space Invaders 100% canvas que também é outro post bastante popular aqui no blog. Fantástico né? Agora vamos voltar às minhas reclamações de três anos atrás.

O pesadelo do HTML (os tais “web standards”)

Na época se não me engano o grande problema era o Internet Explorer e a maior parte dos browsers não dava um suporte razoável aos novos recursos do HTML 5. Wow, como as coisas mudaram. Pra começar, hoje na média, de acordo com o site “Can I Use…” estamos com suporte de aproximadamente uns 80%, ou seja, basicamente apenas os recursos menos usados não são suportados pela maioria.

html5_support

Internet Explorer

E o Internet Explorer? Bom: ao menos no meu blog corresponde a bem menos de 10% dos acessos, mas neste caso não vale muito pois minha audiência é técnica. Mas tirando isto, vou usar uma fonte bem mais confiável. Atualmente corresponde a 15,6% de todo tráfego da Wikipédia.

O próprio Internet Explorer acabou melhorando bastante: a versão 10 possuí um suporte bem melhor e, além disto, pelo fato de a Microsoft ter adotado Javascript/HTML como sua plataforma de desenvolvimento preferencial (mesmo por que ao que tudo indica ninguém mais liga pro Windows) a coisa parece que vai ficar ainda melhor no Internet Explorer 11: ou ela se adapta ou tá fora, simples assim.

Como quase optei pelo Flash

Na época eu estava desenvolvendo um produto que era basicamente um kanban eletrônico (mas gostei tanto do Trello que acabei largando o projeto). Então basicamente era drag and drop o tempo inteiro na interface do usuário e o suporte que eu tinha no HTML 5 era bem fraco para alguns detalhes da interface. Além disto, a linguagem Action Script também tinha me fisgado: me apaixonei por ela conforme ia lendo mais a respeito.

Durante o desenvolvimento deste projeto meu interesse foi para a área de jogos: comecei criando algumas coisas com OpenGL (sim, existe um “Duke Nanna” em algum lugar aqui em casa) mas por algum acaso resolvi experimentar o canvas do HTML 5 (um experimento muito tosco me acordou). Boom! De repente as coisas que eu achava serem possíveis apenas no Flash eu estava conseguindo com Javascript! Logo em seguida vieram animações com CSS 3, suporte a persistência local, dados de localização e pronto: em algo tipo seis meses eu já podia fazer práticamente tudo o que o Flash oferecia sem precisar comprar uma licença do produto.

O suporte que os navegadores passaram a oferecer a estas tecnologias veio muito rápido, bem mais rápido do que eu esperava (no post eu falo algo sobre o HTML 5 só estar pronto em 2022). Erro meu, que bom! :)

A presença “universal” do Flash

Eu realmente acreditava que só a Apple iria chutar o Flash e com o tempo acabaria voltando atrás. Wow, como estava errado! Na realidade diversos players começaram a simplesmente abandonar a plataforma por completo. Meu celular atual (um Nokia Lumia 800 com Windows Phone 7.8) já apresenta dificuldades ao lidar com o formato, idem para diversos dispositivos Android. Dado que mobile, e não desktop é o futuro, Flash não está mais com os dias contados, pois simplesmente não há mais dias para contar: acabou.

E ei: a popularização de coisas como Phone Gap e Appcelerator também contribuiram muito pra isto. De repente estamos criando aplicações semi nativas mobile usando HTML 5. Mais um prego no caixão.

Concluindo

Bendito seja o dia em que resolvi brincar com o canvas! Até então eu não conseguia ver o potencial da plataforma que estava surgindo (ela realmente se mostrava muito débil pra mim). HTML 5 pode até não ser oficialmente um padrão hoje, mas na prática é: e ao que tudo indica vai ser o padrão durante os próximos anos e talvez das próximas décadas.

O proprietário vai aos poucos sendo enterrado e o aberto dominando. Me pergunto: visto que esta plataforma está dominando de tal forma, será que aquele velho sonho de tornar o sistema operacional mero comodite já está se concretizando? Será que poderemos dizer em pouco tempo que tanto faz você ter um Mac ou PC pois sua aplicação foi feita pra rodar inteiramente na web? Acho que sim: mas ainda vai demorar um pouco.

PS: daqui a três anos eu volto a este post pra ver o quão certo ou errado eu estava ok?

Trazendo o Atari para o HTML5 com Canvas: Space Invaders

Continuando minha pesquisa sobre HTML5 usando canvas, aqui está meu mais novo experimento: recriei à minha moda o clássico “Space Invaders” do Atari. Confesso que fiquei MUITO satisfeito com o resultado e, espero, vocês também.

Desta vez não posso dizer que o código seja tão mínimo quanto minha primeira grande experiência, pois um dos meus objetivos foi justamente trabalhar em algo mais complexo. Sendo assim, para evitar ficar perdido em uma multidão de código fonte, optei por modularizar meu projeto.

Há algumas diferenças com relação ao original que devem ser salientadas:

  • O jogo possui final: basta aniquilar todos os invasores para ser saudado com os meus “peculiares parabéns” :D (fica a surpresa). Há somente um nível.
  • Não há barreiras de proteção, o que torna o jogo mais difícil e, na minha opinião, mais divertido também.
  • A coreografia dos invasores está ligeiramente diferente (gera uma certa confusão que me diverte bastante)
  • E, claro, eu vou te xingar o tempo inteiro :D

É importante mencionar que, novamente, é apenas uma prova de conceito. Estou evoluindo aos poucos para que, em um futuro que espero próximo, eu possa desenvolver coisas mais complexas usando tanto HTML5 como outras tecnologias (Flex, OpenGL, Java, etc.). Pra mim, é muito mais uma saída da minha zona de conforto. Saida esta que tem me feito MUITO bem (e eu recomendo a todos).

Sobre compatibilidade entre browsers

Novamente, o browser campeão foi o Chrome. Ele renderizou tudo perfeitamente sem problemas e, o que achei mais interessante: também reproduziu meu áudio perfeitamente. Pra minha surpresa, ele aceitava o formato MP3, que foi aonde gravei os sons pela primeira vez. No Firefox, no entanto, eu só posso tocar arquivos no formato OGG ou WAV (fiquei com preguiça de converter, sendo assim, para ouvir minha voz sexy, use o Chrome), porém a renderização no Firefox, assim como no Chrome, é perfeita.

No IE8 o “Space Invaders” simplesmente não executou. Sinceramente, nem me esforcei neste caso, porque, confesso, tenho birra deste browser (como todos vocês).

Minha grande decepção desta vez foi o Safari. Como não estou com meu macbook, tive de testar meu jogo na versão Windows, e por alguma razão, caso você morra ou termine o jogo, ele trava. Ao usar as ferramentas de desenvolvimento, fiquei muito frustrado, pois elas não me permitem depurar o código tão bem quanto no Chrome ou no Firefox usando Firebug.

Resultado final

Basta clicar na imagem abaixo para ver o resultado. Espero que se divirtam jogando-o (e fuçando meu código) tanto quanto eu AMEI trabalhar nesta brincadeira. Semana que vêm coloco mais uma aventura por aqui.

Levando o Atari para o HTML5 usando canvas e Javascript – Freeway

Em 1985 ganhei meu primeiro video game do meu pai: era um Atari 2600, e o jogo que o acompanhava era o “Freeway”. Sendo assim, nada mais natural que o primeiro jogo que eu tente recriar seja este!

Me propus recriar em Javascript usando o novo elemento canvas presente no HTML 5 alguns clássicos do Atari (de preferência, todos). Optei pelo Atari pelas seguintes razões:

  • São jogos extremamente simples do ponto de vista gráfico (basicamente, apenas desenho de retângulos e pouquíssimas transformações)
  • As regras são banais. Veja Freeway, por exemplo: tudo o que você precisa fazer é levar a galinha ao outro lado da rua para que, por mágica, mais uma tente a mesma travessia.
  • O desafio técnico é do caralho: basta lembrar que River Raid, com seu mapa de proporções quase infinitas ocupava APENAS 4 KB de memória.
  • O Atari possui um valor muito especial pra mim. Foi meu primeiro videogame e, além disto, o dispositivo no qual desperdicei minha infância. :D

Esta minha primeira versão do Freeway é apenas uma prova de conceito. Antes que postem aqui os defeitos, os listo para vocês:

  • Meu algoritmo de colisão é muito fraquinho. Basicamente, os carros só tem a certeza de terem aniquilado nossa pobre galinha quando passam por cima da sua cabeça
  • As ruas são ainda mal desenhadas – eu poderia melhorar isto, mas quer saber? Fiquei com preguiça. :D
  • Ainda não domino bem a escrita de texto com o canvas. Repare como os textos aparecem horrívelmente borrados.
  • A renderização, como já se era de esperar, varia um pouco entre navegadores. No caso, testei o Freeway apenas no Firefox 3.5 e Chrome.
  • Ainda não há som (não trabalhei neste ponto ainda)
  • Só há uma galinha! (esta é uma prova de conceito meu caro!)

Clique no screenshot abaixo para tentar ajudar nossa pobre galinha a atravessar a rua. (e divirta-se com meu código fonte!) :D

Conclusões após o experimento

Javascript está se tornando, pouco a pouco, minha linguagem favorita. O ambiente de desenvolvimento é o que mais gosto: apenas um editor de texto e um browser, nada de IDEs (nada contra IDEs, mas adoro este sentimento de “raiz”). No caso do Freeway, o desenho é basicamente bitmap, ou seja, são criadas matrizes com valores numéricos represenando cores que em seguida são renderizadas, como quadrados adjacentes na tela. Bem simples.

Freeway foi o primeiro e último jogo de Atari que criei “na unha”. A partir deste primeiro trabalho, iniciei o desenvolvimento de uma biblioteca que me permite automatizar diversos elementos presentes em um jogo, como por exemplo renderização, física, inputs, etc. Nesta biblioteca há, por exemplo, um editor gráfico (tudo é escrito em Javascript) que me permite criar sprites muito mais rápido que o método aplicado em Freeway (to louco pra liberar este subprojeto).

Óbviamente, eu poderia ter implementado um Freeway muito melhor em C ou Java, mas quer saber? Estou descobrindo até onde posso ir no canvas. E até agora, poucas limitações apareceram (99% fruto da minha própria ignorância). Faz muito tempo que não me sinto tão feliz aprendendo algo. Espero que gostem da minha versão do Freeway. Aguardo opiniões!

Grande abraço!

PS: Ah! Como no original, a galinha só pode se mover pra cima e pra baixo. :D