Front-end

Devo começar como Front-End, Back-End ou Full Stack?

Olá, Web Developers!

Muitos programadores no começo de suas carreiras acabam encontrando os termos Front-End, Back-End e Full Stack quando vão se candidatar a vagas de emprego. Então surgem as seguintes dúvidas: “o que devo seguir?”, “qual a mais difícil e qual a mais fácil?”, “qual paga melhor?”, etc.

Todos possuem vantagens e desvantagens. Vamos ver os pontos base sobre cada um.

Front-End

Desenvolvimento Front-End

Necessidades

O desenvolvedor Front-End terá que desenvolver as telas da aplicação que foram projetadas pelo Arquiteto e Designer, normalmente com HTML, CSS e JavaScript.

Este desenvolvedor também terá que saber analisar o trabalho do designer para poder seguir o que ele projetou, portanto também pode ser necessário saber o básico de softwares como PhotoShop, Illustrator, Adobe XD e Sketch.

Você não precisa saber sobre experiência de usuário e design, mas há empresas em que o próprio desenvolvedor Front-End precisa desempenhar os papéis de arquiteto e designer, tornando esses conhecimentos um diferencial deste profissional.

Há empresas que também vão querer um desenvolvedor Front-End para criar um site/blog feito com WordPress, então também pode ser interessante saber um pouco de PHP.

Desvantagens

O código feito por um Front-End é executado no cliente. Porém, não sabemos se o usuário está em um smartphone, tablet, notebook ou desktop. Será que o usuário está usando um bom Wi-Fi ou está com uma Internet móvel bem lenta?

Também não sabemos o sistema operacional, qual navegador, versão, etc. Um desenvolvedor Front-End precisa desenvolver um código que possibilite que a maioria dos usuários possam utilizar a aplicação sem problemas. Portanto, é necessário muitos testes em diversos ambientes.

Como estará em contato direto com o usuário, deverá entregar uma boa experiência, e isso se inicia no tempo de carregamento da aplicação. Portanto, também é preciso se preocupar com a otimização dos arquivos HTML, CSS, JS, imagens, etc.

Vantagens

Um Front-End tem como principal linguagem de programação o JavaScript, que está crescendo muito. Você pode ver mais no post O que se pode fazer com JavaScript hoje em dia?.

Além da web, este profissional pode aprender facilmente a criar aplicações desktop e mobile, desenvolver jogos e começar a trabalhar com Back-End utilizando apenas JavaScript.

Ele também não precisa se preocupar com performance do processamento feito no servidor e nem com o Banco de Dados.

Todas as empresas precisam de um Front-End, permitindo que você envie currículo para qualquer empresa.

Outro ponto é que o resultado do seu trabalho pode ser visto em ação (sistemas, aplicativos, sites, etc), permitindo deixar o seu currículo mais interessante.

Como normalmente as regras de negócio ficam no servidor, o Front-End pode ser um pouco mais amigável para quem não tem tanta lógica de programação (isso não significa que lógica é dispensável).

Hoje em dia as empresas estão valorizando cada vez mais o JavaScript, fazendo a demanda e o salário oferecido aumentarem, já que ainda há poucos Front-Ends de qualidade se comparar com a quantidade de desenvolvedores Back-End.

Back-End

Desenvolvimento Back-End

Necessidades

O desenvolvedor Back-End é aquele que responderá às requisições do cliente. Ele precisa saber alguma linguagem de programação, ter uma boa lógica para programar as regras de negócio do sistema, se conectar ao banco de dados para recuperar ou gravar dados, etc.

O banco de dados pode ser de responsabilidade de um profissional especializado, mas muitas vezes ele fica por conta do próprio desenvolvedor Back-End, fazendo da otimização de banco de dados algo interessante de se saber. Independente disso, o Back-End precisa saber mexer com banco de dados.

Além disso, este desenvolvedor também precisará saber publicar a aplicação, podendo ser necessário conhecimento em serviços como AWS ou Azure e a criação de contêineres como o Docker.
Para saber mais sobre o que é Docker, veja nosso post: No final das contas: o que é o Docker e como ele funciona?

Hoje em dia, dependendo do sistema, pode ser necessário que este profissional saiba lidar com Internet das Coisas (IoT), Aprendizado de Máquina (Machine Learning), Mineração de Dados (Data Mining), etc. Algumas destas habilidades será um grande diferencial deste profissional.

Desvantagens

Normalmente desenvolvedores Back-End tem mais familiaridade apenas com uma linguagem de programação, o que ilmita os lugares para onde podem enviar currículos. Então entra a questão: “devo estudar outra linguagem ou me especializar no que já sei?”

Se um Front-End pode enviar currículo para qualquer lugar, um desenvolvedor Back-End especializado em Java dificilmente será chamado por uma empresa que só trabalhar com Python, por exemplo.

Como lidam diretamente com a regra de negócio, precisam ser os mais atentos a cada detalhe, inclusive os dados enviados pelo Front-End, pois o cliente pode dar um jeito de burlar as regras do Front.

Devem estar atentos a vários casos de teste e lidar com a segurança do servidor para evitar ataques aos dados. Um pequeno problema aos dados e toda a empresa pode ter sérios problemas. Front e Back precisam estar atentos, mas erros no servidor podem ser muito mais graves.

Outro ponto é que a velocidade do Front-End muitas vezes vai depender das respostas do servidor, então também devem saber otimizar o banco e o código. Todos os usuários estarão acessando o seu servidor, então é preciso saber como escalar a sua aplicação para que ela não caia em um momento de grande quantidade de acessos.

Vantagens

O Back-End não precisa se preocupar com o dispositivo ou versão do navegador do cliente, pois seu código estará rodando em apenas uma única máquina a qual você mesmo pode configurar.

Um Front-End precisa saber logo de início HTML, CSS, JavaScript, deixar as telas funcionando em todos os tamanhos de dispositivos, etc, enquanto o Back-End precisará de uma linguagem de programação e um banco de dados, podendo o Back-End ser um pouco mais amigável para alguns iniciantes, principalmente os que tem boa lógica de programação e/ou aqueles que não se dão muito bem com as partes mais visuais de um sistema.

