I know jQuery

Muito além do jQuery

Por incrível que pareça eu comecei esse artigo no dia 8 de Agosto de 2013 e ele ficou perdido no limbo do meu Google Drive desde então, faltavam alguns exemplos e uma conclusão. Então, eis que o encontrei ao procurar um outro artigo que estava perdido por lá.

Resolvi finalizar e estou postando com mais de 1 ano de atraso mesmo.


Bom galera já tinha um tempo que eu queria falar sobre esse assunto, mas ainda faltava um incentivo para soltar a boiada. E então eis que aconteceu, dispararam o gatilho. E aconteceu em um grupo de desenvolvimento do facebook, o jQuery Brasil. Um iniciante perguntou quais os requisitos necessários de JavaScript para aprender jQuery e um membro respondeu que não era preciso saber JavaScript para aprender. E na hora eu fiquei indignado, mas pensando bem eu acho que ele está certo, muita gente sabe jQuery e não sabe JavaScript. Mas se o jQuery é uma biblioteca JavaScript, logo, quem sabe jQuery sabe JavaScript, certo?

Em teoria era isso que deveria acontecer, mas as bibliotecas e os frameworks existem para criar uma camada de abstração maior e simplificar o trabalho, então em grande parte das vezes as pessoas não aprendem a linguagem e sim a ferramenta, que pode ser uma biblioteca, um framework, uma sdk, etc.

Então esse artigo é dedicado para o pessoal que sabe jQuery e que provavelmente não sofreu para aprender a trabalhar com o DOM (Document Object Model) ou fazer uma requisição ajax usando o XMLHttpRequest.

Primeiramente eu gostaria de lembrá-los que para tudo que o jQuery faz existe algo equivalente em JavaScript, até por que jQuery é JavaScript (sim, vou falar isso várias vezes). Mas eu não vou começar pelo básico, até por que o básico você encontra facilmente no google. Eu recomendo o ótimo artigo do Tárcio Zemel entitulado “Equivalentes nativos de JavaScript para funções jQuery“, onde o autor mostra algumas dessas equivalências.

Quando usar jQuery?

Uma das inspirações para esse artigo foi o artigo I know jQuery. Now what? do Remy Sharp, onde ele levanta alguns pontos sobre quando não usar jQuery e demonstra algumas soluções de problemas sem a utilização de jQuery. Este artigo é mais simples que o do Remy Sharp por isso recomendo a leitura dele, no entanto, é igualmente opinativo.

Bom, esse artigo já está ficando grande e chato e eu nem comecei a parte técnica ainda, então chega de enrolação.

Quando a complexibilidade supera a facilidade

Quando uma grande parte do seu público alvo não utiliza navegadores de última geração fica complicado trabalhar com JavaScript puro já que algumas funções do JavaScript podem não ser compatíveis por terem sido implementadas depois. O pessoal da BBC, no artigo Cutting the mustard, divide os navegadores em dois grandes grupos (Navegadores HTML5 e Navegadores HTML4) para poder exibir uma interface mais rica ao usuário dependendo dos recursos suportados pelo navegador do mesmo.

Por padrão o IE8 não suporta o método addEventListener que é um método que fica “escutando” um evento e é executado quando o evento do objeto é acionado. Está presente em todos os navegadores lançados desde 2007, menos no IE8. E isso, teoricamente, implica que se o navegador do cliente suportar esse recurso então esse navegador possui um melhor suporte aos padrões que o IE8.

Logo, se o seu público alvo utiliza esse navegador você deve utilizar jQuery. O que não quer dizer que todos os projetos que não utilizem jQuery ou outras bibliotecas não irão funcionar no IE8 e sim que você deve começar o projeto de forma simples e sem gambiarras.

Quando é necessário agilidade

Isso é uma das principais causas pelo qual os desenvolvedores utilizam bibliotecas e frameworks, agilizar o desenvolvimento. E o jQuery faz isso muito bem. Então não precisamos ficar reinventando a roda.

Como sobreviver sem jQuery?

Desenvolver sem o jQuery pode soar para alguns como reinventar a roda. Mas existem algumas alternativas para se escrever a aplicação sem ele e sem perder tempo.

document.ready

O document.ready, ou simplesmente $(function), é utilizado para executar o JavaScript após o navegador ter compilado o DOM. Fazemos isso pois o JavaScript bloqueia a renderização, mas como estamos falando de alternativas que tal colocar o seu código JavaScript antes da tag ? Dessa forma o DOM já estará compilado.

