Novo release do Jails 1.0.0 e a experiência de escrever um framework

Fala meu povo!

Eu às vezes me sinto um pouco babaca escrevendo aqui pra mim mesmo ahahhaahah. Mas se você é um dos poucos que acompanham este blog parado tenho uma boa notícia!

Acabei de lançar a última versão do Jails, projeto de arquitetura AMD que comecei faz algum tempo já. Não imaginava que fosse chegar à esse ponto, não tinha a mínima idéia o quanto ela evoluiria desde a sua concepção lá no início. Me lembro que pensava que se eu utilizasse ela na versão 0.0.2 ( lá no comecinho ) eu iria melhorar muito meus projetos… Mal sabia o quanto ela ainda iria melhorar.

Jails 1.0.0 ( Orpheus )

Bom, todos os releases tem um codinome baseado em alguma figura mitológica, é por isso o nome estranho ali. Mas falando do que mais importa, esta versão é estável e totalmente reescrita do zero.

Quando você tem uma idéia, você a rabisca, faz rascunhos primeiro, depois lapida, testa, gera algumas versões e vê como ela se comporta em um cenário em produção.

Bom foi isso que eu fiz basicamente, quando ela se tornou promissora e realmente fazia sentido ser usada, decidi então reescrever usando os mesmos conceitos, porém melhorando a parte técnica do código. Isso faz com que melhore tanto na performance, quanto na manutenção, e abrindo novas possibilidades ao mudar algum approach.

Independente do jQuery/Zepto

Esta foi uma tarefa bem difícil pois ao contrário do que a maioria pensa, trabalhar sem jQuery é complicado. Dar suporte à maioria dos browsers não é uma tarefa fácil. O Jails ainda não dá suporte à maioria deles, mas uma característica nesta versão faz com que você acople bibliotecas nela que faz com aumente o espectro de compatibilidade. Por exemplo, se usar um Adapter jQuery 1.11 ela vai dar suporte à todos os browsers que esta versão do jQuery dá.

Repositórios – Components & Modules

No começo eu estava tão empolgado com a idéia que queria inflar o repositório com módulos e componentes. Com esta nova versão, percebi que a maioria deles tinha dependência com o jQuery/Zepto, mas não precisariam ter.

Não foi só a biblioteca que foi ganhando maturidade, mas eu também, ao utilizá-la no dia-a-dia e percebi que ao invés de ter repositórios lotados de componentes e módulos beta, eu deveria me preocupar mais com a qualidade dos componentes/módulos que eu estava escrevendo.

Eles também ganharam uma interface um pouco mais bonita, um lugar para buscar e ler sobre a documentação e ver exemplos.

Compartilhando Exemplos

No início eu hospedava em cada módulo/componente os exemplos que fazia. Isso começou a fazer menos sentido conforme fui amadurecendo o projeto, não fazia sentido criar uma série de exemplos e ficar commitando no github…( Ahh vá !! ) Oras… pra que serve jsfiddle, codepen, plunker? Então agora, os exemplos são todos hospedados nestes serviços..

Mas, existe um caso que vale a pena ser hospedado. Alguns projetos eu fazia e deixava na minha máquina, eram aplicações para testar o funcionamento e comportamento do Jails. Existem mais arquivos, e são mais complicados de serem testados em serviços de compartilhamento de código pelo fato destes serviços serem mais lentos por estarem na nuvem.

Então criei um repositório chamado Demos e lá ficam estas aplicações, no momento existem apenas duas, uma aplicação Flickr usando o serviço JSONP do próprio, e uma aplicação TodoMVC, um fork daquele projeto famoso.

Documentação…

É a parte mais chata de todas né… bom dei uma melhorada no padrão das documentações dos módulos e componentes, mas preciso ainda dar um grau na documentação do próprio Jails…

Por enquanto está lá meio capenga na wiki do projeto, mas acho que a wiki do github não tem um apelo visual dos melhores.. Acho que vou melhorar esta documentação e usar o bom e velho gitbook.

Exército de um homem só

Nem preciso dizer que não tenho qualquer suporte e/ou contribuição né? Mas isso não é de fato o que me incomoda. O que realmente me incomoda é o fato de eu não conseguir ainda “vender” este projeto, mostrar o potencial dele para as pessoas…  então é o fato de ninguém realmente ter usado que me deixa mais angustiado…