Além disso, hoje em dia ainda é muito comum que empresas paguem salários maiores para desenvolvedores Back-End, principalmente por sua alta responsabilidade com os dados da aplicação.

Full Stack

Pessoa Trabalhando

Necessidades

O NINJA! O Full Stack é o desenvolvedor que faz tanto Front quanto Back. Então tudo o que foi dito aqui são necessidades para que alguém seja considerado um verdadeiro Full Stack.

Mas deve-se tomar cuidado! Há desenvolvedores Back-End que só por saberem se virar com JavaScript e um pouco de CSS se consideram Full Stack (precisa mais que isso para ser Front), do mesmo jeito que muitos Front-Ends, por saberem como fazer uma API e salvar algo no Banco de Dados (precisa mais que isso para ser back), já se consideram Full Stack também.

Um verdadeiro Full Stack deve estar bem familiarizado com ambos os lados. Por esses motivos, muitos acreditam que um verdadeiro Full Stack é algo que não existe, como um ser mitológico. Porém, isto não te impede de ser Full Stack.

Há empresas que apenas esperam que uma mesma pessoa pegue dados do banco e exiba em uma tela, e depois pegue os dados da tela e salve no banco. Conseguir fazer o fluxo completo com qualidade já pode qualificar este profissional como Full Stack, mas é preciso se dedicar muito para fazer tudo isso com qualidade.

Você pode aprender mais sobre isso com o nosso curso MEAN 2 – JavaScript FullStack

Desvantagens

As tecnologias estão sempre evoluindo, e é muito difícil se manter atualizado em várias coisas ao mesmo tempo, o que seria o ideal para quem quer se manter como Front e Back ao mesmo tempo.

Não confunda Full Stack (sabe bem Front e Back) com um generalista (sabe um pouco de tudo).

Vantagens

Possibilidade de enviar currículos para mais lugares e poder encontrar empresas que ofereçam salários maiores. Além disso, pode se oferecer para trabalhar apenas como Back ou apenas como Front.

Conclusão

Cada caminho possui vantagens e desvantagens. O melhor é analisar sua realidade, necessidade e objetivos para fazer a melhor escolha. E não se preocupe em ter que escolher certo de primeira, pois se não gostar da sua escoha sempre haverá tempo de recomeçar com algo diferente.

Confira também nosso Post sobre Ser especialista em algo ou saber um pouco de tudo?

TW Entrevista 12: Loiane Groner

Hoje trazemos para vocês uma entrevista com a Loiane Groner, que já escreveu diversos livros publicados internacionalmente e possui os títulos GDE (Google Developer Expert) e Microsoft MVP (Most Valuable Professional).

Se você ainda não viu, o Diego Eis foi o último entrevistado por nós.

Fale um pouco sobre você (de onde é, onde mora, o que faz, onde trabalha atualmente, etc)

Me chamo Loiane, trabalho há 10+ anos na área de TI como desenvolvedora, formada em Ciência da Computação, natural do Espírito Santo, porém nos últimos 9 anos morei em São Paulo (2 anos em Campinas e 7 na capital). Trabalho atualmente no Citibank como desenvolvedora e analista de negócios, e recentemente me mudei para os Estados Unidos.

Tenho um canal no Youtube onde publico tutoriais e cursos sobre desenvolvimento, já publiquei alguns livros em inglês pela Packt (editora Novatec traduziu o último livro lançado para o português) e já tive a oportunidade de palestrar em eventos no Brasil e EUA.

Quando e como você começou a se interessar pela área?

Essa parte é engraçada porque tudo foi uma decisão de qual curso fazer vestibular. Quando era adolescente sempre quis ser advogada/juíza, e perto do vestibular decidi fazer Ciência da Computação por gostar mais de responder perguntas e estudar a parte de exatas pro vestibular.

A decisão pelo curso de computação foi simplesmente por sempre ter sido curiosa por computadores (meu primeiro computador vivia no conserto por tentar comandos na linha de terminal, vivia estragando o sistema operacional por conta disso).

Naquela época pouco se falava sobre cursos de exatas e as informações não eram tão fáceis assim como hoje, onde temos quase tudo disponível na internet. Entrei na faculdade sem saber o que era algoritmos, custei a entender lógica de programação no primeiro semestre, mas depois me apaixonei e hoje não me arrependo da decisão.

Como foi seu primeiro trabalho na área?

Arrumei o primeiro trabalho/estágio ainda na faculdade, quando estava no segundo ano (quarto semestre). A faculdade tinha (até hoje tem) parceria com empresas e uma delas precisava de dois estagiários. Me inscrevi junto com um amigo e a coordenação do curso nos ajudou a conseguir as vagas.

Sabia apenas o básico do básico de Java (controles de fluxo e o básico de Orientação à Objetos). No estágio deram um treinamento pra gente de XML, SQL, controle de versão, web services e outros conceitos básicos.

Depois foram passando tarefas de desenvolvimento básicas e à medida que ia aprendendo, iam passando tarefas mais complexas. Trabalhei 2 anos nessa empresa. Me sinto muito sortuda pois tive dois mentores excelentes, que foram pacientes e me ensinaram muito. Trabalhei com Java backend, um projeto Java desktop (Swing), projetos Java web (com JSON e Ajax, que na época era super novidade, onde foi meu primeiro contanto com web também), relatórios, SQL e até um projeto .NET.

Como é a experiência como escritora? Ainda mais de livros que são distribuídos internacionalmente. Tem algum conselho para quem quer começar a escrever?

Comecei em 2009, quando publiquei meu primeiro post no blog loiane.com. Criei o blog para mim mesma, uma espécie de documentação e notas para que eu pudesse usar depois como referência e documentar o que estava escrevendo.