Caso essa simples ação ainda não resolva o seu problema, o que eu duvido muito, você ainda poderá utilizar o DOMContentLoaded. O DOMContentLoaded é suportado pela maioria dos navegadores.

document.addEventListener("DOMContentLoaded", function(event) {
  //do work
});

querySelectorAll

Anos atrás, quando o jQuery surgiu, ele trouxe uma revolução ao modo de utilizar JavaScript pelo simples fato dele ter simplificado, de forma significativa, a tarefa de selecionar os elementos com os quais queremos trabalhar. Porém o JavaScript evoluiu e hoje nós temos uma maneira igualmente fácil e nativa. É o querySelectorAll que é usado da seguinte forma:

var matches=document.querySelectorAll("div.nota, div.alerta");

Classes

Frequentemente costumamos trabalhar com classes no JavaScript, tanto para selecionar um elemento, quanto para fazer gets e sets do atributoclass em elementos. Normalmente acabamos usando o jQuery. Mas que tal usar as propriedades className e classList?

Formulários

Antigamente para fazer a validação de formulários no navegador nós sempre utilizávamos JavaScript, não existia outra opção. Porém o HTML também evoluiu e atualmente é possível fazer validação de formulários utilizando apenas atributos nos elementos HTML. É possível validar emails com o input do tipo email, definir campos obrigatórios com o atributo required e fazer validações com expressões regulares com o atributo pattern, nos permitindo assim, validar telefones, CPFs, CNPJs, etc.

Animações

O CSS também evoluiu e hoje podemos fazer animações com ele através da propriedade animate, como visto nesse artigo da MDN, e até mesmo utilizar aceleração hardware utilizando o translate3d da propriedade transform como visto nesse artigo do Paul Irish. 
Eu, particularmente, uso bastante essas duas características do CSS3 para deixar as animações nos dispositivos móveis mais fluídas.

Conclusão

Hoje é possível ser produtivo sem utilizar jQuery que embora seja muito prático muitas vezes não é necessário, pois muitas vezes carregamos uma biblioteca inteira para utilizar apenas alguns métodos que já possuem APIs nativas disponíves no JavaScript ou alternativas melhores, mais simples e mais performáticas no HTML e no CSS.

Então sempre que o jQuery não for necessário, evite-o ;)

jQuery Boilerplate

Melhores da semana 2

A segunda edição dos melhores da semana aparece numa sexta feira pré dia dos pais e traz, entre outros, o Emmet LiveStyle, o MEAN e o novo layout do site do jQuery Boilerplate.

 

Emmet Live Style

emmet

Uma nova maneira de editar o seu CSS.

Eu ia postar o site do projeto, mas acredito que o artigo do Diego Eis será mais elucidatório e quem quiser ir mais a fundo é só ir no site do projeto, que também está no artigo do Diego.

http://tableless.com.br/emmet-livestyle/

 

Design para telas sensíveis ao toque

Artigo do Dani Guerrato que levanta alguns pontos interessantes sobre essa nova era das telas sensíveis ao toque.

http://tableless.com.br/design-para-telas-sensiveis-ao-toque/

 

An overview of the regular expression API

Uma visão geral da API de expressões regulares do JavaScript.

http://www.2ality.com/2011/04/javascript-overview-of-regular.html

 

jQuery Boilerplate

jQuery Boilerplate

Projeto para facilitar o pontapé inicial no desenvolvimento de plugins jQuery. Esse foi o primeiro projeto open source do Zeno Rocha e agora ganhou uma cara nova.

http://jqueryboilerplate.com/

 

MEAN (Mongo, Express, Angular, Node)

Um ponto de partida simples, escalável e fácil para aplicações centradas em JavaScript.

http://mean.io/

 

MockUPhone

Repositório de MockUps de dispositivos móveis.

http://mockuphone.com/

 

A Responsive Web Design Process

Nesse artigo o autor, Tristan L'Abbé, tentou juntar grande parte do conhecimento compartilhado na web sobre Design Responsivo e então ele decidiu propor um processo para o desenvolvimento de um design responsivo para a web.

http://heliom.ca/blog/posts/a-responsive-web-design-process

 

A guide to using Github Pages

GitHub logo

Aprensa a usar o GitHub Pages.

http://www.thinkful.com/learn/a-guide-to-using-github-pages/

 

Tablet Usability

Artigo que aborda a Usabilidade nos Tablets. Complementar ao artigo da Dani Guerrato no Tableless.

http://www.nngroup.com/articles/tablet-usability/

Senha

Balanceando segurança e experiência do usuário

Oi, eu sou o Jean e antes de começar esse primeiro post do blog eu me sinto no dever de fazer uma breve apresentaçao.
 