Estou sofrendo do estigma de “mais um framework javascript” e lutar para ter a atenção que React, AngularJs, Ember, Backbone é certamente uma luta perdida, praticamente Davi vs Golias.

Motivação

Mas não se trata de ganhar uma luta, ou aparecer mais que os outros… Recebi alguns comentários, emails e stars no github que me motivaram a continuar. E não são só estas as minhas motivações.

O fato é que está FUNCIONANDO, não no sentido técnico, mas no sentido filosófico, está cada vez mais fazendo sentido escrever pequenos frameworks, pequenas bibliotecas. Eu realmente estou escrevendo menos código, estou conseguindo me divertir MUITO mais desenvolvendo e estou olhando para um código antigo feito em Jails com orgulho, e não mais com aquela sensação de que tudo ficou um lixo. Inclusive pensando bem…era este meu objetivo principal.

Consigo ver agora nos projetos que utilizei o Jails, o que mais pode ser feito, ao invés de pensar em refactories. Ao invés de pensar em que módulo melhorar, pensar qual módulo poderia agregar mais ao site, como um notificador quando algum módulo do site quebra, como fazer um BI desacoplado, etc etc etc.

Agora penso muito mais em como posso agregar com outras soluções, ao invés de pensar em como posso destruir e começar tudo do zero. Mesmo que seja a única pessoa no mundo que esteja usando, já valeu MUITO à pena.

Eu já utilizei outros frameworks, outras arquiteturas, novas e antigas… já tentei de tudo. Posso dizer com um PUTA orgulho… Nenhum deles, até agora, me faz “dropar” essa iniciativa e migrar para outra solução. Simplesmente porque o projeto não mira as inovações do mercado, o projeto é pé no chão, simplicidade aqui é tudo, e a modularização faz com que qualquer coisa nova revolucionária e já consolidada, possa ser acoplada de maneira muito simples.

Posso mudar a micro-arquitetura das aplicações de acordo com o projeto, e não engessar todas elas numa única arquitetura. Mantendo sempre a simplicidade, acho que o projeto só tem a crescer mais e mais.

Abaixo cito uma das frases que mais tem feito sentido para mim nos últimos tempos, reflete a verdadeira essência do Jails, sempre penso nela quando vou refatorar o código do projeto, ou quando estou escrevendo um componente/modulo e penso que preciso colocar mais coisas:

…It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to subtract. 

Antoine de Saint Exupéry – Terre des Hommes (1939)

 

 

Anúncios

Jails + Riot – A React-Like view.

Olá meus queridos!

Queria mostrar como é interessante trabalhar numa arquitetura modular, uma vez que você expande suas possibilidades de forma ilimitada. O Jails vem de fábrica com uma view default, esta view é um componente que utiliza o Mustache como engine.

Mas você pode querer usar uma outra engine certo? Você não deveria ficar engessado ou poderia escolher outra forma de renderizar as coisas na tela.

Bom, neste post eu vos apresento o Riot.js. Para quem não conhece, eu sugiro muito que conheça, pois é um daqueles micro-frameworks muito bem feitos, bem documentado, pequeno, e muito muito útil.

Riot implementa Virtual DOM e Custom Tags… Isso mesmo fera… Exatamente aquilo que mais gostamos no React, e ainda o implementa em 3kb.

Para quem não conhece, Virtual DOM grosseiramente falando é uma forma de abstrair a árvore do DOM em uma estrutura de dados independente e muito mais rápido de manipular do que a árvore DOM do browser.

Ele basicamente faz o diff das coisas que alteraram nesta árvore e apenas atualiza o elemento no DOM que foi alterado, portanto, você consegue um ótimo ganho de performance.

Além disso, Riot permite criar uma CustomTag, e ainda da forma mais fácil do mundo, e ainda fica mais fácil usando o riot-view do Jails como wrapper:

Screen Shot 2015-06-20 at 12.24.27

Criar um TODO list é simples e o template html é tão simples quanto criar um código html:

Screen Shot 2015-06-20 at 14.00.58

Para saber mais, só acessar o repositório do componente.

Jails + Riot component

Abraços

Jails – Módulo Debugger

Depois de bastante tempo satisfeito com o framework, eu precisava testar sua modularidade com um desafio bastante interessante.