Depois que comecei a trabalhar numa multinacional e comecei a usar inglês no dia a dia, senti a necessidade de praticar mais a parte escrita, e como forma de praticar, criei um blog em inglês também. Escrevia os posts (tutoriais) em inglês e depois reescrevia o mesmo em português.

Depois de alguns anos, o blog começou a ganhar mais visibilidade e a editora entrou em contato com o convite para escrever um livro. Nunca imaginei que fosse ter tal oportunidade. A editora gostou da didática e depois foi convidando para escrever outros títulos também. Já convidaram até por conta de um repositório de exemplos no github.

Não tenho palavras para descrever o sentimento de ver uma pessoa lendo um livro seu e ver que aprendeu algo lendo o que você escreveu. É muito gratificante ver pessoas de diferentes partes do mundo consumindo seu conteúdo. Tenho guardado algumas teses de mestrado de universidades européias e canadenses que usaram algum livro meu como referência – isso não tem preço pra mim.

Os livros também foram incentivo para criar o canal no youtube. Como foram escritos em inglês, começaram a me puxar a orelha por não ter criado conteúdo em português, e aí decidi começar a fazer vídeos dos assuntos em português. É legal que são duas experiências bem diferentes: criar conteúdo escrito e em vídeo.

Algumas dicas:

  • Comece escrevendo para você mesmo. Hoje em dia existem diversas ferramentas que você não precisa se preocupar com domínio, hospedagem, etc. Publique algum tutorial ou algo que seja útil para você e depois compartilhe nas redes sociais (se te ajudou, pode ser que ajude outras pessoas também). Com o tempo você toma gosto e não consegue parar! rs
  • Algumas editoras pedem para ver conteúdo escrito já publicado (blog, etc) para ter uma noção do estilo de escrita, então a primeira dica é bem valiosa! rs
  • Você não precisa ser “O” expert no assunto para escrever. A motivação é sempre por compartilhar conhecimento. Até porque a gente aprende muito sobre o assunto enquanto escreve.
  • O público gosta muito de exemplos práticos. Mas é sempre bom colocar um pouco de teoria também, pois teoria é sempre a base e vai te ajudar a dar mais fundamento também.

Você é GDE (Google Developer Expert) e Microsoft MVP (Most Valuable Professional). Como conseguir esses títulos, quais as responsabilidades para mantê-los e que dicas dá para quem quer consegui-los?

Esses títulos são títulos de reconhecimento dados pelas respectivas empresas/comunidades a membros das comunidades que compartilham conteúdo sobre produtos dessas empresas.
Geralmente são pessoas ativas na comunidade que compartilham posts de blog, cursos, publicam livros, apresentam palestras em eventos, contribuem em projetos open-source, etc. A responsabilidade é continuar fazendo o que já vinha fazendo antes de receber o título, ou seja, compartilhar conhecimento porque gosta de fazê-lo!

Não tem uma receita de bolo para conseguir o título. Geralmente a pessoa já é um GDE ou MVP mesmo sem o título. Acaba vindo naturalmente. Esse post é bem legal sobre o assunto e pode ser aplicado a outros títulos também:

https://medium.com/@frosty/preparing-to-become-a-gde-752b551c88df.

Participar de comunidades é muito gratificante. É uma forma de aprender junto. Cada um compartilha o pouco que sabe e você aprende com outras pessoas que também estão compartilhando o que aprenderam. Além disso, participar de comunidades é uma ótima maneira de aumentar o networking. Já conheci várias pessoas em eventos, tive oportunidade de conhecer pessoalmente pessoas que apenas conversava pela internet e fiz amizades!

Quando estuda algo novo, qual a sua maior dificuldade e o que faz para contornar?

Sempre tento consumir diferentes tipos de conteúdo. Se for um framework novo por exemplo, primeiro acesso a documentação, e sigo os tutoriais. Gosto muito de ler livros também, pois fornecem uma base teórica muito boa.

Pra mim é importante saber usar uma ferramenta/framework, mas é importante saber como funciona também – e a base teórica vai me fornecer isso – saber como funciona ajuda muito nos casos complexos, e vai te ajudar a se diferenciar de outros profissionais também.

E cursos online: sempre tem algo ou um ponto de vista diferente que um instrutor pode te ensinar. Dificilmente consumo um curso ou leio um livro e saio sem aprender nada – mesmo achando que já saiba a tecnologia. Sou assinante de 2 portais de cursos e na empresa que trabalho também tem um grande portal de cursos liberado para os funcionários. E se for uma dúvida pontual, posts de blogs ajudam muito, principalmente com exemplos práticos também!

Resumo: estudar com diferentes formas de conteúdo sempre ajuda. Mas é importante saber o que funciona para você, pois cada um tem uma forma que aprender mais fácil.

Se pudesse falar com você mesma no começo de sua carreira, o que gostaria de falar? Teria algum conselho? Algum medo que gostaria de ter encarado ou alguma situação que poderia ter evitado?

Todos nós temos medo de algo, medo de tentar por achar não ser bom o suficiente ou achar que não tem mais idade pra isso (ou é muito novo). Não deixe de tentar por medo ou insegurança. O “não” você já tem.

E tenha paciência. Muita paciência. Algumas coisas na vida demoram, mas não perca o foco ou determinação. E as coisas acontecem para diferentes pessoas em diferentes momentos. Você vai ouvir muitos “nãos”, mas não deixe que isso te impeça de fazer algo ou de tentar novamente.

O que você considera que caracteriza um desenvolvedor raiz e um desenvolvedor Nutella?

Já vi alguns memes sobre o assunto. Mas acredito que todos nós nos dias de hoje somos uma versão híbrida. Hoje temos muitas ferramentas ao nosso dispor para solucionar problemas de forma mais fácil e rápida. Independente de título (programador, desenvolvedor, software engineer, etc), nosso trabalho é resolver problemas usando tecnologia, de forma a entregar a melhor solução para o cliente.

