A big concern related to front end performance is the burden brought by javascript includes, which tend to be big in size. Fortunately there are techniques and best practices to minimize this issue. Loading javascript files (and why not CSS files…) during navigation can be a very good idea.
Laravel Framework has a class to manage assets that allows you, among other things, to load Javascript and CSS files only when needed. All you have to do is use asset containers. Add a new file to a container and it (the file) will be loaded when the route is called and the action is executed. Let’s take a look how it works from within a controller.
Let’s assume we have an asset container being registered and its assets being loaded in the layout file (layout.blade.php):
Now we have a javascript with instructions related to products only. We create a filter before in the controller:
1
2
3
4
5
6
7
8
9
10
11
12
13
class Product_Controller extends Base_Controller
{function __construct(){
parent::__contruct();// Aplicar o filtro apenas nestas actions$this->filter('before','addAssetsToProducts')->only(array('new','get'));}publicfunction action_new(){...}
When both actions new or get are executed, the file js/product.js (in this case stored in /public/js) will be inserted in our layout file and only for those actions.
Uma das grandes preocupações de performance na interface do usuário é a carga trazida pelos includes Javascript, que tendem a ser grandes. Felizmente existem técnicas e boas práticas para minimizar o problema. Carregar arquivos javascript (e pq não folhas de estilos) durante a navegação pode se mostrar um coringa no seu desenvolvimento.
O Laravel Framework possui uma classe para gerenciar assets que lhe permite, entre outras coisas, carregar aquivos Javascript e CSS conforme se precisa deles. Basta utilizar o recurso de asset containers. Adicione um novo arquivo a um container e ele (o arquivo) será carregado quando o link da funcionalidade for requisitada. Vejamos como funciona a partir de um controller.
Supondo que se tenha um asset container sendo carregado no arquivo de layout (layout.blade.php) da aplicação:
Agora imagine que no controller produtos, se tenha um javascript cujo conteúdo seja relevantes apenas para a funcionalidade de produtos. Basta criar um filtro before no controller:
1
2
3
4
5
6
7
8
9
10
11
12
13
class Produtos_Controller extends Base_Controller
{function __construct(){
parent::__contruct();// Aplicar o filtro apenas nestas actions$this->filter('before','addAssetsToProducts')->only(array('new','get'));}publicfunction action_new(){...}
Com isso, quando as actions new e get do controllerprodutos forem executadas, o javascript js/produtos.js (salvo em /public/js) será inserido no layout da aplicação e apenas para estas actions.
Tenho utilizado bastante a app do GitHub para Windows [link], que foi desenvolvida utilizando a nova interface dos produtos Windows: Metro. Quando a instalei, de cara me senti bastante confortável com a interface lisa e efeitos discretos. Pensei: “- Ohhhh: o pessoal do GitHub tem bom gosto! =D”. Pouco tempo depois, me dei conta de que o bom gosto é na verdade o look and feel Metro.
Eis que hoje de manhã me deparei com um video de 1 hora e alguma coisa, de uma apresentação oficial sobre como desenvolver aplicativos Metro utilizando HTML5/CSS3/Javascript e como estou bastante interessado em tudo o que diz respeito a essa trinca, fui conferir o video.
O que encontrei me deixou bastante empolgado. Sei que existem outras formas de desenvolver para Windows 8, como C# por exemplo, mas de cara ficou óbvio que, ao trazer para o desenvolvimento para Windows os web standards, a Microsoft aumentou muito a quantidade de desenvolvedores que podem se interessar em desenvolver para Windows e os desenvolvedores web ganharam um mercado gigantesco para explorar. Está clara a relação ganha-ganha nesta história. O melhor de tudo foi perceber que, no meu caso, eu não teria que aprender algo completamente novo: posso continuar a trabalhar com as tecnologias que amo: HTML/CSS/JS. Obviamente que existe muita coisa proprietária da MS neste pacote, mas como o alvo aqui não são o browsers e sim apps desktop/tablets/smartphones, pode-se usar sem medo “aquela transição CSS 3D que vc ficou apaixonado dias atrás“.
Durante a apresentação fiquei com a sensação de que a Microsoft fez “um Flex” que não depende do Flash Player. Não é lindo??? Isso pq existe uma suite de componentes de interface de usuário, de comunicação e utilitários na SDK, da mesma forma que o Flex tem, só que baseados em standards. E isso muito me agrada.
O único ponto que me broxou foi o one-way data binding. Qual a dificuldade em trazer two-way para algo que teve tanto esforço para ser desenvolvido?
Bem, assim que eu tiver um tempinho, instalarei o Windows 8 + o Visual Studio 2012 para começar a explorar esta nova possibilidade. Como eu já disse antes, tecnologia boa é aquela que paga as minhas contas.
Ao cair de paraquedas no mundo Javascript, vindo do mundo do Flex, a primeira coisa que senti falta foi a ausência do data binding. Mais ainda, do two-way data binding. Uma rápida explicação:
Quando se tem a disposição do two-way data binding, sua preocupação volta-se apenas para a informação, que está ligada (bind) ao um elemento de interface de usuário que a representa. Quando uma mudança é feita na informação, é refletida no elemento de interface. Quando é o elemento que recebe a mudança, esta é refletida na informação. Nenhum acesso ao elemento precisa ser feito para mudar seu valor.
A segunda ausência sentida foi a possibilidade de rapidamente desenvolver componentes de interface personalizados e utiliza-los em diversos projetos, coisa corriqueira quando desenvolvendo com Flex. Os plugins para jQuery fazem este papel e são relativamente fáceis de desenvolver, porém, é necessária bastante expertise para chegar a um resultado satisfatório. Finalizando, o uso do plugin de jQuery deve ser feito na programação e não de forma declarativa, HTML style, coisa que gosto muito.
AngularJS: a forma declarativa é como escrever HTML!
Bem, ao utilizar seu documento HTML como template, o AngularJS (http://angularjs.org/) faz, após o parse do browser, o seu próprio parse da marcação HTML, procurando por elementos conhecidos do framework, para transforma-los em qualquer coisa que vc tenha determinado. Estes elementos são as diretivas. Podemos defini-las como elementos HTML criados por você e que são parseados pelo framework em tempo de execução. É como criar componentes no Flex.
Com muita determinação, fui atrás de informações sobre como desenvolver uma diretiva básica: uma propriedade a ser utilizada num <select> para aplicar a ele o plugin jQuery Select2 (http://ivaynberg.github.com/select2/), sem que fosse necessário inicia-lo dentro do meu controller, o que me obrigaria a fazer acesso ao DOM, algo que é desencorajado no uso da AngularJS (lembra-se de se preocupar apenas com os dados?).
E como dito acima, foi preciso muita determinação para chegar num bom resultado, algo que fosse possível utilizar num projeto real. A informação está muito fragmentada, a documentação oficial não contém exemplos de como fazer algo personalizado, porém o grupo no Google ajuda muito, pois está repleto de exemplos no JSFiddle.
Agora que estamos bastante confortáveis no desenvolvimento de apps web com HTML5/CSS3 e Javascript, eu e minha equipe começamos a colocar as asinhas de fora e desenvolver elementos personalizados, que tínhamos a disposição no Flex. O primeiro a entrar para a lista foi um slider para conteúdo. Algo bem simples de usar e de entender, caso queira ver o código fonte para estudar.
Esteja a vontade para baixar, usar, clonar o código no GitHub, fazer alterações e fazer pull request.
Estava eu lendo o livro opensource do Addy Osmani sobre Backbone.js quando pesquei uma explicação bem simples sobre o conceito MVC (Model, View, Controller) aplicado na inteface de usuário. Decidi traduzir e postar aqui no blog. Seguem o original e a tradução. Para os novatos, deve esclarecer bastante coisa!
Models represent the domain-specific knowledge and data in an application. Think of this as being a ‘type’ of data you can model — like a User, Photo or Note. Models should notify anyone observing them about their current state (e.g Views).
Views are typically considered the User-interface in an application (e.g your markup and templates), but don’t have to be. They should know about the existence of Models in order to observe them, but don’t directly communicate with them.
Controllers handle the input (e.g clicks, user actions) in an application and Views can be considered as handling the output. When a Controller updates the state of a model (such as editing the caption on a Photo), it doesn’t directly tell the View. This is what the observing nature of the View and Model relationship is for.
Tradução: Models representam o conhecimento específico do negócio e a informação contida na aplicação. Pense nisso como sendo o ‘tipo’ de informação que você quer manipular – como um Usuário, Foto ou uma Nota. Models podem notificar quem quer que esteja observando seu estado atual (por ex. as Views).
Views são comumente consideradas a interface da sua aplicação (por ex. seu HTML e templates), mas não necessariamente precisam ser. Elas sabem da existencia dos Models para poder observa-los mas não interagem diretamente com eles.
Controllers gerenciam o input (por ex. clicks, interações do usuário) na aplicação e as Views podem ser consideradas como gerenciadoras do output. Quando um controller atualiza o estado de um Model (como por ex. editando a legenda de uma foto), ele (o controller) não informa diretamente à View. Isso é que a relação entre o Model e a View proporciona. Quando o model é atualizado, a View muda de acordo.
Inicio o post informando: AngularJS não substitui jQuery. Assimilou? Excelente! =D
Apesar de não ser a única solução Javascript para prover data binding (http://en.wikipedia.org/wiki/Data_binding) ao mundo HTML/Javascript/CSS, o AngularJS me chamou a atenção por ser simples de usar e ao mesmo tempo poderoso (além de ter o patrocínio do Google). Uma boa alternativa é o KnockoutJS (http://knockoutjs.com/) porém a minha preferência pelo AngularJS se deve ao fato dele ser declarativo, utilizando o HTML como um template.
Em futuros screencasts mostrarei o desenvolvimento de componentes customizados e testes automatizados.
Uma demonstração de como utilizei Javascript e JQuery para implementar um carrinho de compras no WordPress. O screencast ensinando a fazer será gravado depois.
@osmarWeb perguntou no Twitter: @vedovellio que você acha do Sencha, é um bom competidor para o Flex?
Antes que eu possa responder, é recomendado que se leia um post sério que explica bem quem é quem nesse novo buzz chamado “HTML5″ (muita gente fala sem saber e acaba aumentando a história). A HTML5 Primer for the Overwhelmed.
Minha resposta é: definitamente sim. O Sencha é um concorrente direto do Flex, sendo até mais completo em muitos aspectos.
No primeiro semestre de 2007, quando eu procurava uma boa solução para minhas interfaces em AJAX, por sugestão de uma amiga me deparei com a YUI-EXT, uma suite de componentes cutting edge que era construída em cima da biblioteca YUI, do Yahoo!. Na época encontrei muita dificuldade em aprender a utiliza-la, pois meus skills em OOP eram menos do que escassos e, por se tratar de uma iniciativa independente de Jack Slocum, a YUI-EXT não possuia muitos exemplos de uso, sendo sua documentação muito técnica.
Nesta mesma época, conheci o Flex e fiquei encantado com o universo que o cercava: resultado visual excelente, uma excelente IDE (Flex Builder, na época), facilidade de uso, farta documentação e comunidade vibrante. Não precisei de pensar duas vezes antes de esquecer completamente a YUI-EXT para adotar (e adorar) o Flex.
O resto da minha história com o Flex todos estão carecas de saber.
O tempo passou, outras bibliotecas JavaScript surgiram no mercado (JQuery, MooTools, Scriptaculous entre outras), tendo progredido em qualidade rapidamente. Mas enquanto as novas bibliotecas seguiam a linha de ferramentas utilitárias, a YUI-EXT cresceu como uma suite de componentes para interface de usuário (o que é o Flex), tendo se desvencilhado da dependência da YUI e passando a funcionar também sobre a JQuery. Por volta desta época, mudou seu nome para EXTJS. Sua adoção por grandes empresas foi maciça e atualmente a biblioteca (ou seria um framework?) é completamente independente, tendo o seu próprio core (não depende mais nem de YUI, nem de JQuery).
Apesar de tanta qualidade visual e quantidade de componentes de UI, seu licenciamento confuso e a falta de uma IDE me deixaram distante até o anúncio feito essa semana: nova mudança de nome, com a agregação à suite de duas novas bibliotecas: JQTouch e Raphaël. A primeira delas, como apenas um plugin para JQuery, já vinha fazendo nossa alegria na RIA Labs, onde a utilizamos para desenvolver a versão para iPhone do website de nosso cliente americano. A segunda eu não conhecia até então, mas ficamos encantados com o que ela oferece em termos de base para criação de componentes de data visualization.
Voltando ao Flex, o que ele tem de mais forte são os componentes de data visualization, como iLog Elixir e o FusionCharts., além dos próprios charts que o Flex oferece de forma nativa. É o que chama mais atenção e que tem mais utilidade no mercado corporativo (que é onde está o dinheiro). Faltava aos aspirantes a concorrente do Flex algo deste nível e essa lacuna ainda não foi preenchida, mas com a criação do Sencha, creio que em breve o Flex terá um forte concorrente. Explico porque.
Não é novidade para ninguém a briga de foice entre Apple e Adobe acerca do Flash Player em seus mais populares dispositivos: iPhone e iPad, que não possuem suporte à tecnologia. Mesmo a Adobe tendo se voltado para o Android, que é o OS concorrende direto do iOS da Apple, é fato que não se pode ignorar o poder de penetração no mercado dos produtos Apple. E se o Flash Player está presente na grande maioria dos devices do mundo, os webstandards estão presentes em todos e nisso o Sencha já sai na frente, pois trabalha apenas com HTML/CSS/Javascript, a trinca webstandard.
Neste momento (junho de 2010), a adoção de uma tecnologia ou outra é apenas uma questão de preferência do desenvolvedor ou exigência do cliente e sequer penso em preferir Sencha em detrimento do Flex. Mas chegará um tempo em que um sistema deverá rodar em qualquer device e então, quem estiver mais preparado crescerá mais, seja tecnologia, seja desenvolvedor.
Em tempo: mesmo antes da mudança de nome, a EXTJs já possuia uma IDE, que apesar de parecer muito boa (vi apenas o screencast de apresentação), não chega perto do Flash Builder.
Tudo isso muito bonito, concorrência é bom para todos. Mas por enquanto, vale apenas para o mundo mobile. Veja abaixo porque.
Outro bom exemplo. Neste video são demonstradas as novas features para formulários, porém, preste atenção que o locutor fala quais os browsers já suportam essas features. Bem… nada bom, concordam?