Estive procurando referências sobre a implementação do objeto Array no Firefox 3 para saber se de alguma forma se assemelhava ao novo Array flexível do IE 8 e acabei encontrando um resumo muito bem feito sobre as características únicas dessa línguagem na própria documentação da Mozilla.

A re-introduction to JavaScript

O melhor resumo rápido em texto que eu já encontrei, mas ainda não bate a série de vídeos do Crockford (que você pode ver no Yahoo! UI Theater).

Why a re-introduction? Because JavaScript has a reasonable claim to being the world’s most misunderstood programming language. While often derided as a toy, beneath its deceptive simplicity lie some powerful language features. 2005 has seen the launch of a number of high-profile JavaScript applications, showing that deeper knowledge of this technology is an important skill for any web developer.

Fiz hoje a prova base do framework .Net (Microsoft .NET Framework - Application Development Foundation 70-536) e felizmente consegui passar. Uma coisa interessante é que algumas pessoas com quem eu conversei disseram que era muito fácil, que o transcender era mais difícil que a prova.

Minha experiência pessoal: Balela.

Foi certamente uma das provas mais complicadas que eu já fiz, as partes de segurança e serialização foram duríssimas, das 40 questões que eu respondi apenas 7 eram similares as mais de 200 questões de preparação que eu respondi antes da prova.

Não tenho vergonha nenhuma de dizer que eu fiquei de olhos marejados ao ver o “Passed”, quem me salvou mesmo foi o Professional C# da Wrox, já que o livro do kit oficial de preparação para a prova e os simulados não foram o bastante para garantir uma “experiência tranquila”.

Não sei se a prova mudou ou se eu sou fraco mesmo, mas recomendo no mínimo 2 meses de estudo dedicado para quem quiser se aventurar.

E que venham a 70-528 e a 70-562…

Uma coisa legal é que se não existirem QueryStrings eu retorno nada, nem mesmo aquele espaço no document.location.QueryString eu ocupo nesse caso.