Como já disse anteriormente, aprenda a base, a teoria. Sim, é chato, é demorado, ir direto pra prática é muito mais legal. Mas depois tudo se torna mais fácil. Seja primeiro um dev raiz, para que você possa se tornar um dev nutella mais tranquilo e mais produtivo!

Como você explica a sua profissão para as pessoas que não são de TI?

Essa parte é sempre complicada. Geralmente falo que desenvolvo sistemas, que é basicamente falar para o computador o que precisa ser feito, uma sequência de passos, como uma receita de bolo. E existe uma forma especial de passar essa receita para o computador, que é através de uma língua que nós (humanos) podemos aprender que o computador também entende.

Escrevendo essa receita nessa língua, o computador entende o que precisa fazer e consegue executar os passos muito mais rápido que nós.

Fique Ligado!

Para seguir a Loiane Groner:

clipboard.js – Copiar e Colar com JavaScript

Olá, Web Developers!

Há momentos em que precisamos permitir que o usuário copie algo para a sua área de transferência (clipboard). Porém, isso pode ser complicado em alguns momentos, seja por APIs antigas ou implementação específica de algum navegador.

Um modo que era bastante usado tratava-se de criar um elemento em flash escondido na página. Isso permitia enviar os dados para a área de transferência do usuário, mas flash não é uma opção hoje em dia e alguns navegadores até o deixa desabilitado por padrão, como é o caso do Chrome.

Para facilitar essa tarefa de modo simples e com um código bem leve (3kb) veio ao mundo o clipboard.js. Ele usa a Clipboard API do HTML5 e foi criado pelo brasileiro Zeno Rocha.

Instalação

Você pode baixar o clipboard.js com o seguinte comando:

npm install clipboard --save

Ou faça download do arquivo js pelo site https://clipboardjs.com/.

Após incluir a biblioteca à sua página, instancie passando um seletor DOM, elemento HTML ou lista de elementos HTML.

new Clipboard('.btn');

Como usar?

Fazer a ação de um elemento copiar o conteúdo de outro elemento é um caso de uso bastante comum.

Na imagem abaixo temos um exemplo: um botão que faz com que o conteúdo de um input seja copiado.

Input com Copy to Clipboard

Para fazer isso funcionar, teríamos um HTML assim:

<!-- Target -->
<input id="input1" value="https://treinaweb.com.br">

<!-- Trigger -->
<button class="btn" data-clipboard-target="#input1">
    <img src="assets/clippy.svg" alt="Copy to clipboard">
</button>

Quando iniciamos a biblioteca, passamos a classe .btn. Isso fará com que as funções da biblioteca entrem em ação sempre que clicarmos em um elemento com a classe “btn”.

Veja que no nosso HTML temos um botão com essa classe. Mas como indicar para a biblioteca qual elemento possui o conteúdo que esse botão deve pegar e enviar para a área de transferência? Para isso a biblioteca usa atributos. Veja que no botão indicamos com o atributo data-clipboard-target o ID do nosso input.

Dessa maneira podemos ter vários botões com a classe “.btn”, e eles serão responsáveis por disparar a ação da biblioteca. Em cada botão a gente pode passar o id de um input. Veja que após iniciar a biblioteca a gente não precisou de mais nenhuma linha de JavaScript!

O comportamento padrão é o de copiar o texto. Caso você passe para o botão o atributo data-clipboar-action com o valor "cut", a ação de recortar será executada.

Também há a possibilidade de se ouvir eventos a partir do objeto clipboard que instanciamos lá no começo, além de outras funcionalidades mais avançadas.

Suporte

O clipboard.js funciona nos seguintes navegadores:

  • Chrome (42+)
  • Edge (12+)
  • Firefox (41+)
  • IE (9+)
  • Opera (29+)
  • Safari (10+)

Até a próxima!

Novidades do Chrome 63 para os desenvolvedores

Olá, Web Developers!

Veremos algumas novidades do Chrome 63, última versão do navegador a ser lançada em 2017.

Importação de módulos JavaScript dinâmicamente

Já faz um tempo que o JavaScript possui um modo nativo de importação de módulos, mas não faz tanto tempo que os navegadores começaram a dar suporte a essa funcionalidade.

O problema é que até pouco tempo, essa habilidade era estática.

Agora, com as mudanças no Chrome 63, podemos importar módulos em tempo de execução baseados em condições. Isso significa que, caso o usuário não precise do módulo, podemos evitar o seu carregamento.

button.addEventListener('click', event => {
  import('./dialogBox.js')
  .then(dialogBox => {
    dialogBox.open();
  })
  .catch(error => {
    /* Error handling */
  });
});

No exemplo acima, o módulo só será carregado caso o usuário clique em um botão. Isso facilita aplicar a estratégia de Lazy Loading, melhorando a performance do carregamento da sua aplicação. Apenas o necessário será carregado no início e o resto será chamado apenas se for preciso.

Sobrescrita do comportamento do overflow scroll com CSS

Em dispositivos móveis podemos usar o scroll para recarregar a página, como mostrado na imagem abaixo:

Recarregamento Mobile

Mas esta funcionalidade faz a página inteira ser recarregada, o que muitas vezes não é necessário. Agora é possível sobreescrever esse comportamento para criar uma funcionalidade igual a de certos aplicativos, onde fazemos o scroll apenas para carregar mais conteúdo (ou atualizar apenas uma parte da página). É o que a PWA (Progressive Web App) do Twitter está fazendo atualmente. Ao invés de recarregar a página, ele adiciona novos tweets à página.

Para isso nós usamos a propriedade CSS overscroll-behavior.

Na imagem abaixo, evitamos o recarrgamento total da página para implementar nosso próprio reload. Neste exemplo, ao invés de recarregar toda a página, apenas atualizaríamos a lista de emails.

Recarregamento Mobile Customizado

Mudança na interface de permissões

Mais de 90% de todas as requisições de permissões são ignoradas ou temporariamente bloqueadas.

É muito ruim para a experiência do usuário quando um site já pede permissões de notificação assim que você entra, sem contexto nenhum. Para diminuir isso, o Chrome 59 começou a bloquear temporariamente uma permissão caso o usuário a negasse três vezes.