O Jails de fábrica não possui um debugger, eu não coloquei dentro do framework breakpoints pra disparar um evento caso algo não exista, caso algum componente não esteja na página, ou se você esqueceu de carregar alguma coisa. Isso porque não é papel do framework saber onde você errou.

O papel dele é bem claro, facilitar a composição dos seus componentes e abstrações do seu projeto AMD, apenas isso.

Mas todo o framework precisa de um debugger, de algo que te diga onde errou, e não precisa ser algo muito complexo, basta apenas um log avisando do que esqueceu, porque é impressionante o tempo que ficamos olhando para um código que não funciona por causa de uma besteira…

É por isso que escrevi o Module/debug no repósitório oficial do Jails, é bem rudimentar, deve evoluir com o tempo, mas já ajuda pacas!

Ficou até bonito a forma como ele mostra os erros, às vezes dá até vontade de fazer errado só pra ver o log xD.


Screen Shot 2015-06-13 at 21.47.25

É MUIIITO fácil de carregar e deixar ele rodando, é um módulo como qualquer outro, se quiser saber mais sobre como carregá-lo basta dar uma conferida no repositório.

https://github.com/jails-org/Modules/tree/master/debug

Um grande abraço!

 

 

Javascript anti-patterns – Nomenclatura

Olá meus queridos!

Acho que eu não cheguei a falar sobre nenhum anti-pattern no blog, pelo menos não que me lembre… Postei bastante sobre padrões e com o passar do tempo você começa a se perguntar se aquilo que acredita faz sentido ou não.

Gostaria de discutir um assunto que é meio polêmico, que é o modo como você padroniza a nomenclatura das suas variáveis no Javascript.

É claro que estas são as minhas opiniões e em algum momento eu posso entrar em contradição em algumas delas, porque no final tudo está relacionado com o que gostamos ou não, é puramente uma questão de gosto.

Anti-pattern – pParameter

Este foi um dos primeiros anti-patterns que eu não entendia. A idéia aqui era colocar um antes do nome da variável para indicar que esta era um parâmetro de função.


function set( pName, pValue ){

my.object.name = pName || '';
 my.object.value = pValue || {};

}

Eu não estava muito certo do porque saber que uma variável vinha de parâmetro ou não era tão importante. Afinal de contas, é apenas uma variável.

Se você perde o tracking das variáveis das suas funções, isso pode significar que sua função está desnecessariamente complicada e/ou ilegível. Ao invés de simplificar a lógica, separar melhor as tarefas entre mais funções, as pessoas acreditam que é melhor criar um padrão para solucionar algo que pode não ser o verdadeiro motivo para um código difícil de se entender.

Escrever um nome que faça sentido, sucinto e simples ajuda muito mais a entender o que está fazendo do que padrões desnecessários.

function create( name, properties ){

    my.object.name = name || '';
    my.object.value = properties || {};

}

Anti-pattern – _underline

Diferentemente do padrão anterior, este é um conceito aprovado mundialmente… O que me deixa extremamente espantado… Independente do gosto, este “padrão” é inútil.

O argumento usado nesse padrão é que, se você constrói um objeto que possui um método privado, você deveria colocar um “_” antes para avisar o programador de que aquilo se trata de um método privado:

    function myModule(){
        return {

            _naoUse :function(){
                // Tudo o que faz o código funcionar
                // Está aqui
            },

            use :function(){
                this._naoUse();
                // Tudo o que é seguro e pode ser usado
                // Por qualquer programador é feito aqui
            }
        }
    }

Eu tenho quase certeza de que este padrão, pelo menos no Javascript, foi pensado por alguém que não conhecia muito bem a linguagem.

O Javascript possibilita nativamente dois níveis de visibilidade para variáveis, ou uma variável é privada ou é pública. Simples assim… qualquer coisa diferente disso é uma implementação para tentar reproduzir outros tipos, ou uma viagem dos gênios por trás do ES6 e ES7.

O fato é, nestes últimos 10 anos programando na linguagem, eu nunca precisei de nenhum outro nível de visibilidade.

