O que é Node.js?

nodejs-logoNode.js é uma plataforma construída sobre o motor JavaScript do Google Chrome para facilmente construir aplicações de rede rápidas e escaláveis. Node.js usa um modelo de I/O direcionada a evento não bloqueante que o torna leve e eficiente, ideal para aplicações em tempo real com troca intensa de dados através de dispositivos distribuídos.

Na JSConf 2009 Européia, um programador jovem chamado Ryan Dahl, apresentou um projeto em que estava trabalhando. Este projeto era uma plataforma que combinava a máquina virtual JavaScript V8 da Google e um laço de eventos. O projeto apontava para uma direção diferente das outras plataformas em JavaScript que rodam no servidor: todos I/O primitivos são orientado a evento. Aproveitando o poder e a simplicidade do Javascript, isso tornou tarefas difíceis de escrever aplicações assíncronas em tarefas fáceis. Desde quando foi aplaudido de pé no final do seu discurso, o projeto de Dahl tem recebido uma popularidade e uma aprovação sem precedentes.

Que problema o Node pode resolver?

Node estabeleceu o objetivo número um que é “fornecer uma maneira fácil para construir programas de rede escaláveis”. Qual é o problema com os programas servidores atuais? Vamos fazer os cálculos. Em linguagens como Java™ e PHP, cada conexão cria uma nova thread que potencialmente tem anexado 2 MB de memória com ela. Em um sistema que tenha 8 GB de RAM, isso põe o número máximo teórico de conexões concorrentes a cerca de 4.000 usuários. E quando o número de usuários aumenta, se você quer que sua aplicação web suporte mais usuários, você tem que adicionar mais e mais servidores. Somado a estes custos também podem haver possíveis problemas técnicos: um usuário pode usar diferentes servidores para cada requisição, então cada recurso compartilhado deve ser compartilhado para todos os servidores. Por todas estas rações, o gargalho em toda a arquitetura de aplicações web (incluindo velocidade de tráfego, velocidade do processador e velocidade da memória) é o número de conexões concorrentes que o servidor pode manipular.

Node resolve esta questão trocando a maneira como a conexão é tratada no servidor. Ao invés de criar uma nova OS thread a cada conexão (e alocar a memória anexa a ela), cada conexão dispara um evento executado dentro da engine de processos do Node. Node afirma que nunca vai dar deadlock, já que não há bloqueios permitidos, e ele não bloqueia diretamente para chamadas de I/O. Node também alega que um servidor rodando ele pode suportar dezenas de milhares de conexões simultâneas.

Então, agora que você tem um programa que pode manipular dezenas de milhares de conexões simultâneas, o que você pode realmente fazer com o Node? Seria incrível se você tivesse uma aplicação web que necessitasse desta quantidade de conexões. Este é um daqueles tipos de problema: “se você tem um problema, não é mais um problema”.

O que Node definitivamente não é?

Sim, Node é um servidor de programas. Entretanto o produto base do Node definitivamente não é como o Apache ou o Tomcat. Estes servidores são basicamente servidores ready-to-install e estão prontos para instalar aplicativos instantâneamente. Você pode subir e rodar um servidor em um minuto com estes produtos. Node definitivamente não é isso. Parecido com como o Apache pode adicionar um módulo PHP para permitir desenvolvedores criarem páginas da web dinâmicas, e um módulo SSL para conexões seguras, Node tem o conceito de módulos que podem ser adicionados no núcleo do Node. Há literalmente centenas de módulos para rodarem com o Node, e a comunidade é bastante ativa em produzir, publicar e atualizar dezenas de módulos por dia.

Como o Node funciona

O Node roda em uma JavaScript V8 VM. Mas espere, JavaScript no servidor? Isso, você leu certo. JavaScript no lado do servidor pode ser um conceito novo para todos que trabalharam exclusivamente com o JavaScript no lado do cliente, mas a idéia em sí não é tão absurda – porque não usar a mesma linguagem de programação no cliente que você usa no servidor?