Agora o Chrome 63 para Android fará requisições em modais. Isso chamará mais a atenção do usuário, mas eles já aconselham para que os desenvolvedores exibam as requisições apenas em momentos que fazem sentido. Acredita-se que assim os usuários estarão 2,5x mais dispostos a aceitar uma permissão.

Device Memory API

A nova API JavaScript Device Memory nos ajuda a entender melhor o que está limitando a performance da sua página dando dicas sobre o total de memória RAM disponível no dispositivo do usuário.

Com isso, podemos adaptar algumas funcionalidades em tempo de execução para melhorar a experiência do usuário, assim como o YouTube altera a qualidade dos vídeos dependendo da velocidade da sua conexão.

Intl.PluralRules API

Essa API nos permite criar aplicações que entendem como aplicar regras de plural das palavras em diversas línguas dependendo do número aplicado. Essa API também pode ajudar com números ordinais.

Devo transformar meu site em uma PWA?

Olá, Web Developers!

Vocês sabem o que são PWA’s? Será que vale a pena transformar uma página web em uma PWA?

O que são PWA’s?

PWA vem de “Progressive Web App” e a ideia é juntar o melhor dos aplicativos nativos e tecnologias web. É importante notar que não estamos falando de aplicativos híbridos.

PWA’s são aplicações web comuns, então só precisamos de HTML, CSS e JavaScript. Porém, possuem características que fazem o usuário se sentir em um aplicativo nativo.

Aqui as características que definem uma PWA:

1. São progressivas

Elas vão funcionar em qualquer contexto, não importando o dispositivo ou navegador. Deve-se verificar se alguma funcionalidade que você vai usar encontra-se disponível no navegador do seu usuário. Se não, proporcionar algum comportamento para que a página não quebre e passe uma má experiência.

2. São responsivas

A interface e funcionalidades se adequam a qualquer tamanho de tela, desde um pequeno smartphone até uma grande Smart TV.

3. Não precisam de conexão

Nós projetamos essas aplicações para poderem funcionar mesmo quando o usuário não estiver conectado, usando o Cache para servir os arquivos e o Storage do navegador para armazenar dados.

4. Parecem aplicativos

Criamos a interface e as interações de modo que se pareçam com um aplicativo ao invés de um simples site.

5. Sempre Atualizadas

Fazemos com que a aplicação sempre esteja atualizada. As aplicações podem sincronizar em background, mesmo quando estiverem fechadas.

6. Seguras

PWAs devem ser obrigatoriamente fornecidas pelo protocolo HTTPS.

7. Fáceis de Descobrir

Criamos um arquivo de manifesto para que eles possam ser identificados como “aplicativos”, e por ser uma página web, os mecanismos de busca, como o Google, conseguem indexá-los.

8. Envolvente

Podemos estimular a interação do usuário com a aplicação graças às notificações.

9. Instaláveis

Os apps podem ser salvos na tela inicial como um aplicativo instalado, dispensando a necessidade do usuário abrir o navegador.

10. Simples de Compartilhar

Por serem páginas web, podem ser facilmente compartilhadas por sua URL.

Steve Jobs já pensava nisso em 2007

Em 2007, a ideia original de Steve Jobs para o iPhone era que os aplicativos fossem aplicações web.

Segundo ele:

Toda a engine do Safari está dentro do iPhone. Sendo assim, vocês podem escrever incríveis aplicativos para a Web 2.0 com Ajax que se parecem e se comportam exatamente como aplicativos no iPhone. E esses aplicativos podem se integrar perfeitamente com os serviços do iPhone. Eles podem fazer chamadas, enviar um email e procurar por uma localização no Google Maps.

E, adivinha? Não há SDK que você precise! Você tem tudo o que precisa se você souber como escrever aplicativos usando os mais modernos padrões web para escrever aplicativos incríveis para o iPhone hoje. Então, desenvolvedores, achamos que temos uma história muito doce para vocês. Vocês podem começar a construir seus aplicativos para iPhone hoje.

Mas, essa ideia foi alterada em 2008.

Quem usa?

Um ótimo lugar para ver uma lista de PWA’s é o site PWA Rocks.

Várias companhias grandes estão testando PWA e integrando em seus sites, como Washington Post e Flipboard, e outras estão começando a lançar sites betas para testes.

O Twitter Lite é uma PWA completa, e você pode acessá-la por: https://mobile.twitter.com

Quando usar PWA?

Caso precise de várias funcionalidades nativas do dispositivo ou um processamento mais pesado, então pode ser melhor criar um app nativo mesmo. Caso esteja pensando em criar um site ou webapp, criar como PWA é uma boa escolha.

Se você já tem um site ou uma aplicação web, você pode implementar aos poucos as características que definem uma PWA, como notificações, cache de arquivos e dados para o usuário poder acessar offline (que faz a página carregar mais rapidamente também), a possibilidade de salvar o app na tela inicial, receber atualizações de dados mesmo quando estiver com o app fechado, etc.

Implementar apenas algumas dessas características não fará com que você tenha uma PWA completa, mas terá pelo menos uma aplicação otimizada.

Caso queira saber mais sobre o assunto, acabamos de lançar um curso completo sobre PWA aqui no TreinaWeb. Confira:

Quando usar sessionStorage e localStorage?

Olá, Web Developers!

Hoje vou falar sobre um erro comum que vejo muitos colegas cometerem: usam o localStorage para armazenar variáveis temporárias.

Quem usa sabe que o localStorage nos permite armazenar dados de forma simples e sem expiração, ou seja, ficam lá enquanto não apagarmos por código ou pelo próprio navegador.

localStorage.setItem('name', 'Treinaweb');  // <- prefira esta forma
localStorage['name'] = 'Treinaweb';

Porém, já vi situações em que é necessário armazenar um valor logo que o usuário abre a página e manter esse valor enquanto o usuário estiver navegando, mesmo que ele mude de página.

