JavaScript, História e Ciência – Palestra Crockford

Ontem parei pra assistir mais uma palestra do Douglas Crockford.
Já falei aqui que o cara é amado e odiado na comunidade JavaScript, e creio que existe muito mito em torno disso.
Como programadores JavaScript, devemos prestar atenção em um fato: O Crockford entende muito da linguagem JavaScript. Provavelmente mais que todos nós.
Digo isso porque o embasamento nas teorias do Crockford fazem muito sentido, e apresentadas por ele, mostram que ele realmente entende do que esta falando.
Depois de longos anos estudando JavaScript, ainda não me considero apto a dizer que sou ninja, e que sei tudo. Até porque isso seria muita presunção minha.
O fato é o que o Crockford sim, parece ser ninja e parece saber tudo sobre a linguagem, então o mínimo que posso fazer é ouvir o homem, prestar atenção e correr atrás para quem sabe um dia ter o conhecimento suficiente para questionar as teorias do Douglas.

Durante a palestra o Crockford provou por a + b suas teorias. Abaixo compartilho algumas:

• Colocar a chave “{“ na direita
  Ex:

  block {
  ...
  }
  

  Por costume, eu sempre coloco na direita mesmo. Mas muitos programadores colocam na esquerda, assim:

  block
  {
  ...
  }
  

  A moral é que isso não importa. Na direita ou na esquerda, não importa…
  Exceto no JavaScript. Rá!
  Sim, para o JavaScript faz diferença, por um motivo simples.
  Vejam o código:

  return
  {
  ok : false
  }
  

  Este código irá falhar.
  Se queremos retornar um objeto literal, devemos sempre colocar a “{” na direita, porque neste caso o JavaScript retorna undefined.
  Uma diferença sútil, e o seu programa não irá falhar:

  return {
  ok : false
  }
  

• Usar sempre === ao invés de ==
  Sempre tive a pulga atrás da orelha com essa premissa do Crockford. Mas ele explicou o porque, e de fato faz sentido.
  O == não funciona muito bem no JavaScript. Até mesmo o Brendan sabia disso quando criou a linguagem.
  O que aconteceu foi que quando a linguagem foi padronizada, o Brendan tentou corrigir isso com o comitê, mas a Microsoft insistiu que não deveria ser feito.
  Porque diabos? Não sei.
  Mas o Brendam conseguiu ao menos implementar o ===, então esse é o motivo de o porque sempre utilizar ===.
  Alguns exemplos que provam a falha do == :

  0 == '' //true
  '' == '0' //false
  0 == '0' //true
  false == 'false' //false
  false == '0' //true
  // E o mais bizarro de todos
  " trn " == 0 //true
  

   

• Declarar variáveis sempre no topo do corpo da função
  Item bem interessante.
  O Douglas explica na palestra que o JavaScript é diferente de outras linguagens em relação ao escopo de variáveis.
  Em outras linguagens, devemos sempre declarar variáveis o mais próximo possível de onde vamos usa-las. No JavaScript é bem o contrário.
  Devemos sempre declarar as variáveis no topo da função, poque de fato é isso que acontece, essa é a primeira coisa que é feita no fluxo da execução.

Antes do vídeo, deixo uma frase que achei muito interessante:
“Se existe uma feature de uma linguagem que às vezes é problemática, e se ela pode ser substituída por uma outra feature que é mais confiável, então sempre use a feature mais confiável” 
Faz muito sentido.

Bom, RECOMENDO que todos vejam este vídeo. Mesmo os que não gostam do Crockford. Alias, principalmente os que não gostam.
Abram a mente, escutem, estudem, pesquisem.
O título do post “JavaScript, História e Ciência” deve-se ao fato de que a palestra do Crockford é isso. Uma aula de JavaScript, obviamente. Mas não só isso. É uma aula de história, onde ele conta vários fatos sobre diversas pessoas e linguagens. E também é uma aula de ciência, onde ele consegue fazer um link muito inteligente entre as confusões do nosso cerébro e a programação.
Vale muito a pena. Parem 1 hora e vejam.

HTML5 AppCache – Cache-Control: no-store

No meu último post, falei sobre como tudo no HTML5 é legal, e especificamente sobre o Application Cache.

O legal de trabalhar com HTML5 é que tudo é muito novo.
O ruim de trabalhar com HTML5 é que tudo é muito novo.

O que quero dizer, é que HTML5 é uma tecnologia nova, e que muitas funcionalidades ainda estão em desenvolvimento.
Ou seja, não está completamente definido como tais features vão funcionar.
Creio que isso seja uma questão complicada para os Browsers, pois eles devem implementar estas especificações incompletas.
Mas tudo isso faz parte da transição em que estamos, e de certa forma, isso é muito bom.

Voltando ao AppCache, vou citar um dos problemas que encontrei utilizando essa feature, que julgo ter um grande potencial, se sofrer algumas alterações.

Como falado antes, o AppCache não é uma feature que apenas permite que sua Web App rode Offline.
O AppCache pode reduzir e muito o “peso” da sua App, reduzindo o número de requisições.
Imagine que sua Web App tenha 6 arquivos JavaScript, 3 arquivos CSS, e várias imagens.
Se nenhum destes arquivos sofre atualizações constantes, todos podem ser “AppCacheados”.
Tecnicamente isto quer dizer que se o total em KBytes de sua página é de 200K, esses 200K podem ser carregados diretamene do Cache.
Sim, o Browser possui um mecanismo de Cache padrão, mas este cache não é controlado pelo desenvolvedor.
Outro fator relevante é que nenhum Header do arquivo é levado em conta se a sua App está utilizando AppCache.
Com exceção do Cache-Control:no-store.
Ou não.

Bom, na especificação temos alguns detalhes que já mencionei, mas o que mais tive problemas foi este:
“A página onde esta definido que a aplicação utilizará o manifest, mesmo não estando listada no manifest, será armazenada no cache”.
Lembre que o AppCache também foi pensado para fazer uma App rodar Offline, então isso até faz sentido, mas gera outros problemas.
Se o meu objetivo é reduzir o número de requisições, e minha página muda constantemente o seu conteúdo, essa regra acaba com a possibilidade de utilizar o AppCache.
Ai chegamos em outra regra da especificação:
“Com exceção da diretiva “no-store”, os headers HTTP de cache são substituídas pelo Appcache”
Problema resolvido então?
Não!!!
Por algum motivo o Google Chrome não respeita esta regra.
Faça o teste, altere as configurações do seu servidor(no meu caso o Apache):

 <FilesMatch "(.html)$">
 Header set Cache-Control "no-store"
 </FilesMatch>

O que fiz foi dizer que todos arquivos HTML devem vir com o Cache-Control “no-store”.
No Firefox e no Opera isso funciona perfeitamente. Todos arquivos listados no manifest para serem Appcacheados estão lá, com exceção da página atual.
No Chrome, isso simplesmente não acontece. A página atual sempre vem do cache.

Notem que esse problema pode ser resolvido se utilizarmos a funcionalidade padrão do Appcache: Atualizar o manifest.
Mas isso nem sempre é possível, ou nem sempre eu quero fazer isso.
Ficar na dependência de alterar um arquivo manifest para atualizar o conteúdo principal é uma coisa delicada.

Bom, ainda estou pesquisando para ver se isso é um Bug do Chrome, ou se realmente o Google ignorou a regra do “no-store”.

HTML5 Application Cache

BrowserID – Novidades

Já falei sobre o BrowserID aqui anteriormente e hoje venho compartilhar uma novidade .
Há algumas semanas, o Ben Adida (https://twitter.com/#!/benadida , http://benlog.com/) passou a ser o líder tecnológico na Mozilla na parte de Indentidade e dados dos usuários.
Mas quem é esse cara?
Bom, eu ainda não o conhecia, mas lendo sobre seus projetos vi que com certeza o BrowserID vai longe.
O Ben publicou varios projetos, todos baseados em autenticação, e 2 delas sobre autenticação via e-mail, assim como é a ideia principal do BrowserID.

Abaixo listo os 3 trabalhos do Ben:
EmID: Web Authentication by Email Address - http://assets.adida.net/research/w2sp2008-emid.pdf
Lightweight Signatures for Email - http://assets.adida.net/research/lightweight-signatures-for-email.pdf
BeamAuth - http://assets.adida.net/research/beamauth-ccs2007.pdf

E agora um vídeo, onde o próprio Ben explica como o BrowserID funciona.
Vale a pena dar uma olhada, e apostar nesta tecnologia!

ECMAScript 5: The New Parts

Acabei de ver a palestra do Douglas Crockford sobre o que vem por ai na ECMA5.
Muitos falam que o Crockford é arrogante, mas o cara sabe muito quando o assunto é JavaScript.
Eu respeito muito o trabalho do cara, e como não o conheço pessoalmente, não compartilho da opinião da maioria.
Bom, como profissional da Internet assisti todo o video, e aconselho que façam o mesmo.
No meu ponto de vista, a palestra é um overview do futuro da Web.
Um futuro bem próximo.

Segue o link do video:
http://channel9.msdn.com/events/MIX/MIX11/EXT13

JavaScript – Resumo da semana 29/08 a 02/09/2011

Essa semana reuni muita coisa, fiz um filtro no que achei mais interessante.
Dentre o que escolhi temos Games, DOM, Performance, Libs, Node, HTML5 e mais algumas coisas.

>>> Jaws HTML5 javascript game lib - http://jawsjs.com/
Pra começar, achei por ai a Lib Jaws,uma biblioteca JavaScript+HTML5 para desenvolvimento de Games 2D.
A biblioteca suporta tanto Canvas quanto DOM, baseando-se em Sprites.
Não fiz nenhum tese prático, mas deixei na minha lista de Libs para Games em JavaScript.
Perdi a conta de quantas Libs como essa já existem, isso é muito bom, pois na hora de desenvolver temos várias opções.
Abaixo alguns demos:
example #2
example #3
example #4

>>> DOM Monster - http://mir.aculo.us/dom-monster/