document.location.QueryString = (function (){
    var params = {};
    var qs=location.search.substring(1,location.search.length)
    if (qs.length == 0) return
    qs = qs.replace(/\+/g, ‘ ‘)
    var args = qs.split(’&’);
    for (var i=0;i<args.length;i++) {
      var value;
      var pair = args[i].split(’=');
      var name = unescape(pair[0]);
      if (pair.length == 2){
          value = unescape(pair[1]);
      }
      else{
        value = name;
      }
      params[name] = value;
    }
   return function(key){
    var value = params[key];
    if (value !=null){
      return value;
    }
  }
})();

Depois é só acessar o valor por:

//retorna o valor associado
location.QueryString(”keyName”);

Se alguém perceber algum bug, por favor comente.

function walkTheDOM(node, func) {
    func(node);
    node = node.firstChild;
    while (node) {
        walkTheDOM(node, func);
        node = node.nextSibling;
    }
}

Uma série de estruturas no browser se encaixam nesse paradigma, os próprios objetos Javascript são estruturas de dados que podem ser percorridas exatamente da mesma forma, e do mesmo jeito que o mestre Crockford percorre o DOM você pode pode percorrer um Objeto interrogando todos os seus elementos filhos a procura de quem interessa, um método de um objeto, um valor, um objeto específico. A coisa pode ficar realmente complexa se levarmos em consideração que um objeto js é uma cadeia de elementos sem um final definido, podemos ter um objeto que contenha um array de objetos que contenha um outro array de objetos e assim por diante. Para um exemplo prático dê uma olhada no objeto YAHOO utilizado como namespace na YUI! (e que na prática é um objeto js como qualquer outro):

Um exemplo inocente:

var walkThatObject = function(object, func){
    for(var prop in object){
        func(object[prop]);
        if(typeof object[prop]== ‘object’){
            walkThatObject(object[prop], func);
        }
    }
}

//Poderia ser uma literal de objeto aqui
var thatObject = {};

thatObject.Nome = ‘David’;
thatObject.Sobrenome = ‘Duarte’;
thatObject.Qualidades = {qualidade1:’Geek’, qualidade2:’Javascripter’, qualidade3:{subqualidade:’Bom filho’}};

walkThatObject(thatObject, function(obj){
    if(typeof obj == ’string’){
        alert(obj);
    }
});

Interessante e “extremamente relevante” não? Pense nisso…

O nada discreto aviso continua na página de documentação da Mozilla dizendo “This feature is available in Firefox 3, but only to extensions and other privileged code; it is not currently available for web content” então pela primeira vez em meses acho que posso dizer que o time do IE saiu na frente em alguma coisa.

Enquanto o pessoal da Mozilla não conseguiu resolver a sua implementação o time do IE simplificou e criou um objeto a parte só para esse fim, o XDomainRequest , particularmente achei inteligente separar as coisas, uma vez que permite que algumas validações sejam incorporadas a implementação nativa ( item 2 do working draft da W3C cita: ” Must not require content authors or site maintainers to implement new or additional security protections to preserve their existing level of security protection.”).

Puxa, bastante tempo sem reclamar de nada, postarei com mais frequência

Em um nível fundamental é importante entender como os timers funcionam em Javascript. Frequentemente eles se comportam de maneira não muito intuitiva por estarem todos em uma única thread. Vamos examinar as três funções para construir e manipular timers:

• var id = setTimeout(fn, delay); - Inicia um timer simples que vai invocar a função depois do intervalo especificado. A função retorna um ID único que pode ser usado para cancelar o timer.
• var id = setInterval(fn, delay); - Similar a setTimeout mas continua invocando a função aplicando o mesmo intervalo (delay) até ser cancelada.
• clearInterval(id);, clearTimeout(id); - Aceita um timer ID (o retorno das funções anteriores) e interrompe a execução do timer

Para entender melhor como os timers funcionam internamente existe um conceito importante a ser explorado: O delay não é garantido, o problema é que o Javascript no browser é executado em uma única thread, o que força todos os eventos assíncronos (clicks de mouse e timers) a rodarem apenas quando ouver uma “janela” de processamento. Isso é melhor demonstrado em forma de diagrama:

Apesar do nome esdrúxulo parece que esse livro vai ser mais interessante que o primeiro, “Pro JavaScript Techniques”, que eu achei muito fraco (bem aquém das minhas expectativas por ser um livro do criador da JQuery).

O artigo original está no endereço http://ejohn.org/blog/how-javascript-timers-work/

Obviamente a funcionalidade de serialização como todas as funcionalidades de suporte devem ser providas por uma interface externa, esse é um conceito fundamental e não existe nenhum motivo prático para ser diferente disso.

Um ponto interessante levantado pelo próprio Nicholas é que nunca houve nas especificações anteriores do EcmaScript qualquer referência a um formato de dados padrão, nem mesmo suporte nativo a XML foi adicionado em nenhum momento, então porque tentar empurrar JSON para dentro da linguagem? O correto é prover recursos para que JSON, XML e qualquer outro formato que venha a surgir sejam integrados da forma mais transparente possível, mesmo que por meio de bibliotecas.

Melhor do que apenas jogar pedras é sugerir uma solução melhor, Zakas postou em seu site pessoal a implementação da JSONLib, um modelo contendo 2 classes simples, uma para objetos JSON e outra para uma coleção de objetos JSONList.

1 - The addition of two new global types: JSON and JSONList. JSON represents a JSON object while JSONList represents a JSON array.

2 - Both types have a toJSONString() method that correctly encodes an object into a JSON string. The default toString() method is available but returns a string representation of the object (not a JSON string). This follows the convention set forth in E4X.

3 - The [[Put]] method is overridden in both types such that it will only accept values of type JSON, JSONList, Date, boolean, string, number, or null. Any other data types cause an error to be thrown.

4 - The JSON constructor allows an object to be passed in that has initial properties to add; the JSONList constructor allows an array to be passed in with items to add.

5 - The typeof operator should return “json” when used on a value of type JSON or JSONList.

6 - JSON strings are parsed via JSON.parse(), throwing syntax errors if they are found.

Exemplos simples de implementação:

var obj = JSON.parse(”{\”name\”:\”Nicholas\”,\”age\”:29}”);

var json = new JSON();
json.put(”name”, “Nicholas”);
json.put(”age”, 29);
var name = json.get(”name”);
var str = json.toJSONString();

var list = new JSONList();
list.put(0, “blah”);
list.push(25);
list.push(true);
var val = list.get(1);
var len = list.getLength();
var str = list.toJSONString();

var json = new JSON({name:”Nicholas”});
var name = json.get(”name”);

var list = new JSONList([1, 2, 3, 4]);
var val = list.get(2);
list.push(function(){}); //throws error

O artigo original pode ser visto em:
http://nczonline.net/archive/2008/1/537

Brendan Eich é hoje um dos maiores defensores de mudanças na estrutura da linguagem e acredita que a implementação do Javascript 2 baseado no ES4 (EcmaScript 4) nos browsers já a partir do Firefox 4 pode corrigir problemas antigos que envolvem segurança e performance. Outros especialistas, entre eles Douglas Crockford, acreditam que o modelo proposto no ES4 descaracteriza totalmente a linguagem atual deixando a programação no browser mais parecida com Java e outras linguagens igualmente rígidas.

Eu acredito que exista espaço para muitas melhorias na forma como fazemos as coisas no browser, algumas coisas citadas por Brendan em seu blog fazem muito sentido, mas como foi citado por Douglas Crockford no vídeo The State of Ajax o browser de hoje já está sofrendo os efeitos da idade. Sejamos realistas, o que as pessoas querem são experiências mais ricas e interativas, sistemas operacionais rebuscados e processadores multi-core estão pipocando pelo mundo enquanto no browser ainda ficamos maravilhados a cada drag & drop, toda vez que alguém cria uma interface relativamente inteligente e com recursos que seriam absurdamente banais se o runtime fosse por exemplo o flash e não um browser, nós aplaudimos e o cara ganha seu pequeno artigo no Ajaxian.

As aplicações Ajax do futuro, assim como as bibliotecas Javascript podem ser muito melhores e mais eficientes do que as de hoje. A proposta do ES4 fala justamente disso, de criar um ambiente onde os desenvolvedores de bibliotecas vão encontrar as ferramentas para programação séria (tipos, iterators, constantes, classes e um compilador JIT por exemplo) sem no entanto abrir mão de um subset simplificado para os webdevelopers acostumados aos prototypes da linguagem atual. Existe hoje uma corrida para fazer com que o browser seja mais multimídia e tenha uma performance melhor para conteúdos mais sofisticados, além do Tamarin e do ES4 é possível ver as equipes dos browsers competindo para implementar o “triturador de html” mais rápido da internet (até agora a vantagem é do Safari), canvas, canvas 3D, tags de vídeo e áudio… uma verdadeira festa.

Só que nesses esforços não existe coesão, a Microsoft não disse em nenhum momento que suporta o ES4, pelo contrário… provavelmente veremos uma versão do EcmaScript 3 bem mais enxuta nos próximos browsers da MS, e sem o IE não temos um padrão, nós sequer sabemos como será o Internet Explorer 8 e que novidades ele vai trazer para a comunidade de desenvolvedores. Enquanto o browser não evolui temos Silverlight e Flash correndo por fora como plataformas RIA, eu não me atreveria a dizer que uma dessas tecnologias virá a substituir o HTML e o modelo de internet que temos hoje, mas a constatação é óbvia, o ser humano não usa aquilo que é melhor… ele usa aquilo que está amplamente disponível.

Estou esperando, por mais estranho que possa parecer acredito que a única empresa realmente mirando na direção certa é a Microsoft, a idéia de usar o EcmaScript 3 como base me parece boa já que a linguagem vai continuar compacta, é diferente do monstro proposto no ES4 e a Microsoft ainda se garante com o Silverlight para quem quiser “algo a mais”.

Que Deus nos livre de viver outra era de incompatibilidades no melhor estilo Netscape vs IE.

• Templates para projetos Silverlight 1.1 em VB e C#
• Website templates para desenvolvimento Silverlight 1.0 usando javascript
• Editor de XAML com syntax highlight e intellisense
• Intellisense para elementos XAML nos arquivos code-behind VB e C#
• Integração de componentes Silverlight em projetos Web.
• Possibilidade de criar referências de Web Services em um componente Silverlight.
• Integração com Expression Blend para facilitar a cooperação entre designers e programadores

Para quem realmente quer tirar proveito da capacidade do WPF e do Silverlight é fundamental ter a mão um editor gráfico de XAML como o Expression Blend, uma das maiores inovações do framework 3.5 é justamente essa habilidade de gerar interfaces sofisticadas, mas o Visual Studio não é uma ferramenta de design e você logo vai notar que editar XAML na mão não é das tarefas mais divertidas. Vale o esforço, quem aprender a usar o Blend direitinho vai poder usar seus truques tanto em aplicações WPF e Xbap usando VB e C# quanto em aplicações Silverlight, onde o modelo de eventos é programado em Javascript (o que poderia ser mais divertido?). Infelizmente nada de doce para as crianças que estiverem brincando de Visual Web Developer Express Edition, mas eu acredito que os recursos possam ser integrados depois, já que existem templates de projeto WPF no Visual C# 2008 Express Edition.

É o melhor de 2 mundos, mesmo com as ferramentas ainda em estágio 1.0 (quase Alpha) esse é com toda certeza o futuro das aplicações Windows e RIA em plataformas Microsoft.

Se eventualmente alguém não pescou, “a fast guy in tights” ou “um cara rápido usando colan” = Flash (The Flash, o herói), e “a movie about coffee” ou “um filme sobre café” = Java “Script”.

Dilbert > Resto