A minha dica é, quando você cria um objeto que precisa ter interface com o mundo exterior, implemente esta interface utilizando métodos públicos e quando alguma lógica é essencial para manter o funcionamento coerente do seu objeto e não deve ser acessado de fora, implemente-a utilizando variáveis e métodos privados.

    function myModule(){

        var tenhoAlma;

        function codigoProtegido(){
            //O core do seu objeto deve ser protegido
            //de forma privada

            tenhoAlma = true;
            //Ninguém pode me tirar a alma
        }

        return {

            use :function(){

                codigoProtegido();
                // Tudo o que é seguro e pode ser usado
                // Por qualquer programador é feito aqui
            }
        }
    }

Leia mais sobre Closures em Javascript, sabendo disso, começa a entender como proteger seu código.

Aconselho também a ler sobre Information Hidding Encapsulation. Estes conceitos de orientação à objetos são muito mais valiosos para você do que padrões desnecessários.

Ah… se o motivo para usar underline é informar que o método é perigoso, bom… se você pudesse criar um botão para destruir sua casa, você o criaria e deixaria um bilhete informando as pessoas que não devem apertar?

Anti-pattern – $variable

Eu acho que tudo aquilo que vai contra os nossos princípios nos incomoda. Mas existem certas coisas que nos fazem querer mandar matar. Este é um dos anti-patterns que mais me irritam e um dos mais recentes.

Eu acredito que tenha sido criado graças à mais popular das bibliotecas javascript, a jQuery.

A idéia aqui é colocar um antes do nome da variável para indicar ao programador que está lidando com um objeto jQuery ao invés de um [HTMLNodeElement].

Seu código fica tão bonito quanto uma bunda suja e peluda:

    function ohGod( $element, $html ){

        $element.remove();
        $html.addClass( 'ready' );
        $html.append($element);
        $element.addClass('droped');
    }

Eu não sei vocês… mas a impressão que eu tenho é de que estou vendo um código php. Eu não tenho nada contra php, aliás eu gosto muito desta linguagem, só que o problema aqui é que estamos programando em Javascript.

O que torna mais estranho pra mim é que o mesmo programador que bota $ para avisar que está lidando com um objeto jQuery, é o mesmo que não coloca obj, arr, str, num, antes das variáveis, uma grande incoerência.

Ou seja, todos os outros objetos do javascript não tem importância saber o que são, só há importância saber se é um jQuery. Afinal de contas, você só pode se confundir com este tipo de objeto né?

Óbvio que não… colocar obj, arr, str, num, $ é o que mais me dói, porque isso é falta de conceito puro da linguagem.

Conceitualmente se você coloca numVariavel para dizer que é um número, você também estaria correto em colocar objVariavel para a mesma variável, porque número é um objeto aqui. Mais do que isso, podemos ter uma infinidade de objetos criados para um propósito específico, você vai criar um prefixo para cada um deles?

O maior poder da linguagem é o fato dela ser dinâmica, isto significa que uma variável que é string num momento, pode virar um objeto em outro momento. Não precisa se desesperar com este dinamismo, nem tentar “resolver” este “problema”. Isto NÃO É UM PROBLEMA. 

Então o que?

Ponha uma coisa na cabeça, o que faz o código ficar ilegível é sua falta de coerência, a falta de organização, uma arquitetura equivocada…isto não tem nada haver com a linguagem ou com falta de padrões ou anti-padrões.

Um programador que usa uma variável só e fica reescrevendo ela o tempo todo vai ter um código ruim independente da linguagem. Colocar prefixos para te alertar sobre o tipo da variável é no mínimo um contra-senso nesta linguagem, se tiver 20 menções da mesma variável no código, e precisar mudar o seu tipo, espero que não queira fazer um find/replace para mudar o nome dela para o tipo novo escolhido…

Se você ao olhar para o código tem a necessidade desesperadora de saber seu tipo, escolha outra linguagem, fuja de Ruby e Javascript. Eu sugiro C/C++, Java ou C#.

Programadores Javascript tem inúmeras vantagens em comparação à programadores de outras linguagens. Nós já sabemos há muito tempo que programar comportamentos é melhor do que acoplar nossas classes através de heranças clássicas. Naturalmente a linguagem nos força a programar assim…

Você pode treinar seu olho e sua mente para pensar de forma dinâmica, para se programar nestas linguagens devemos pensar em duck typing. Programamos comportamentos, portanto:

When I see a bird that walks like a duck and swims like a duck and quacks like a duck, I call that bird a duck.

