Category Archives: JavaScript

Imersão ExtJS 4

Olá, é com grande satisfação que gostaríamos de compartilhar com você nosso novo curso curso online, o Imersão ExtJS 4 que será ministrado pelo Christiano Milfont que irá tratar sobre as melhores práticas para desenvolver WebApps com riqueza de usabilidade usando ExtJS 4.

O Framework Javascript de propósito geral ExtJS possui Widgets [componentes] que fascinam e agilizam o desenvolvimento principalmente de aplicações comerciais que são migradas do Desktop.

Existem bons livros já publicados, como o da brasileira Loiane Groner, que também está publicando um curso gratuito no formato de Screencasts cobrindo o básico do ExtJS e aprofundando com muitos exemplos. O próprio Framework contém uma excelente documentação, uma gama enorme de exemplos, abrangendo inúmeras situações.

Bootstrapping

Uma grande dificuldade para desenvolver WebApps, principalmente para desenvolvedores especializados no Backend, é a aridez de desenhar a interface com CSS e trabalhar o comportamento da visão com Javascript.

Enquanto os sistemas operacionais fornecem um conjunto de componentes de Interface por meio de API e Look’n’Feel padronizado para você simplesmente construir a aplicação, na Web o trabalho é bastante artesanal, inclusive com a necessidade de trabalhar com ferramentas especializadas de design como GIMP ou Photoshop.

Não é à toa que o Toolkit Bootstrap disponibilizado pelo Twitter faz tanto sucesso, inclusive com o mesmo nome da técnica de construir um modelo de layout com componentes padronizados para facilitar a construção de aplicações web.

O ExtJS já fornece embutido no seu Framework todo um conjunto de templates e elementos gráficos para utilizar com seus componentes, além da abertura para customização caso seja necessário. Além disso existem diversos templates distribuídos por terceiros.

Diferencial do Curso

Como já mencionado, existe uma infinidade de materiais disponíveis na Web onde você pode aprender por conta própria.

O diferencial do nosso curso não é simplesmente aprender sobre os Widgets e montar telas ricas, é a experiência de quem desenvolve com o Framework desde que ele era uma extensão do YUI [Framework do Yahoo].

Iremos demonstrar as melhores práticas de como construir aplicações verdadeiramente ricas que são proibitivas de serem construídas num processo artesanal por meio de JS e CSS por dar muito trabalho.

Vamos tratar sobre assuntos espinhosos, como extender componentes, modificar o comportamento natural de elementos do próprio HTML, como navegação por meio de eventos que não existem e ainda vamos dar uma palhinha de como construir uma aplicação que se adapte a dispositivos móveis usando o SenchaTouch com o mínimo de esforço dentro do possível.

Matricule-se já e garanta sua vaga.

Engine de template em Javascript com estratégia de HTML Sprites

Apresentei no QCON São Paulo 2011 um Lightning Talk: “Engine de template em Javascript com HTML Sprites”. A estratégia consiste em montar um template com suas Partials no mesmo arquivo html para facilitar o trabalho de renderização usando DIVs como “sprites”, assim como fazemos com CSS.

Para a estratégia eu construí uma Engine de Templates minimalista quase Logic-less baseada na EL do JSP. Quase Logic-less porque a única lógica permitida são sentenças como IF Ternário, comparações e o conceito de Helpers (como no Rails), que não passam de funções javascript simples que retornam alguma formatação para a VIEW.

No meu curso Javascript Fundamental, um dos exercícios é construir essa engine que chamei de ELJS.

A grande diferença entre o ELJS e o Mustache (Engine Logic-less famosa) são os Helpers e o conceito de compilação separado da própria renderização. A grande vantagem da compilação é fazer um parser das marcações e deixar o template preparado para interpolação sem precisar tratar sentenças a cada chamada de “render”.

Assim como o Mustache, o tratamento dos Partials é feito fora da Engine, no meu caso eu tratei no plugin para jQuery (TODO: terminar plugins para outras bibliotecas/frameworks).

Atualizei o plugin para jQuery apresentado no evento com a última versão que usamos nos nossos projetos e tornamos Open Source. Criei uma página de exemplo como funciona a estratégia, mas os testes facilitam a compreensão, principalmente o teste do plugin.

Dá uma olhada nos slides novamente para entender a evolução dessa estratégia.

CoffeeScript

Resolvi falar sobre CoffeeScript porque algumas pessoas com poder de influência em diversas comunidades estão evangelizando essa aberração.

História

Vou começar pelo começo, aproximadamente entre os anos de 99 e 2009 a comunidade Javascript passou se degladiando sobre o futuro da linguagem, uma parte defendia algo próximo ao ActionScript [exemplo fácil só para um termo de comparação], com classes e outras características que não existem na linguagem que é prototype-based. Venceu a turma conservadora, que defendia js se manter como estava.