O que é V8? O motor JavaScript V8 é o motor que a Google usa com seu navegador Chrome. Poucas pessoas pensam sobre o que realmente acontece com o JavaScript no lado do cliente. Bem, a engine JavaScript realmente interpreta o código e o executa. Com o V8 a Google criou um ultra-rápido interpretador escrito em C++, com um outro aspecto único: você pode baixar a engine e incorporá-la em qualquer aplicação desejada. Isso não está restrito em rodar em um navegador. Então Node atualmente usa o motor JavaScript V8 escrito pela Google e propõe que seja usado no servidor. Perfeito! Para que criar uma nova linguagem quando há uma boa solução já disponível?

Programação orientada a Evento

Muitos programadores foram ensinados a acreditar que a programação orientada a objetos é um modelo de programação perfeito e a não usarem nada mais. Node utiliza o que é chamado modelo de programação orientada a evento.

Programação orientada a evento no lado do cliente com jQuery:


// jQuery code on the client-side showing how Event-Driven programming works

// When a button is pressed, an Event occurs – deal with it

// directly right here in an anonymous function, where all the

// necessary variables are present and can be referenced directly

$(“#myButton”).click(function(){

     if ($(“#myTextField”).val() != $(this).val())

         alert(“Field must match button text”);

});


O lado do servidor na verdade não é diferente do lado do cliente. Claro que não há botões sendo pressionados e não há campos de texto sendo escritos, mas em um nível mais alto, os eventos estão ocorrendo. Uma conexão é feita – evento! Dado é recebido através da conexão – evento! Data parou de chegar através da conexão – evento!

Por que é que este tipo de configuração é ideal para o Node? JavaScript é uma excelente linguagem para programação orientada a evento, porque ela permite funções anônimas e encerramentos, e o mais importante, a sintaxe é familiar para quase todos que já programaram na vida. As funções de callback que são chamadas quando um evento ocorre podem ser escritas no mesmo lugar onde você captura o evento. Fácil para desenvolver, fácil para manter. Sem frameworks complicados de Orientação a Objeto, sem interfaces, nenhum potencial para o excesso de arquitetura de qualquer coisa. Basta escutar um evento, escrever uma função de callback, e o Node toma conta de tudo.

Artigo retirado de: NodeBR

Anúncios

Otimizações na Web e o carregamento assíncrono

Ao preocupar-se com otimizações Web, o uso de ferramentas como o PageSpeed ou YSlow é muito importante, mas ainda mais crucial é executar testes frequentes e analisar os tempos. A ferramenta WebPageTest, é excelente para esse fim.

Um post aqui do Blog sobre otimização de performance na Web mostrou 7 práticas simples e altamente recomendadas para melhorar sensivelmente a performance de qualquer página Web, como usar GZIP, agrupar e comprimir CSS e JavaScript, colocar CSS no topo e JavaScript embaixo da página, entre outras. Mas há muitas outras práticas interessantes, como o carregamento assíncrono de JavaScript e componentes não essenciais à página.

Carregamento assíncrono de JavaScript

Carregamento assíncrono de JavaScript

Carregamento assíncrono de JavaScript

Colocar arquivos JavaScript no <head> ou espalhado no meio do HTML é má prática há anos. A boa prática é sempre jogar para antes do </body>, uma das regras principais analisadas pelo YSlow. Mas será que jogar o JavaScript para o fim da página é suficiente?

Muitos navegadores não suportam download em paralelo de arquivos JavaScript quando usamos a tag <script>, independentemente da posição em que apareça. E não apenas navegadores antigos como IE6 ou 7; Chrome, Opera, Firefox3 e outros engrossam essa lista. Steve Souders, papa de otimizações Web, sugeriu diversas técnicas em seu livro Even faster Web Sites. Começaram a surgir então ideias e bibliotecas com objetivo de carregar JavaScript em paralelo assincronamente, como LABjsHeadJS e ControlJS, do próprio Steve.

Estou estudando sobre otimização de páginas web portanto, utilizarei o o LABjs, mas independentemente de framework, o importante é carregar assincronamente seus arquivos JavaScript, principalmente se vários arquivos são usados na página. Além do download paralelo, o evento onload dispara mais cedo, executando os callbacks associados a ele e dando uma medida melhor de performance da página.

É preciso tomar cuidado, porém, com a ordem de execução dos scripts caso haja dependências entre eles (muito comum ao usar um framework como JQuery). As ferramentas citadas possuem suporte para manter a ordem de execução. Um outro problema é quando há uso do document.write, algo que é má prática há muito tempo mas infelizmente ainda muito usado.

Usar o LABjs é bastante simples:

// carrega 3 scripts em paralelo mas mantém ordem de execução$LAB.script(‘jquery.js’).wait()    .script(‘plugin.jquery.js’).wait()    .script(‘app.js’); 

// carrega e executa outro script em paralelo, com callback

$LAB.script(‘sem-dependencias.js’).wait(function() {

   alert(‘Callback executando quando script carrega’);

});

O HTML5 especificou um novo atributo async na tag <script> mas poucos browsers suportam. O IE possui um atributo proprietário defer há muito tempo, com propósito parecido. Enquanto não há uma solução padrão e portável, o uso de algum framework de carregamento assíncrono é recomendado.

Adiando o carregamento de conteúdo secundário

Além de JavaScripts assíncronos, é possível melhorar bastante a performance deixando para carregar certos componentes mais tarde, apenas quando necessários. A Caelum tem fotos grandes com chamadas principais rotacionadas. É um efeito muito comum atualmente, mas um grande desafio de performance, já que essas imagens costumam ser grandes e pesadas.

A primeira implementação da Caelum consistia em um HTML simples com tags <img> apontando para cada imagem, um pouco de CSS para mostrar apenas uma imagem por vez e um código JQuery para alternar as imagens com um efeito legal. É uma implementação usada por muitos Sites e plugins do JQuery.

Mas colocar as <img> direto no HTML fazia o navegador carregar todas essas imagens conforme ia lendo o HTML, mesmo que 3 das 4 imagens só fossem aparecer para o usuário muito tempo depois. Era gasto um tempo precioso do carregamento da página, que podia ser usado carregando outros componentes mais essenciais para a renderização inicial, como outras imagens do layout e scripts.

A solução foi carregar assincronamente, via JavaScript, as imagens secundárias, deixando inicialmente apenas a primeira imagem com HTML normal. Usamos os data attributes do HTML5 para criar atributos próprios no HTML que referenciam os endereços das imagens secundárias:

<ul>

<li>

<p>Conheça os cursos de Java da Caelum</p>

<img alt=”Cursos Java” src=”banner_01.jpg” width=”960″ height=”330″ />

</li>

<li data-img-src=”banner_02.jpg”>

<p>Veja os projetos da Caelum</p>

</li>

<li data-img-src=”banner_03.jpg”>

<p>Baixe as apostilas gratuitas</p>

</li>

</ul>

Repare como apenas o primeiro banner possui a <img> direto no HTML. Os demais apenas declaram os caminhos em atributos data- que não são interpretados pelo navegador. Uma função JavaScript pode, então, ler esses valores e gerar as tags <img> de forma assíncrona, depois que a página foi carregada:

$(function() {

setTimeout(function(){

$(‘li[data-img-src]’).each(function(){

var src = $(this).attr(‘data-img-src’);

$(‘<img>’).attr(‘src’, src).appendTo(‘ul’);

});

}, 600);

});

Usando JQuery, selecionamos todos os <li> que possuem o atributo data-img-src. Criamos, então, um novo elemento <img> com o src apontando para o endereço da imagem. Repare que tentamos adiar esse carregamento o máximo possível, já que a segunda imagem só aparecerá para o usuário depois de vários segundos. No código acima, agendamos o script para rodar 600 milissegundos após o carregamento da página.

Observe no gráfico de conexões HTTP ao longo do tempo como o primeiro banner é carregado no início junto com o restante da página e os demais são carregados bem depois:

primeiro banner é carregado no início junto com o restante da página e os demais são carregados bem depois

Uma preocupação possível com essa prática é com usuários com JavaScript desabilitado ou navegadores limitados. É preciso pensar bem nesse caso e oferecer uma boa experiência para o usuário em todas as situações. Mas as imagens rotativas dependem de JavaScript para funcionar; logo, mesmo sem o carregamento assíncrono das imagens secundárias, o efeito não funcionaria e apenas a primeira imagem (em HTML e CSS puros) seria mostrada. Portanto, não há impacto para o usuário em usar a solução JavaScript para carregamento das imagens. Um impacto possível é que os buscadores não enxergam mais as imagens secundárias e, portanto, estas não serão indexadas. Não é um problema no nosso caso, mas pode ser um detalhe importante em outros cenários.

Widgets externos assincronamente

Outro bom exemplo para carregamento assíncrono é dos widgets do Facebook, usados na home de muitos sites e blogs com um Like Button no topo e um Like Box no corpo da página. Onipresentes hoje na Web, esses widgets são importados na página com um <iframe>. O <iframe> tem a vantagem de carregar paralelamente com a página, mas ainda trava o onload da página até que acabe de carregar – e os widgets do Facebook são gigantescos, com mais de 50 requests, 250 KB e 5 segundos para carregar mesmo em navegadores modernos.

Steve Souders mostrou que a tag <iframe> é o elemento mais caro a ser criado no DOM, ordens de magnitude mais lento, mesmo vazio. Mas o principal problema é o onload da nossa página passar a depender do onload do widget, que é grande e lento. Devemos otimizar o tempo que o onload dispara, pois isso dispara os callbacks de onload (bastante comuns) e porque o indicador de carregamento do navegador para de girar após o onload (dando a sensação de rapidez pro usuário).

A melhor estratégia é carregar o <iframe> após o onload via JavaScript, ainda mais se não é algo crítico, como o widget do Facebook. O código é bastante simples:

$(window).load(function(){

$(‘#facebook_like_box’)

.html(‘<iframe src=”https://www.facebook.com/plugin…></iframe>’);

});

Esse carregamento assíncrono do Facebook foi o responsável pela maior parte da otimização final mostrada no vídeo do início do post. Repare no gráfico a seguir como o carregamento todo dos widgets é feito apenas após o onload e, apesar de grande e lento, não afeta a performance do restante da página:

1

Como o widget demora bastante para carregar, o resto da página (já bastante otimizada) aparecerá rapidamente mas o widget bem depois. Para minimizar esse efeito, o header da página da Caelum carrega primeiro um botão like de mentira, com uma imagem simples copiando o visual do widget do Facebook. Quando o widget acaba de carregar, ele é inserido no lugar dessa imagem falsa com precisão, a ponto de ser quase imperceptível para o usuário. Se o usuário clicar na imagem falsa antes do widget carregar, será levado para o Facebook da Caelum; mesmo comportamento se o JavaScript estiver desabilitado. É um truque simples que traz a sensação de alta performance ao carregar a imagem falsa logo, apesar de ser tudo assíncrono e demorado.

 FONTE: Caleum

 

As 7 práticas para um site otimizado

Todo mundo gosta de sites rápidos. Seus primos não sabem dizer se você tem um arquitetura escalável, se seu banco NoSQL é mais robusto ou se é melhor usar Web Services SOAP ou REST. Mas eles sabem dizer duas informações com precisão: se seu site é bonito e se ele é rápido. Performance, medida pelo usuário, é o que te diz se a velocidade de resposta da sua aplicação é aceitável. E, assim como usuários não se cansam de bordas redondas e sombrinhas bonitas, sempre haverá otimizações possíveis para tornar seu site mais rápido.

Inspirado pela recente edição 2010 da Velocity Conference organizada pela O’Reilly. O TOP 7 não pretende ser uma lista completa e nem detalhada de boas práticas. É mais um guia rápido sobre tudo o que você deveria fazer em qualquer site antes de perguntar a opinião dos seus primos – ou do seu chefe, ou de qualquer usuário. Eis então:

As 7 práticas para um site otimizado

TOP 7 das Otimizações na Web:

0. Habilite GZIP em todas as suas páginas. Se você ainda não fez isso, pare imediatamente de ler esse post e faça. É o passo zero, nem vou contá-lo. Dicas de como fazer no TomcatJettyApache,IIS.

1. Agrupe arquivos JavaScript/CSS. 90% do trabalho de otimização consiste em diminuir o número de requests feito na página e o peso de cada um deles. Você usa JQuery (ou qualquer outro framework) com JQuery UI e mais meia dúzia de plugins, sem contar o código JS da sua aplicação? Junte tudo no menor número de arquivos possíveis para evitar muitos requests. Mesma coisa com CSS, um arquivo com tudo basta. Mas gosta de manter as coisas organizadas ao invés de escrever um arquivo com milhares de linhas? Então junte essas coisas dinamicamente como faz o pessoal do Digg ou faça o serviço no build da aplicação.

2. Comprima o JavaScript/CSS. Você escreve JS/CSS elegante, bem documentado, com código organizado e variáveis de nomes legíveis. Mas seus primos não se importa com isso, eles querem um site rápido e isso significa não trafegar no request bytes e mais bytes de documentação ou de código legível. Comprima todo o seu código JavaScript e CSS usando o YUI Compressor ou o Google Closure Compiler. Faça isso em build time ou dinamicamente.

3. Otimize suas imagens com Smush-it. Nem todos os KB de suas imagens são necessários para o cliente. Arquivos JPEG possuem uma série de metadados e PNGs possuem palhetas de cores. Remova vários KBs desnecessários de suas imagens usando o Yahoo Smush-it em todas elas.

4. Coloque CSS no topo e JavaScript embaixo. Simples assim. Referencie os seus CSS no <head> com <link> para evitar o flash effect, e coloque seus scripts logo antes do fechamento do <body> para não atrasar a renderização da tela.

5. Não redimensione imagens no HTML. Não use os atributos width e height das imagens para redimensionar seu tamanho. Sirva as imagens já com tamanho certo e otimizadas. Mas coloque sempre o width e height de todas as imagens para ajudar o browser nos cálculos da renderização da página.

6. Configure o Expires corretamente. Use o cache do navegador para prover uma melhor experiência ao usuário no segundo request – seja no retorno ao site ou navegando para a próxima página. Permita também que Proxies entre seu servidor e o cliente cacheiem elementos do seu site para evitar um download demorado. Configure o header de Expires de todo seu conteúdo estático (JS, CSS, imagens) com alguns dias de duração.

7. Use YSlow e PageSpeed. Depois que você fez todas as otimizações anteriores, instale o YSlow e o PageSpeed para um diagnóstico detalhado de seu site. Monitore sua performance constantemente e vá implementando sempre novas otimizações. Seus usuários agradecem.

Esse TOP 7 são todas as otimizações que você deveria ter feito ontem em qualquer site seu antes de começar a falar em performance. Há muitas outras práticas, algumas mais complicadas, como CSS Spritesusar CDNsotimizar seus cookies, fazer preload e postload de conteúdo, ou comprimir seu HTML. Dependendo da tecnologia que você usa no seu sistema, você terá maior ou menor facilidade de aplicar todas essas práticas: no JSF e ASP.NET você terá benefícios para desenhar sua interface, mas muito mais trabalho de fazer esse ajuste fino; com Struts, Rails, ASP.NET MVC, VRaptor e frameworks action based, será o contrário.

Fonte: Caelum

O que são os padrões Web ?

Padrões Web é um conjunto de normas, diretrizes, recomendações, notas, artigos, tutoriais e afins de caráter técnico, produzidos pelo W3C.

 Padrões Web

É destinado a orientar fabricantes, desenvolvedores e projetistas para o uso de práticas que possibilitem a criação de uma Web acessível a todos.

A Web em padrões:

A Web em padrões

Divisão em Camadas

O correto é fazer divisões em camadas, como mostrado na figura abaixo:

Divisão em CamadasObservação: Trabalhar com Web Standards (a padronização é a criação de uma “Web universal”) não é uma questão de trocar tabelas por div’s e sim uma questão de semântica!