Bom, eu sou graduando de Sistemas de Informação na UFG e trabalho no LabTIME/UFG e na Monodois Comunicação, além de ter vários projetos pessoais que, assim como muitos dos projetos por aí, estão demoram a sair do papel.

 

E a ideia de criar um blog partiu de uma conversa minha com o Márcio Sena, que também trabalha comigo no LabTIME/UFG e irá se apresentar por aqui futuramente, e a idéia basicamente é compartilhar nosso conhecimento e nos ajudar a buscar mais conhecimento.

 

A partir daí eu convidei mais dois colaboradores, o Diogo César e o Clóves Cardoso, que se também se apresentarão futuramente, e a partir daí decidimos auxiliar a disseminar as tecnologias frontend e um pouco de UX para a comunidade.

 

E é isso, espero que gostem.

 


Ajudando a atrapalhar o usuário

 

Eu não sou o único a sofrer quando digito uma senha e o único feedback recebido são um monte de bolinhas. Muitos usuários sofrem do mesmo mal e é normal, afinal nem sempre temos a certeza de termos digitado a senha corretamente. E o problema tende a piorar nos famosos "Digite sua senha novamente".

 

De modo geral o ato de mascarar as senhas é uma convenção de segurança definida anos atrás e que foi criada para evitar que "bisbilhoteiros" roubassem as senhas dos usuários mais descuidados. E embora seja uma boa prática de segurança pode comprometer a experiência do usuário, principalmente nos dispositivos móveis, onde a digitação é comprometida pela falta de espaço entre os caracteres do teclado.

 

Quando mascaramos as senhas nós criamos, basicamente, dois problemas:

 

  • Os usuários cometem mais erros, pois eles não conseguem ver o que estão digitando e, por isso, se tornam menos confiantes. Tornando-se mais propensos a desistirem da ação.

  • A incerteza que o usuário sente com relação ao que foi digitado faz com que o usuário busque formas alternativas de "burlar" o sistema, como empregar senhas excessivamente simples e/ou copiar senhas de arquivos em seus computadores. Ambas as condutas levam a uma perda real de segurança.

 

No entanto, deixar as senhas sem máscaras podem oferecer um risco real aos usuários, pois sempre há a possibilidade deles estarem sendo espionados por um "bisbilhoteiro". Principalmente nos formulários de login, pois essa é uma ação que se repete várias vezes, ao contrário dos formulários de cadastro. No caso dos formulários de cadastro mascarar as senhas podem criar mais problemas ao usuário do que realmente valem a pena. A segurança proporcionada pelas máscaras nesse caso muitas vezes é inútil, já que normalmente as pessoas não se cadastram em sites com outras pessoas bisbilhotando.


 

Solução

 

Uma solução plausível é o desmascaramento de senhas que pode ser realizado quando o campo do formulário estiver em foco ou quando um checkbox estiver marcado por exemplo. Isso fica a critério do desenvolvedor.

 

Cases

 

Recentemente o Windows 8 foi lançado e junto com ele o Internet Explorer 10 e ambos possuem um recurso de desmascaramento de senhas quando se mantém pressionado um signo (botão), como podem ver abaixo.

Alguns aplicativos para dispositivos móveis já implementaram o mesmo recurso. É o caso do Polar e do LinkedIn como se pode ver nas imagens abaixo.




 

Extra: hideShowPassword Plugin

 

O pessoal do Cloud Four concorda comigo e como não conseguiram encontrar nenhum plugin javascript que realizasse o desmascaramento de forma otimizada para dispositivos touchscreen então eles criaram um.

 

hideShowPassoword no Github

Demo

O hideShowPassword necessita do jQuery ou do Zepto.js e funciona de forma muito fácil e tudo o que você precisa fazer é alterar a visibilidade do campo de senha através dos métodos:
 

$('#password').showPassword();     // Exibir

$('#password').hidePassword();     // Esconder

$('#password').togglePassword();     // Alternar

 


Conclusão

 

Seguir as convenções de design é geralmente o aconselhável, mas quando essas convenções começam a dificultar a vida dos usuários então elas precisam ser repensadas. A segurança deve ser equilibrada com a experiência do usuário. E ao meu ver mascarar as senhas é uma convenção errada e eu sou a favor de desmascarar as senhas temporariamente a fim de otimizar a experiência do usuário, tendo em vista que isso não prejudica consideravelmente a segurança.


Referências

Stop Password Masking
Better Password Masking For Sign-Up Forms
Hide/Show Passwords: The Missing Plugin