Para terem uma idéia da confusão, hoje existe a especificação ECMA 262 versão 3 e versão 5, justamente porque a 4 ficou no meio dessa briga e nunca chegou a existir.

Desculpas

De 2006 pra cá algumas linguagens antigas como ruby e python influenciaram todas as comunidades de desenvolvedores com argumentos – dos quais concordo em parte – como expressividade, facilidade na leitura por humanos com menos ruído sintático em vez de apenas performance ou outra característica técnica que poderia muito bem ser trabalhada em um nível inferior (Como por exemplo, para cada linha que voce evita de escrever em Python, existem centenas em C que fazem o trabalho).

Primeiro argumento do uso de Coffeescript é justamente sobre ruído sintático do Javascript, mas inventaram uma SINTAXE NOVA que não é igual a Ruby e nem Python, mas há métodos e características de ambas para justificar seu uso. Ora bolas, porque não terem implementado um subset direto do Ruby?

Incluíram o Pattern Klass como funcionalidade dessa linguagem sendo que Frameworks antigos como Prototype já implementavam isso.

Em Javascript você consegue Closure, Currying e outras construções funcionais porque function é um cidadão de primeira classe na linguagem, consegue ter Mixin até mais fácil do que em Ruby porque além de dinâmico é de tipos fracos.

A justificativa de se usar Coffeescript por causa de sintaxe é a mesma de muitos que usam Groovy porque a “curva” de Java seria menor. Falácia grave. O problema de um desenvolvedor não aprender uma sintaxe porque é assim ou assado já demonstra em muito que ele não quer aprender as características da linguagem e vai continuar “programando em Java” usando Groovy.

Isso é muito comum, já passei por muito programador PHP programando em Ruby como PHP ou programador Java programando em javascript como Java.

Alguns entusiastas de Ruby defendem o uso porque lembraria a sintaxe que se sentem familiar e por ironia citam List Comprehensions, funcionalidade que existe no Python e não no Ruby. Como voce contorna isso no Ruby? Vamos parar com a covardia e sair da zona de conforto?

Problemas

Eu tenho um problema com linguagens intermediárias com Enhanced, mas vá lá, podemos viver com isso.

javascript tem muitos problemas, mas não é apenas sintaxe, precisamos normalizar todas as versões e especificações e atacar as fraquezas conhecidas, não sair criando pseudo-linguagem.

List Comprehensions que já citamos, tem na versão 1.7 que o SpiderMonkey implementa (usado pelo Firefox) , mas o V8 (usado no Chrome, Safari e no node.js) não implementa, Rhino implementa e assim vai, uma confusão só. Os navegadores basicamente implementam a versão 1.5 que é equivalente a ECMA 262 – versão 3 que chamamos de ES3 (ECMA Standard 3), o V8 implementa a ES5 e mantém compatibilidade com 1.5. SpiderMonkey implementa a 1.5, mas não tem compatibilidade entre ES5 e 1.5, se quiser usar funcionalidades definidas na ES5 tem que usar versão 1.8. Confuso? É assim mesmo.

Se Javascript não se encaixa no seu projeto, não a use, é porque não serve mesmo, agora tentar mudar as características (como assincronismo, só para aproveitar o momento e bater em ferramentas como Step) para se encaixar é querer usar a furadeira para pregar um prego.

Se você é obrigado, já que não existe outra alternativa na camada de apresentação em Webapps (RIP ActionScript 🙁 ), use os frameworks modernos que já implementam o Crossbrowser aceitável (nunca vai ser decente) e se beneficiam de sua idiossincrasia. Coffeescript só está em evidência por causa do node.js, já que há várias bibliotecas e até Frameworks implementados com isso, se a discussão aqui for navegador, nem invente.

Eu por exemplo sinto mais falta de incluírem o “method_missing” na especificação do que interpolação de strings.

Ainda pra completar há uma rivalidade entre os defensores de Frameworks como entre o jQuery e Mootools que não sei de onde surgiu, mas nós humanos somos assim mesmo, brigamos por religião e por Framework.

Javascript é de tipos fracos, dinâmicos, sem classes, orientada a protótipos e assíncrono… aprenda a linguagem. Já basta de uma linguagem a mais para cada chilique de desenvolvedor por causa de um “{” ou “;”. Como alguém, que não lembro quem foi, escreveu no twitter dias desses: “Antigamente todo mundo queria seu próprio Framework, hoje todo mundo quer sua própria linguagem”.

Aproveite e vá me assistir no QCONSP 2011 que vou demonstrar algumas coisas bacanas de se fazer com Javascript e como a sintaxe não atrapalha 🙂