Por ter a possibilidade do usuário clicar em um link e mudar de página (ou recarregá-la), uma variável comum não servirá, pois terá seu valor perdido.

Por isso, muitos desenvolvedores que conhecem o localStorage aproveitam-se dele para esse objetivo. No entanto, o localStorage não tem seus valores apagados, o que causa a necessidade do programador verificar se o usuário acabou de entrar na página para poder apagar ou reiniciar os valores que armazenou no localStorage.

É exatamente para essas ocasiões que existe o sessionStorage. Seu funcionamento e API são idênticos aos do localStorage, com a diferença de que os dados só duram durante a sessão. O usuário pode até mesmo ir para outro site, e as variáveis permanecerão. Elas só serão apagadas quando o usuário fechar o navegador.

sessionStorage.setItem('name', 'Treinaweb');
sessionStorage.getItem('name');

Imagine que o usuário está preenchendo um formulário e pensa em verificar uma informação em outra parte do seu site. Você poderia armazenar os dados do formulário para ele continuar quando voltar. Ao voltar ao formulário, o trabalho dele ainda estará lá.

Se não tem sentido o formulário continuar preenchido caso o usuário tenha fechado o navegador, sem problemas, pois isso irá apagar o sessionStorage, e quando ele voltar, o formulário estará em branco, pronto para um novo preenchimento.

Desta maneira você poderá iniciar suas variáveis temporárias, acessar seus valores enquanto o usuário navega (mesmo que seja para outro site), e não precisará se preocupar em apagar os valores, pois serão apagados automaticamente quando o usuário fechar a janela.

Então, quando precisar de uma variável temporária, lembre-se que o sessionStorage existe para isso. Use o localStorage apenas para dados que devem se manter gravados mesmo com o fechamento do navegador.

Até a próxima!

O problema do iPhone X e a Web

Olá, Web Developers!

Estamos cada vez mais próximos do lançamento oficial do iPhone X, e já apareceu um problema que pode ocorrer no layout de muitos sites.

Há algum tempo, empresas como Samsung, vêm investindo na ideia de fazer com que seus smartphones possuam uma tela mais ampla e, para isso, veio a ideia de remover o botão home físico da parte da frente.

A Apple seguiu a ideia. Porém, ela decidiu ir além, deixando a tela ainda mais expandida, cobrindo quase toda a parte frontal, exceto pelo espaço ocupado pela câmera, como podemos ver na imagem abaixo:


(Jogo sendo executado em um iPhone X)

Isso pode resultar em situações um pouco estranhas ao navegar pela web. Quando o iPhone está na vertical, não há problemas, mas, quando se está com ele na horizontal, para poder acomodar bem as páginas web e evitar que o espaço da câmera cubra algum conteúdo (como o jogo mostrado acima), é criada uma “área de segurança”.

Em muitos sites isso pode resultar em bordas brancas indesejadas, como o exemplo abaixo:

Há pessoas que já reclamaram, dizendo: “Steve Jobs nunca deixaria isso acontecer”. Sendo verdade ou não, é uma realidade.

Temos duas formas de arrumar isso. Veremos abaixo.

Com background-color

Caso a sua página tenha uma única cor como fundo, a solução é a mais simples de todas. Há pessoas que criam um container para a aplicação e inserem a cor de fundo nele. Para resolver o problema, simplesmente coloque a cor de fundo na propriedade background-color da tag <body>.

A sua página vai continuar com as bordas laterais, mas agora ela terá uma cor igual ao do fundo da página, que a tornará imperceptível para o usuário.

Porém, se sua página possui vários fundos, isso não irá resolver. Na home do site do TreinaWeb temos cores diferentes, então, colocar uma só cor no fundo não é uma opção.

Com viewport-fit

Caso você tenha vários fundos, ou uma imagem/vídeo como fundo, ou se ainda quiser ter mais controle do layout, background-color não irá te ajudar.

Neste caso, podemos aproveitar o viewport-fit:

<meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover">  

Isso fará com que sua página ocupe toda a área da tela do dispositivo:

Isso fará com que parte da sua página passe por baixo da área da câmera, mas agora você tem mais controle e pode definir margens para o seu conteúdo ser exibido corretamente.

As constantes safe-area-inset-*

O Safari do iOS 11 também inclui algumas constantes que podem ser usadas quando usamos o viewport-fit=cover.

  • safe-area-inset-top
  • safe-area-inset-right
  • safe-area-inset-bottom
  • safe-area-inset-left

Essas constantes podem ser usadas nas propriedades CSS margin, padding e top, left, right e bottom quando a posição do elemento for position: absolute.

.my-container{
    padding: constant(safe-area-inset-top) constant(safe-area-inset-right) constant(safe-area-inset-bottom) constant(safe-area-inset-left);  
}

Por que devo dar atenção a isso?

Muitos desenvolvedores pensam nesses ajustes como as antigas “gambiarras” que tínhamos que fazer para que um layout moderno funcionasse em versões específicas do Internet Explorer, usando variáveis e funcionalidades específicas de um único navegador.

Porém, também devemos pensar que haverá usuários com esses dispositivos e eles não culparão o aparelho. Eles irão pensar: “há algo errado com esta página”.

Alguns desenvolvedores estão até aproveitando para brincar com o espaço ocupado pela câmera:

Funcionalidades do jQuery com a API nativa do JavaScript

Olá, Web Developers!

Em outro post falamos sobre quando usar e quando não usar o jQuery. Agora nós vamos ver sobre as principais funcionalidades do jQuery que podemos executar apenas com JavaScript nativo. Lembre-se que a maioria dessas funcionalidades estão presentes apenas em navegadores modernos.

Busca de elementos

A principal funcionalidade do jQuery é a busca de elementos. Quando no JavaScript tínhamos funções com nomes compridos e diferentes para cada tipo de seleção (nome do elemento, ID, nome da classe, etc), o jQuery facilitava nossa vida oferecendo uma busca por seletores escritos com a sintaxe do CSS. Hoje em dia isso é possível com a função querySelectorAll().