Não criem padrões para ajudá-los a entender a linguagem. Gastem este tempo para aprender a mesma. Nada vai garantir que outras pessoas sigam o seu padrão. Saibam fazer contas, com laranjas, bananas e maças.

A igualdade 3x+9 = 0 também pode ser reescrita como 3y+9 = 0, você deve saber resolver das duas formas, não padronize a matemática se tem problema com a variável y.

Sem preguiça, olhe o código como quem gosta da linguagem, acostume-se a entender como identificar os tipos.

Desafio

Vou fazer um teste agora, usando a psicologia reversa, geralmente quando existe um desafio todo mundo deixa a preguiça de lado pra mostrar o quão melhor que os outros é…

Abaixo segue um código simples em javascript. Consegue me dizer quais são os tipos das variáveis existentes no código abaixo?

    function desafio( container, paragraph ){

        var name, lastname, age, person, nodeName;

        name = 'Angus';
        lastname = 'Young';
        age = 60;
        nodeName = document.createTextNode( person + ' ' +lastname );

        person = {
            name :name,
            lastname :lastname,
            age : age
        };

        paragraph.appendChild( nodeName );
        container.append( paragraph );

        return person;
    }

 

Vai me dizer que leva muito tempo para identificar quais são as variáveis do tipo nodeElement e qual é a do tipo jQuery…

 

jQuery, você precisa muito mais dele do que imagina.

Ultimamente eu tenho visto uma série posts sobre o fato de que não precisamos usar mais o jQuery. Acho interessante todos os posts que nos fazem repensar no que estamos fazendo. Mas eu acho que a maioria começa a seguir uma linha de pensamento que não necessariamente pode estar de acordo com a realidade.

A impressão é de que as pessoas vão no fluxo, se parar para pensar a gente precisa muito mais do jQuery do que a gente imagina. Eu não acho que é fácil perceber onde está toda a genialidade da biblioteca, e quem não percebe o que está realmente por trás dela pode acabar subestimando-a sem perceber.

Na minha opinião apenas na minoria das vezes não precisamos do jQuery, e não o contrário. O exemplo mais batido é o document.querySelectorAll, mas o jQuery é muito mais que isso.

Quando você começa a desenvolver sem jQuery você passa a involuntariamente resolver problemas que não deveria estar resolvendo. E essa é uma das tarefas principais de qualquer biblioteca/framework. Um exemplo onde inevitavelmente você vai perder mais tempo e código que deveria é addClass, removeClass por exemplo, ou então em tarefas repetitivas.

$(‘p’).addClass(‘error’);

Esse simples e ingênuo comando serve inclusive para “n” paragrafos, não apenas para um. Desafio qualquer um a programar essa linha em javascript puro, sem que fique desnecessariamente verboso.

Já li alguns artigos gringos que falam que você não precisa mais de jQuery porque agora pode fazer as coisas com Javascript. Na verdade você sempre pode, porque jQuery é feito em Javascript.

Mas o jQuery tem uma série de propostas, um outro fator importante é o simples fato de aplicar design patterns sem que você se quer saiba quais são.

$(‘p’).get(2).addClass(‘error’).next().remove();

É como ler um texto, você faz muita coisa, com 1 linha de código e sabe rapidamente identificar o que ele faz. Existem alguns padrões de projeto ali.

Ainda hoje, existem desenvolvedores que mal sabem como usar Promises ou sequer sabem que existem. Quando você for desenvolver sem jQuery, você fatalmente vai acabar adicionando alguma biblioteca para resolver esse problema se realmente quer desenvolver aplicações ajax da forma correta.

Quando for utilizar Event Delegation para deixar sua aplicação mais performática, você provavelmente e intuitivamente faria isso:

$(‘body’).on(‘click’, ‘.mutable-view’, Function);

Não é só mais performática mas também resolve o clássico problema da  view que é dinâmica e que ao atualizar seus elementos filhos, estes perdem seus eventos.

Se for usar um approach Pub/Sub também terá de incluir na sua biblioteca do seu projeto caso não use jQuery.

$(‘p’).trigger(‘set’, { mydata:true });

$(‘p’).on(‘set’, Function( mydata ));

Caso ache que para um problema bem específico precisaria guardar uma instancia do seu objeto no seu elemento html teria de achar uma solução parecida com essa:

$(‘p’).data( new TextMessage(‘hello’) );

