Javascript

O que todo desenvolvedor Javascript precisa saber

js

O título é quase um spoiler, mas saber de tudo é um tanto quanto convexo, já que o Javascript, embora padronizado no ECMAScrpit, ele segue vários caminhos e vários players, se fosse colocar em comparação à algo que você conheça não existe nada melhor que dizer: “É caneta para todo papel”.

Brincadeiras à parte, Javascript muda da água para o vinho dependendo onde ele é executado, no Chrome é de uma forma, no Firefox é de outra, No IE ele é uma hidra, no servidor ele é um bom moço, fora novas implementações como o DART, Coffescript e por ai vai.

De Janeiro para cá o que deu para lembrar eu fui juntando e guardando em minha lista de snipets, e resolvi publicar aqui para vocês guardarem e sempre consultarem quando for possível.

Me baseei em algumas coisas interessantes que eu achei sobre a linguagem, a melhor forma de aprender é tentar criar seu próprio framework.

Tipos

O Javascript é um PHP da vida, começa como String e terminar como Boolean, ele possui 9 tipos de variáveis possíveis de serem adotadas.

null – Nulo ou vazio. Semelhante ao Actionscript 3.0

undefined – Indefinido no Actionscript 3.0 seria NaN

string – String é isso em todo lugar, diferente do Java, aqui tanto faz você declarar com aspas simples ou dupla.

number – Igual no Actionscript, tudo aqui é tratado como Float e a grande vantagem é que a biblioteca Math do JS é semelhante ao AS3.0

boolean – Semelhante em qualquer linguagem de programação ( True ou False)

Array – Pode ser declarado como new Array() ou simplesmente [], semelhante ao AS3.0. Tem suporte à Multi-dimencional e várias APIs que implementam o Array Tipado. Ainda estão tentando implementar e definir isso de uma vez por todas.

Object– Igual no AS3.0,C#, Java, pode ser declarado como new Object(); ou pode ser criado de forma literal

     // new
     obj = new Object();
     // ou semelhante
     obj.title="Hello World";
     obj = {title:"Hello"};

E na hora que for verificar o tipo, por exemplo você recebe uma mensagem do servidor 1 // Numero e quer saber se é Boolean, geralmente você faria.

 
var resposta = true;
    resposta == typeof Boolean;
    // false
 
var itens = [1,2];
itens == typeof Array;
// false

O certo mesmo seria você usar o construtor

 
  resposta.constructor == Boolean;
// true

É bizarro isso, o que seria para ajudar, acaba é estragando tudo, mais bizarro é quando você pede por exemplo para definir o tipo.

 
typeof [1,2]; // Object ao invés de Array;
typeof typeof; // Saiba como destruir o firefox de alguém com isso, o Chrome dá erro de sintaxe
typeof null; // Object Essa ai é de matar

Function – Igual em toda linguagem de programação, função é função no mundo de pandora ou nas terras do senhor dos anéis, no JS ela pode ser sua maior amiga e pior amiga, é ai onde entra o problema e faz muita gente odiar o Javascript, a Mayara amiga minha detesta o JS justamente por desconhecer essas particularidades dele, espero que ela esteja lendo esse post.

Por que Functions é tudo isso?