Também podemos usar essa função para fazer uma busca dentro do elemento selecionado.

// jQuery
var el  = $('div #abc .def');  
$(el).find('button.close');

// JS
var el = document.querySelectorAll('div #abc .def');  
el.querySelectorAll('button.close');  

Requisições Ajax

Uma das funcionalidades mais usadas é a função $.ajax(). Ela é bem mais simples e direta do que trabalhar com o velho objeto XMLHttpRequest.

Hoje em dia nós possuímos a função fetch(), que é tão simples quanto a função $.ajax() e nos permite trabalhar com Promises:

// jQuery
$.ajax({
  'url': '/my/url',
  'type': 'POST',
  'data': JSON.stringify(data)
});

// JS
fetch('/my/url', {  
  'method': 'POST',
  'body': JSON.stringify(data)
})

Classes CSS

Também é comum trabalharmos com a inserção e remoção de classes dos elementos. Poucos usam as funções do JavaScript (muitos nem as conhecem) porque normalmente manipulam com jQuery ou usam algum framework que acaba manipulando os elementos automaticamente.

// jQuery
$(el).addClass('my-class');
$(el).removeClass('my-class');
$(el).toggleClass('my-class');
$(el).hasClass('my-class');

// JS
el.classList.add('my-class');  
el.classList.remove('my-class');  
el.classList.toggle('my-class');  
$(el).hasClass('my-class');

Extend

Esta função permite que os valores de um ou mais objetos sejam atribuidos em outro objeto.

// jQuery
$.extend({}, objA, objB);

// JS
Object.assign({}, objA, objB);  

Uma diferença aqui é que o jQuery permite que os campos de nível mais profundo do objeto sejam misturados, enquanto a função nativa do JavaScript só permite uma união nos níveis mais rasos do objeto.

Eventos

Esse é bem conhecido: adicionar e remover listeners em elementos.

O que não atrai muito (como a maioria das funcionalidades) é a diferença do tamanho do nome das funções.

// jQuery
$(el).on(eventName, eventHandler);
$(el).off(eventName, eventHandler);

// JS
el.addEventListener(eventName, eventHandler);  
el.removeEventListener(eventName, eventHandler);  

Finalizando

Uma lista bem completa de funcionalidades do jQuery feitas com JavaScript puro pode ser encontrada em:

http://youmightnotneedjquery.com/

Porém, como dito anteriormente, deve-se analisar bem as necessidades do projeto para poder dizer se devemos incluir ou não o jQuery.

Compartilhe as suas ideias com a gente aí nos comentários? o/

Ainda vale a pena utilizar o jQuery?

Olá, Web Developers!

Hoje trago aqui algumas reflexões sobre a biblioteca JavaScript mais famosa, o jQuery. Será que ainda vale a pena utilizá-lo?

Ainda é muito comum ver empresas, tanto no Brasil quanto no exterior, cobrando o conhecimento de jQuery. Normalmente ocorre um dos dois motivos para esse requisito: falta de conhecimento de quem escreveu o perfil da vaga ou necessidade de dar suporte a um código legado.

A API do jQuery é bem simples de se aprender, então, nesse caso, será um ponto positivo em seu currículo (mesmo que provavelmente você nem precise utilizar na nova empresa), e não te tomará tanto tempo assim.

Conhecimento nunca é demais. Não precisa estar totalmente atualizado sobre as novidades e conhecer tudo o que está na documentação. Pelo menos saber como ele funciona, sim, vale muito a pena. Há muitos cenários possíveis no mundo da programação e pode aparecer um caso em que a ferramenta se encaixe perfeitamente para a sua necessidade.

Quando devo usar jQuery?

A maior parte dos desenvolvedores dirão “nunca!” para essa pergunta logo de prima. Mas, vamos analisar alguns pontos positivos:

1) Caso precise trabalhar com o DOM, o uso do jQuery pode ajudar, já que sua API é mais elegante e simples do que o JavaScript puro.

2) Caso esteja criando um projeto pequeno, como um site simples, não fará sentido usar um framework poderoso. Se for trabalhar com muitas funções das quais o jQuery possua, ele pode ser um belo aliado para se escrever menos código.

3) Outra vantagem é sua simplicidade. Normalmente a maioria dos desenvolvedores novatos conseguem aprender a usar jQuery mais rapidamente do que outros frameworks ou a API do DOM. Assim, eles já conseguem criar efeitos, animações, requisições e lidar com eventos.

4) Há muitos plugins e ferramentas que usam jQuery. É comum encontrar boas soluções para algumas situações e, nesses casos, o jQuery acaba sendo uma dependência obrigatória. Mas, se possível, prefira procurar algo independente de jQuery para não ter que incluí-lo apenas por causa de uma funcionalidade.

5) O jQuery era muito apreciado por normalizar as diferenças de funcionalidades que existiam entre navegadores. Então, caso ainda precise dar suporte a navegadores mais antigos, o jQuery pode ser uma boa pedida.

6) Por ser simples e direto ao ponto, pode ser perfeito caso esteja apenas precisando criar um protótipo rápido. Eu adoro tentar fazer várias coisas com CSS puro e evitar o máximo de JavaScript, mas tenho que admitir que animações e efeitos com jQuery são bem mais rápidos e simples de se escrever.

Quando evitar?

1) Hoje em dia temos várias funcionalidades do jQuery no próprio JavaScript e as animações são melhores quando feitas com CSS3. Caso só precise dar suporte aos navegadores modernos, provavelmente não precisará do jQuery.

2) Não é bom ficar acessando o DOM diretamente. Caso precise atualizar muito as informações na tela, exibir muitas informações ou acessar o DOM frequentemente, prefira um framework ao invés de usar jQuery ou JavaScript puro, pois eles já são otimizados para se trabalhar com templates, acessando o DOM o mínimo possível. Há também bibliotecas leves que servem apenas para criar componentes com uma ótima performance.