O que eu mais tenho lido e que também é utilizado como uma vantagem de não se usar jQuery é o fato de que em x browser tal método é mais lento, ou há problemas de memory leaks e tudo mais. É muito provável que você cometa erros piores em outros trechos do seu código.

Nenhuma biblioteca/framework do mundo é feito para ser perfeito, provavelmente ao realizar as tarefas que o jQuery realiza na mão, você provavelmente cometerá novos erros. Identificar onde o jQuery é mais fraco e substituir por um approach mais manual é muito mais vantajoso do que substituir a ferramenta inteira.

Uma coisa é certa, você estará resolvendo problemas que não deveria resolver. Você deveria pensar como um desenvolvedor e não como um codificador. Sua cabeça deve estar aberta à problemas de caráter arquitetural. Tanto em negócios, em projetos, na vida financeira ou na própria equipe que você trabalha, as pessoas tentam atacar problemas que em porcentagem significam 5% talvez 10% do nosso tempo ou esforço total para resolver um determinado problema.

Ninguém olha para as coisas nas quais perdemos 70, 80 ou 90% do nosso esforço. Quantas vezes já discutiu com alguém da sua equipe se o melhor é “_” ou camelcase, ou então vírgulas antes ou depois. Ou se deve usar ponto e vírgula no final etc etc. Não adianta também você ser um sênior master em sublime text e ao invés de usar três comandos, usar um só. Isso não vai te trazer muitos benefícios… Quando você sair de férias, a pessoa que vai dar manutenção no seu código não vai se beneficiar das suas mãos rápidas…

Realmente, o que vai te fazer perder mais tempo é a forma como organiza seu pensamento para resolver um determinado problema, como você interliga seus objetos e componentes e como abstrai realmente um ecossistema de módulos funcionando todos juntos, é isso o que importa. O resto você pode até discutir, mas deveriam ser assuntos com prioridade bem mais baixa…

Cada dia que passa  estamos desenvolvendo aplicações mais e mais complexas em js. Não faz muito sentido voltarmos nosso pensamento para trás e desenvolver em js puro. Salvo rarísssimas excessões. Pergunte para um programador Rails, se ele refaz suas aplicacões em Ruby, só porque ele pode… Talvez uma ou outra faça sentido, mas é mais provável que esta tarefa seja concebida como uma refatoração.

Em alguns posts eu li algo como “jQuery foi feito para designers”. Eu não sei de onde isso surgiu, pode até ser verdade na sua concepção lá no início, mas a biblioteca está na comunidade há um bom tempo e ela evoluiu muito. Se um designer consegue usar a biblioteca e fazer funcionar, isso é mais uma prova de que a biblioteca é muito boa, não é nenhum demérito e não significa que você como programador não tenha nada para aprender com ela. Muito pelo contrário, eu duvido que a maioria dos programadores front conhecem bem a biblioteca, e se conhecem, duvido que saibam utilizá-la da melhor maneira em diferentes ocasiões.

Na minha humilde opinião, o jQuery deveria ser um modelo para várias melhorias na linguagem, só o fato de melhorar a api do DOM como fazemos no jQuery, já seria um grande avanço. Ter Promises nativas, as chamadas ajax, os métodos e manipulação do DOM. Aquela grande merda que estão planejando para o ES6 colocando classes, adicionando keywords como let…. Quando eu penso que já inventaram as coisas mais imbecis, aparecem coisas novas.

O Javascript deveria evoluir de forma lenta e coerente, porque a linguagem já é MUITO boa… mudar a estrutura dela para tornar mais parecida com outras linguagens é a prova de que não conseguimos aprender nada do que a linguagem nos trouxe de melhor. Poderíamos ter uma chamada nativa require, define, porque a RequireJS já nos provou que é muito boa, e porque não deixá-la da mesma forma nativamente? Deveríamos dar pequenos passos, pequenas melhorias que fazem sentido, e elas fazem mais sentido pelo simples fato de terem sido TESTADAS. Já estão em produção, já se conhece os benefícios os malefícios também.

Deveríamos aprender muito com estas bibliotecas e frameworks… cada vez mais. Ao invés de andarmos para trás, tentando resolver os mesmos problemas, poderíamos ajudar mais estas ferramentas à resolverem problemas novos e estarem mais perto do que imaginamos ser o ideal para o bem do Javascript.