Por que por padrão retornará sempre undefined se você não especificar o retorno, e a palavra [highlight bg=”#ff999d” color=”#ffffff”]this[/highlight] que você tanto se refere ao escopo da função pode ser considerada tanto Global (window) ou local do objeto que ela foi chamada e nunca pertencente ao escopo da função em sí.

Ex: O paraíso

 
function imprima (){
return "Hello World";
}
imprima();
 
// lazy 
var echo = function(){ return echo};
echo() === echo // retorna true;
 
// Como objeto
var somar = new Function("a","b","return a + b");
somar(15,15); // 30
 
// Pegar argumentos da forma tradicional
 
var multiplica = function(){return arguments[0]*arguments[1]};
multiplica(5,5);
// 25

Continuando com Functions, ela possui dois métodos um tanto intrigantes que tem o mesmo funcionamento, [highlight bg=”#ff999d” color=”#ffffff”]call()[/highlight] e [highlight bg=”#ff999d” color=”#ffffff”]apply()[/highlight]

var operacao = function(){ switch(arguments[0]){ case 'somar': return arguments[1]+arguments[2];break}};
 
operacao.call(this,'somar',1,3);
// 4
operacao.apply(this,['somar',1,3]);
// 4

A única diferença é que um você precisa colocar em array no caso do Apply e o outro é literal, é meio louco isso, embora você não viu nem a metade.

Passagem de parametros com valor padrão definido

Imagine você congelado no tempo sem saber por que raios ele não funciona com parametros pre-definidos.

 
var nasceu = function (resposta){ return resposta !== undefined ? resposta + ', finalmente decidiu' : "Decide ai"};
nasceu(); // "Decide ai"
nasceu('SIM'); // SIM, finalmente decidiu;
 
<pre>
 
<h3>Operadores</h3>
 
Ah, É cilada bino! Nesse ponto, aquele primeiro argumento de comparação faz você xingar a mãe <a href="http://en.wikipedia.org/wiki/Brendan_Eich" target="_blank">do cara</a> que fez o Javascript, por quê?
 
<pre lang="javascript">
true == 1// true
true == '1'//true
'1' == 1 // true
undefined == null // true
false == 0 // true
false == '' // true
'' == 0 // true

Especialmente quando você usa esse tipo de comparação em uma resposta de uma chamada Ajax, Deus! Como eu já perdi tempo fazendo isso. Embora a W3C insiste em ensinar errado, eu prefiro que você use as opções:

true === 1 // false
true === 0 // false
 
// usem o equivalente !== para não igual e %== para módulo

Verificando a qualidade do seu Javascript

Só existe um de respeito, e esse é o JSLint, não adianta você querer me convencer que existam outros para medir sua qualidade de código, o JSLint é fenômeno e faz o que promete de uma maneira direta e simples, te ajuda a corrigir erros bizarros que você não nota no dia-a-dia.

Testando o código de forma unitária

Nesse quesito, Jasmine é a resposta, se você espera que seu código retorne 5 e ele retorna 10, então ele vai te mostrar um erro, e a essência do Jasmine é bem simples para implementar.

Cada um em seu quadrado

O Javascript sofre a cada mudança do ECMAScript e atualmente na versão 1.8.6 faz com que a linguagem ganhe inimigos, por achar que é complexo, o fato é que a cada nova release essa quebra de padrão de uma versão anterior ou nova maneira de fazer alguma coisa que era mais simples na anterior, tira o sono de muita gente. Só que eu acho o seguinte, toda linguagem precisa de evolução, vai dizer que tu sabia o que era Tchu Tcha em 1999?

Essa fragmentação da linguagem é de lascar, da 1.5 até a 1.8.x fez muita gente adotar o JQuery como ponto de partida ou o Javascript.NET, justamente para não ter que lhe dar com tanta diferença de um navegador para outro, e essa é uma briga que nunca acabará, por que todos querem uma fatia dos usuários conectados, Browsers ainda são a janela da Internet.

Conheça os recursos

Fonte de material MDN (https://developer.mozilla.org/en-US/docs/Web/JavaScript)
Fonte de material de primeira (http://stackoverflow.com/questions/tagged/javascript)
Refresh no Javascript (http://typedarray.org/javascript-refresh/)
Melhor overview já feito, na minha opinião (http://en.wikipedia.org/wiki/JavaScript)

Javascript

Classes e heranças com Javascript sem usar framework

js

Usar coisas prontas adianta a vida, não investigar suas entranhas é um erro fácil de cometer. Eu tenho andado bem ocupado com EmberJS, AngularJS, BackboneJS e KnockoutJS.

E sabe o que eu descobri? Todos compartilham o mesmo comportamento de MVC, dessa semelhança o que eu mais gostei foi que ambos implementam um certo tipo de extensão de classes, é como se você registrasse ela no root do documento DOM (window).

O que garante o trunfo de um para outro são técnicas especificas como templates, data-biding, componentes UI; Ao mesmo tempo que aprendo com cada um deles de dentro para fora, eu vou escrevendo o meu, a vida fica bem mais fácil melhorar o que já foi criado, lá na frente quem sabe alguém não chegue a usar o meu!?

Certo, como é então que se usa classes e heranças no Js sem framework? Simples, implemente um você mesmo com poucos passos. Me lembra muito da época que o Actionscript 1.0 ainda estava sendo especificado, JS dos dias de hoje é o actionscript de 10 anos atrás. No dia que essa linguagem ganhar tipação das coisas, provavelmente as coisas virarão coisas, sacou?!

Boilerplate necessário

 
;(function(){
 
	var Classe = window.Classe = {};
 
	var fator = function () {};
 
 
    var inherits = function (parent, protoProps, staticProps) {
        var child;
        if (protoProps && protoProps.hasOwnProperty('constructor')) {
            child = protoProps.constructor;
        } else {
            child = function () { return parent.apply(this, arguments); };
        }
        // vindo do underscoreJS
        _.extend(child, parent);
 
        //Prototype é quem vai fazer valer a pena
        fator.prototype = parent.prototype;
        child.prototype = new fator();
 
        if (protoProps) _.extend(child.prototype, protoProps);
        if (staticProps) _.extend(child, staticProps);
 
        child.prototype.constructor = child;
        child.__super__ = parent.prototype;
 
        return child;
    };
    function ExtendsEls(protoProps, staticProps) {
        var child = inherits(this, protoProps, staticProps);
        child.extend = ExtendsEls;
        return child;
    }
    Classe.Base = function () {};
    Classe.Base.extends = ExtendsEls;
})();

Digamos que eu até poderia mudar no final e chamar direto ().call(this,name). Só que ai eu quebro a idéia de fazer simples sem precisar chamar o construtor e fazer a evaluação da classe em tempo de execução.

Ao invés disso você pode criar o construtor e inicar o que precisa dentro dele.

No final das contas eu criei outro arquivo MeuApp.js e escrevi o seguinte código.

// Classe extendida da classe pai Classe
var Carro = Classe.Base.extends({
	aceleracao : 0,
	buzinar: function (){
		console.log('bit bit, sai do meio!');
	}
});
 
// Carro de corrida extende Carro
 
var CarroCorrida = Carro.extends({
	constructor : function (name){
		CarroCorrida.__super__.constructor.call(this,name);
	},
	acelerar: function (){
		var acc = this.aceleracao > 300 ? this.aceleracao=Math.round(300 - Math.random()*300) : this.aceleracao+=10;
		$('body').html('<p>'+ acc +' km/h</p>');
		console.log(this.aceleracao + ' km/h');
	}
 
});
 
 
// Ferrari é um objeto 
var ferrari = new CarroCorrida();
ferrari.buzinar();
 
// Testar a aceleracao
window.setInterval(function(){ferrari.acelerar()},100);

Fácil, não? Ai agora é só implementar Views e Controllers, só depende do que você quiser fazer. A boa notícia é que mesmo sem tipação você pode simular tal opção sem se preocupar com decadência do objeto.

Ah! o código está no Github também.

HTML 5/ HTML5 / CSS3/ JQuery/ Web 2.0

10 mitos da incompatibilidade nos navegadores para HTML/CSS/JS

Quem anda de cabresto, sempre tende a olhar para baixo, excluindo a curiosidade de olhar o mundo exterior ao seu redor, depois que eu saltei da minha zona de conforto a 10 meses atrás, eu tinha a notória sensação de que eu descobria coisas novas a cada segundo, e as lembranças da zona de conforto me acomodaram mal, muito mal por sinal.
Uma das coisas que te deixam infeliz é a tal preguiça de inovar, justamente por que confortavelmente você acha que nunca precisa mudar, e nessa migração constante deparamos com mitos criados ou expurgados por quem não dá a mínima atenção em inovar e ser competitivo.

Quando eu comecei a estudar HTML5/CSS3/JS, eu tinha aquela sensação de mal estar adquirido, achando que nada prestava, tudo precisava melhorar, CSS então era a brincadeira de estica e puxa,Deus nos acuda!

Ao passar das semanas eu fui percebendo que os navegadores evoluíram bastante, frameworks e desenvolvedores de padrões web colaboraram para essas evoluções e no final percebi que quem estava atrasado na história era eu mesmo.

Então somei o que eu achava mito e decidi escrever esse post para você abrir sua mente e se liberar de seus medos.

10 Mitos da incompatibilidade nos navegadores

MITO 1 – HTML e CSS é feito para fazer sites e não sistemas.

Resposta: Então você nunca usou o Hotmail, Gmail, adWords, adSense na vida, você nunca usou itaú bankline, Bradesco on-line e por ai vai. o HTML e CSS é poli valente, funciona para tudo.

MITO 2 – Tenho que fazer vários ifs e elses para suportar N navegadores

Resposta: Não há necessidade, já que existem N frameworks no mercado que fazem a manipulação perfeita entre engines de navegadores, grande parte dos navegadores usam webkit/gecko e o único a usar um engine diferente é o IE com seu msie, porém na última versão 8, já vem com suporte a padrões web.

Frameworks que podem te ajudar a quebrar esse mito: JQuery, MooTools, EXT Js, Script.aculo.us, ProtoType.

Ou seja, alternativas é o que não falta para esse mito, já que todos peleijam em achar que irá voltar a época das cavernas por manipular DOM de cada engine de navegador.

MITO 3 – HTML5 é incompatível com navegadores

Respota: Desde quando HTML é incompatível com navegadores? HTML5 nada mais é que uma nova versão do HTML, existem alguns recursos como WebGL, Canvas, Audio, Video, codecs de audio e video que são específicos de cada navegador, que ao total 93% de todos os recursos que você vai usar em um único projeto é compatível com todos os navegadores.

Caso você ainda tenha problemas em achar que o HTML5 pode não rodar perfeitamente no IE7,8 você pode usar bibliotecas já prontas para isso. Uma delas inclusive é amplamente utilizada, a Modernizr.

MITO 4 – Não posso usar MVC em uma aplicação web feita em Javascript e HTML

Resposta : Mito detonado, no bom estilo caçadores de mitos, desde que javascript é javascript, e tudo é Objeto. Então eu manipulo qualquer objeto aplicando qualquer padrão existente, Aconselho você usar esse slides para te influenciar a pensar diferente.

MITO 5 – Não consigo criar interfaces com facilidade como no Flex

Resposta: É por que você não conhece o JQuery UI, YUI, Prototype UI, UKI, MochaUI, Livepipe UI, Alloy UI e GWT. Ou seja, alternativas para você criar interfaces não faltam.

MITO 6 – Aplicações Web feitas em HTML 5 e CSS3 não são cross-plataforma.

Resposta: Navegadores hoje são cross-plataformas, rodam no Linux, MAC, Windows, ios, Android e Windows Phone. Se sua aplicação fica na caixinha de areia do navegador então ela também será cross-plataforma, não tendo a necessidade absoluta de portar seu aplicativo para diferentes plataformas. Assim como no Flash Player ser cross-plataforma, é por que ele tira proveito dos navegadores.

MITO 7 – Aplicações feitas em HTML5 e CSS3 são lentas

Resposta: Uma vez que sua aplicação pronta, ela trafega muito mais rápido para o navegador do usuário do que seu SWF, já que não é compilável, é apenas lida.
O Flex compila o que você escreve em um SWF, esse SWF é binário, como uma imagem em JPEG ou PNG é. A diferença é que uma vez baixado ele se torna mais rápido por que não é interpretado. Já com HTML, CSS e JS ele é interpretado sempre que você manipula.

A grande vantagem está no tráfego de dados e na re-utilização do sistema, á que por padrão ele tem cache ativo. roda muito mais macio no navegador e não depende de plug-in.

MITO 8 – Em aplicações Web eu não consigo fazer Sockets, usar o AMF

Resposta: Você consegue sim, WebSockets são novidade, são feitos em js, veja o Node.JS. E AMF conheça o AMFJs.

MITO 9 – As IDE atuais são péssimas, produtividade ZERO

Resposta: Mito detonado também, existem N IDEs excelentes uma delas é as IDEs feitas pela JetBrains, compatíveis com os padrões do mercado e cheia de recursos, outras tão boas são para o Eclipse como o Aptana. E claro o Dreamweaver CS5.

MITO 10 – Meus aplicativos são re-escritos sempre que for criar uma versão mobile deles.

Resposta: Existem 2 posibilidades de você usar HTML, CSS e JS em aplicações Móveis, uma é usar os Media-Queries de CSS, fazendo o layout de suas aplicações responsivas. Ou criando um aplicativo específico para Mobile usando o mesmo HTML 5 e CSS3 feito para versão Web/Desktop.

Então se você chegou até aqui, é sinal que alguns mitos já passaram por sua cabeça e a dúvida pairava no ar. A minha sugestão é, ajude outras pessoas a se libertar desses mitos.

Flex/ Notícias/ Pessoal

Onde está o futuro do Flex?

Wow! Que semana foi aquela heim?! Muito se foi dito, muito ainda estará por ser. E eu faço a pergunta, onde você quer estar?

No apagar das luzes da última semana na sexta-feira, o time de desenvolvimento do Flex SDK, fez uma declaração um tanto assustadora para todos aqueles que gostam de ficar sempre na zona de conforto. E logo em seguinda (Ontem), fez uma atualização esclarecendo melhor o que fora escrito, acalmando mais os ânimos daqueles que estavam assustados.

Curiosamente, nada disso me colocou em cheque! Ou amarelado pelo fato das declarações feitas por parte do time do Flex ou Adobe. É ai onde eu explico minha história com o Flex.

Onde?
Tudo começou em Outubro de 2003, quando nos pre-releases da Macromedia existia um produto chamado Royale(Flex SDK) e Brady(Flex Builder). Nessa época eu já criava hotsites com o Flash e tinha feito 2 jogos muito utilizado no Flash Lite para dispositivos Nokia.
Eu estava em minha zona de conforto quando apareceu o Flex e a proposta que me chamou mais atenção, naquele produto em teste foi o gráfico comparativo do Apps 1998 client/server, HTML/js e Rich Internet Applications.

Eu já tinha feito apps no Flash MX, e foi nessa época que começou o termo RIA, só que existia um grande problema, o fato de não dá suporte totalmente a uma linguagem mais poderosa, deixava esse termo enfraquecido, já que surgia no mercado outros compiladores mais robustos para Actionscript 2.0 o Motion Tween e um outro chamado SWFMill. Ambos até hoje existem.

Foi ai que surgiu o Flex, a grande proposta dele era criar Apps usando sintaxe MXML e o recém lançado Actionscript 3.0. Nossa! Que mudança eu pensei, saímos da água suja do esgoto para os melhores frascos de perfumes da França.

Então, decididamente eu larguei tudo que eu fazia em Flash, era meu porto seguro e cair de cabeça no Flex, foi assim que surgiu a 3 lista sobre Flex no mundo a Flex-Brasil. Ainda hoje é a 2th maior. Eu finalizei minha frase de boas vindas com a mensagem

“E Deus disse, vão e se ploriferem” <-- vamos fazer isso

Como eu era um poeta e apaixonado heim! E não é que foi justamente isso que aconteceu? Foi dai que surgiu a comunidade Flex no Brasil, foi dai que saíram grandes profissionais e foi dai que muitas empresas tomaram por base para adotar o Flex como tecnologia.

Esse foi o Onde.

Quem?

Quem realmente cresceu a comunidade? Todos, uma comunidade precisa de apenas uma idéia e alguém que a defenda, se você tiver isso, você consegue constrúir uma comunidade, foi e é hoje uma grande comunidade, não feita por mim, mais feita de uma ídeia, quantas pessoas hoje não vivem de Flex por que começaram ali?
De lá para cá, eu consegui ser sortudo o bastante para treinar aproximadamente 3 mil pessoas, ter viajado por todo o Brasil menos no estado do MT, preciso conhecer esse lugar, tudo através da tecnologia Flex. Tem horas que eu me pergunto, valeu a pena? Até hoje vale a pena, quantas dessas 3 mil pessoas não treinaram outras ? e essas outras, outras também?

Uma comunidade é baseada em 3 pilares, Auto sustentável, colaborativa e continuidade.

Auto sustentável, é que gere receita para quem escolhe a tecnologia adotada.
Colaborativa, que os membros da comunidade se ajudem.
Continuidade, é que as pessoas acreditem na idéia que comparam, querendo ou não são idéias que movem o mundo.

Fantástico todos esses últimos anos, sem falar a quantidade de pessoas que eu conheci, fui e sou muito feliz por isso. Em cada canto desse país eu tenho um amigo, eu acredito que sou milhonário por isso. Tudo isso proporcionado por uma idéia lançada a 7 anos atrás.

Eu sou referência no Flex? Não, eu sou referência em amar o que faz.

Nunca fui apegado a tecnologia, eu fui sempre apegado a idéias, amo minha esposa, a família, meus amigos e até meus inimigos. Eu sou bastante apegado ao que eu faço, eu amo todos os dias acordar e tentar resolver problemas, geralmente dos outros.

Tive sorte o bastante de achar aquilo que eu gosto de fazer logo cedo. E minha mãe achando que eu me tornaria um cardiologista, nada a ver né? Hoje sento todo dia, ligo minha parafernalha tecnologia, faço algumas ligações diariamente e continuo ganhando o dia.

Tem dias que é um saco, mais ao final dele você sabe que fez algo de melhor, colaborou para um mundo menos complexo. Organizou mais as coisas e aos poucos você vai matando o papel e tudo que é tocavelmente simples.(A moda antiga).

Esse foi o Quem.

Quando?

Toda a minha empolgação com uma tecnologia Flex, veio acabando naturalmente a medida que tecnologias emergentes vem à tona. De 1 ano para cá, eu sempre venho estudando aquilo que me deixa confortável, que tenha um mesmo nível de raciocínio que o Flex possui.

Flex veio em uma boa época onde navegadores eram lentos, existiam apenas 3 players grandes no mercado ( M$ IE e Mozilla Firefox, Safari). Somente quando o Google entrou no campo de navegadores com o chrome eu percebi que muita coisa boa ia acontecer aos padrões Web. O que de fato aconteceu nos últimos 2 anos.
Novas engines, novos frameworks Javascript, padronização ironizada do HTML5. E de fato um novo mercado tinha surgido, meio que tímido, mais com uma tecnologia não tão compreendida.

Foi quando a Apple, entrou na briga e falou que o Flash era da era dos PCs, foi onde começou toda a murmurização do assunto.

Defensores dos padrões, cairam matando uma tecnologia que mal eles sabiam era a mesma utilizada nos caixas eletronicos do Itaú, Unibanco. Mal sabiam eles que as companhias aéreas faziam uso deles, mal eles sabiam que os primeiros infográficos no mundo eram feitos em Flash.

O grande problema do Flash Player foi ter como mãe a Adobe, ela nunca foi boa em manter um nível competitivo da tecnologia, suas IDEs então nem se fala, ela é boa em efeitos visuais, ferramentas para designers. Desde então ela deu mais ouvidos à concorrência do que sua própria capacidade de ser criativa.

Foi ai que aos poucos ela mesmo foi matando a tecnologia, por que a idéia de um Player para todas os navegadores foi enfraquecendo, a idéia de uma tecnologia robusta para criação de melhores UX e UI foi morrendo, muita gente desacreditando e isso foi tornando cada vez mais relevante para mim a frase.
Está na hora de mudar.

Mudar para onde?Por quê? Eu me fiz essa pergunta centenas de vezes, fiquei por 1 ano e meio sem rumo, comecei a trabalhar com outras coisas não ligadas a tecnologia, pensei até em abandonar de vez, sabe aquela sensação de vazio que fica? Seria excesso de informação? Decidi que era hora de parar. E parei por longos 6 meses, não escrevi uma linhazinha se quer de código. Estava farto, afinal o fiasco do lançamento do Flex 4x me deixou furioso, a Adobe estava tentando colocar o SDK amarrado a suas soluções de suíte CS e esquecendo de ficar competitiva.

O mesmo compilador usado por 6 anos e nenhuma mudança drástica, foi quando em Março desse ano eu decidi que era meu último treinamento pessoal em Floripa, nunca mais eu treinaria alguém pessoalmente ou viajaria por causa do Flex.

De lá para cá eu dei atenção as tecnologias emergentes, HTML5, CSS3, Javascript,JQuery para criação de interfaces, algo que me completasse como desenvolvedor, o que o Flex já não fazia mais. Estudei muita coisa e criei muita coisa na RIACycle com essas tecnologias, até compartilhei algumas semelhanças.

Só que ai, vi que realmente não importava qual tecnologia usar, já que o próprio Flex gerava um HTML, JS,CSS para embarcar meu SWF gerado. Já que meu cliente não dava e nunca deu a mínima para qual tecnologia eu usei para criar, ele quis e sempre vai querer o produto funcional, bonito e com uma boa experiência.

É onde caiu a ficha. Tecnologia é o produto do meio e não o produto final. Você é um modelo de tecnologia ou faz dela um modelo de negócio?

É onde entra o Futuro.

A Adobe decidiu que era melhor fazer a doação do SDK para a fundação Apache(ASF), lá o SDK terá melhor visibilidade não só na fundação, mais na comunidade, outras empresas tornaram a tecnologia melhor e mais competitiva do que nunca, lá a colaboratividade será mais rápida, as respostas vão funcionar melhor.

Por que a Apache e não a fundação Spoon? Eu não acredito na fundação Spoon por 3 motivos.

1 – É baseada em 4 pessoas. Se todos estiverem no mesmo carro e por desgraça do destino sofrerem um acidente, já era o projeto.
2 – Os 4 caras são excepcionais, criadores do Robotlegs, Swiz framework, mas uma coisa é manter um framework, outra coisa é manter um SDK inteirinho.
3 – Flex SDK é baseado na tecnologia Java, quem domina o Java tirando a Oracle? Quem tem um modelo de negócio sustentável pela tecnologia Java e que o mundo inteiro usa?

O expersite da Fundação Apache é bem melhor, por que tem mais pessoas colaborando, a visibilidade do projeto será sem dúvida, notórida, já que mais e mais desenvolvedores vão colaborar com o SDK.

E quando eu me refiro ao SDK, eu me refiro aos compiladores, aos testes automatizados, a possibilidade de usar o MXML e AS3 no lado servidor, a possibilidade de compilar para JS/HTML, coisa que já está em fase de testes pela Adobe com o novo compilador Falcon.

O Fato é, Flex tem ou não tem futuro? TEM FUTURO, e seu futuro será brilhante, desde que o Flex 3.0 entrou como produto Open-source, ele foi muito mais adotado por grandes empresas, por que temos 2 fatores, 1 depender apenas de uma corporação para cria-lo e outra é depender apenas da comunidade.

Tem que ter 2 pilares fundamentais para que uma tecnologia se sustente, seja ela Flex ou outra qualquer, é a forma híbrida da coisa, tanto uma organização séria e respeitada e uma comunidade inteira que acredita em um ideal sobre um produto.

Não é atoa que até hoje o Windows XP é utilizado em grande escala, mesmo a Microsoft afirmando que parou de dar suporte.

O Flex é o produto do meio, ele terá sempre um espaço e seu espaço tende a crescer mais ainda com seus concorrentes, ele continua sendo inovador, criando Apps móveis, criando Apps desktop e criando Web Apps.

O que você como desenvolvedor não pode ficar esperando é que tudo venha pronto, nada vem de graça, tem que tomar na marra, na garra, você tem que colaborar, tem que incentivar, tem que acreditar naquilo que você faz. Seja você empregado ou empregador.

A tecnologia Flex tem sído uma grande ferramenta que não depende apenas do Flash Player, ela depende da boa vontade de quem a faz.

Se seus gerentes lê matérias sensacionalistas e tomam decisões baseadas nelas, cabe a você acreditar naquilo que você faz, e não em mera expeculações, ele provavelmente tomará decisões que pode afetar sua vida pessoal e profissional.

Continuem apostando em tecnologias emergentes, continuem vivos e alívidos com o Flex SDK e BlazeDS nas mãos da fundação Apache, continue apaixonados elo que vocês adoram fazer, Softwares.

Não percam a empolgação, não se deixem descabídos por decisões mal feitas pela Adobe, ou pronunciamentos mal elaborados. Continuem amando o que faz, tecnologias emergentes são excepcionais oportunidades de novos negócios, de novos modelos de negócios de novas fronteiras para você.

Seja criativo, nunca deixe de elaborar novas idéias, de acreditar naquilo que você ama, quando você aprender e começar a se conhecer, você vai ver que tudo é do ponto de vista de alguém, e que nem sempre esse alguém tem razão.

Que venha o futuro do Flex, da Web, das tecnologias emergentes, eu estarei sempre de braços abertos e fazendo o que eu sei de melhor, Desenvolver, ensinar e compartilhar.

Por que eu ainda tenho muito a colaborar.