3) O jQuery tem como principal objetivo facilitar o uso de funcionalidades simples do JavaScript (“write less, do more”). Porém, em muitas aplicações será muito comum a necessidade de funcionalidades mais complexas como: roteamento, componentização, formatação, modularização, validações, etc. Nesses casos, para realmente escrever menos, você provavelmente precisará de um framework, o qual terá tantas funcionalidades que dispensará o uso de jQuery.

4) Ao escrever várias funcionalidades com jQuery, é muito comum misturar HTML no meio do JavaScript, dentro de funções. O uso de frameworks modernos nos ajuda a separar e manter o código mais organizado.

5) Em aplicações grandes, você terá muito mais trabalho para gerenciar cada pedaço do que cada código faz. Com jQuery, muitas funcionalidades serão escritas por você, enquanto que com um framework, muitas coisas já estarão prontas e testadas. Tem pessoas que tem medo de frameworks com muita “mágica”, porém, se você souber como usar estas “mágicas” a seu favor, você desenvolverá muito mais rápido e sem erros. As próprias linguagens de programação são “mágicas” em certas funcionalidades. Nós simplesmente aprendemos a utilizá-las ao invés de ficar pensando em como cada bit de informação será processado.

6) O site http://youmightnotneedjquery.com/ possui uma grande lista de funcionalidades do jQuery e como fazer o mesmo com JavaScript puro. Várias funcionalidades são simples de aprender, e as mais complexas você pode encapsular em uma função, evitando ter que incluir a biblioteca inteira caso precise apenas de uma ou outra, apenas.

Então, devo ou não utilizá-lo?

Como sempre, a maioria das coisas em programação resume-se em “depende”.

A melhor maneira de saber se deve ou não usar alguma coisa é ter um bom conhecimento sobre as ferramentas disponíveis, conhecimento da equipe, quais as necessidades do projeto, tempo disponível, etc.

Não há uma resposta absoluta. O melhor mesmo é ter a cabeça aberta para se fazer uma boa análise do que será necessário fazer no projeto e escolher as melhores ferramentas. Fuja de pessoas que usam a palavra “sempre” para alguma biblioteca ou framework pois, normalmente, possuem pouco conhecimento em outras ferramentas.

Espero que os pontos levantados aqui te ajudem a se decidir em seu próximo projeto. Caso tenha outras ideias de quando usar ou evitar, compartilhe com a gente aí nos comentários. =)

Vantagens e desvantagens de labels flutuantes em formulários

Olá, Web Developers!

Há um bom tempo que temos visto formulários com labels flutuantes em vários lugares. A ideia era de trazer algo diferente e melhorar a experiência do usuário. Será que melhorou mesmo?

Nesse artigo eu vou listar as vantagens e as desvantagens que considero pertinentes.

Vantagens

Algumas das vantagens de utilizá-los:

Os formulários ficam menores:

Nós enxergamos os elementos no navegador por blocos.
Na imagem abaixo, enxergamos quatro blocos: dois labels e dois inputs.

Já na imagem abaixo, percebemos apenas dois blocos. Isso passa a impressão de um formulário menor.

Já foram realizados testes com esses estilos de formulários e, no segundo estilo, os usuários realmente pensaram estar preenchendo um formulário com metade do número de campos.

Sem problemas com alinhamento:

Essa não é uma vantagem tão grande. Qualquer CSS bem feito resolve.

Mas, realmente, não precisamos ficar nos preocupando com o alinhamento dos elementos e labels, o que já dá uma pequena facilitada.

Separação entre campos:

Quando temos campos como os da imagem abaixo, precisamos dar um espaço em branco ou separar com uma linha para que o usuário saiba qual campo determinado label pertence.

Nesta imagem sabemos que senha pertence ao campo de baixo porque temos apenas dois campos. Agora, já imaginou um formulário maior? É preciso deixar um espaço bom para podermos perceber melhor a separação e agrupamento de elementos.

Já na imagem abaixo, não precisamos nos preocupar com separação e agrupamento. Mesmo que a gente diminua os espaços entre os inputs, saberemos qual input cada label pertence.

Leitura mais rápida:

Como o label estará dentro dos inputs, e também poderemos diminuir os espaços em branco, como visto no item anterior, a leitura será mais rápida. Isso porque os olhos do usuário precisam passar pelas linhas em branco e pensar na ligação entre elementos quando eles estão separados.

Desvantagens

Agora eu listarei algumas desvantagens.

Nada de labels compridos!

Você tem que pensar bem no que escrever no label para que ele seja bem curto e direto. Do contrário, seu texto pode acabar sendo cortado em dispositivos com telas menores.

No exemplo acima, ao invés de Há quanto tempo trabalha com desenvolvimento?, poderíamos escrever algo como Tempo de experiência, mas nem sempre vamos conseguir deixar claro o que queremos.

Campos preenchidos podem dificultar a leitura:

Quando preenchemos um campo, o label diminui de tamanho, dando espaço ao valor preenchido.

Dependendo do novo tamanho da fonte do label, pode dificultar a leitura, caso o usuário queira revisar os campos do formulário. Lembre-se que podemos ter usuário com problemas de visão usando dispositivos com telas pequenas.

Labels dentro do input podem ser confundidos com campos preenchidos:

Sim, isso é um problema que também pode acontecer com placeholders. O usuário pode simplesmente passar o olho e pensar que aquele campo já está preenchido.

Mesmo que a gente os deixe com uma cor diferente, é sempre bom considerar essa possibilidade, ademais, diferentes usuários, diferentes formas de visualizar e entender o contexto.

Sem consistência de localização:

Não temos uma consistência de localização dos labels quando precisamos de campos que não sejam de texto, como combo boxes, radio buttons e checkboxes.

Concluindo

E você? Usa em seus formulários? É a favor ou contra?
Compartilhe com a gente aí nos comentários! 🙂

JUNTE-SE A MAIS DE 150.000 PROGRAMADORES