Desenvolvimento web

Desenvolvimento de site por R$150,00/Mês

Desenvolvimento Web responsivo com Melhor Custo-beneficio

Planos de desenvolvimento web com hospedagem Gratís
Blog | LCF HOST

Blog


Twitter Bootstrap

Conheça mais sobre Twitter Bootstrap e saiba como você pode desenvolver projetos mais robustos, profissionais e visualmente agradáveis com este incrível framework!

Twitter Bootstrap já não é nenhuma novidade para os desenvolvedores que conseguem acompanhar as melhores tendências e ferramentas lançadas “lá fora” por conseguirem ler em inglês e, apesar de a popularidade do Twitter Bootstrap (TB) poder contar com uma curva crescente de uso em solo brasuca, um artigo sobre este fantástico framework vem, sim, em um bom momento. Se quiser saber mais sobre o Twitter Bootstrap, continue lendo!

O que é o Twitter Bootstrap

Se você acompanha os artigos do desenvolvimento para web, deve se lembrar que em março deste ano, no artigo que comentava sobre o novo tema do blog, que uma das tecnologias usadas por aqui é o Twitter Bootstrap. Entretanto, foi só um comentário “por alto” e, neste artigo você encontrará mais informações sobre o TB.

Idealmente e tecnicamente, o Twitter Bootstrap pode ser considerado um framework. Ele é um projeto que nasceu dentro do Twitter pelas mãos dos desenvolvedores @mdo and @fat. Fato curioso é que, inicialmente, tratava-se de um esforço para documentar determinados padrões de design e UI dentro do Twitter, mas a coisa tomou proporções maiores e seus autores decidiram virar amigos da garotada, disponibilizando o Twitter Bootstrap no Github (que, por sinal, é um dos projetos mais populares de lá).

Grosso modo, o TB é um conjunto de HTML, CSS e JavaScript que proporciona uma maneira ultra-rápida, eficiente e profissional de planejar e desenvolver o front-end de web sites, aplicações, sistemas e produtos web através de seus elementos de UI e interações. Na prática, isso quer dizer que você pode “dar vida” a seus sites e produtos web em apenas algumas horas!

Através do uso de HTML5 e CSS3, os projetos feitos com TB são modernos e garantidos de serem “duráveis”. Para melhorar, o CSS é feito com LESS! E, para constar, no momento da descrita deste artigo, a versão do Twitter Bootstrap é a 2.2.0.

Principais características do Twitter Bootstrap

Como citado, o Twitter Bootstrap possui um conjunto incrível de elementos de marcação, estilo e comportamento para que dar a início a projetos de características profissionais seja uma tarefa bem simples para os desenvolvedores web.

Scafolding

Sua poderosa estrutura conta com:

  • Estilos globais que servem para todos os navegadores modernos
  • Sistema de grid
  • Sistema de grid fluido
  • Layout fixo
  • Layout fluido para web design responsivo

Projetar estruturas de layout com o TB é extremamente simples e muito rápido, já que ele já conta com alguns tipos de grid, layouts e exemplos de marcação para se começar com seu uso imediatamente! Por exemplo, ao se conhecer suas classes, ter um layout fluido é tão simples quanto:

CSS

Com o poder das classes pré-definidas do TB, é possível ter um visual incrível dos elementos de marcação mais básicos e contar com elementos de UI fantásticos. O CSS do Twitter Bootstrap abrange:

  • Tipografia
  • Código
  • Tabelas
  • Formulários
  • Botões
  • Imagens
  • Icon Fonts

Por exemplo, veja como é simples apresentar botões bonitos e funcionais apenas usando algumas classes pré-definidas:

Botõesclass=””
btn
btn btn-primary
btn btn-info
btn btn-success
btn btn-warning
btn btn-danger

Componentes

Provavelmente você nunca criou componentes tão funcionais em seus sites usando uma marcação tão simples e bem pensada, com características cross-browser e visual de encher os olhos. São eles:

  • Dropdowns
  • Grupos de botões
  • Dropdown de botões
  • Navegações
  • Barra de navegação
  • Breadcrumbs
  • Paginação
  • Rótulos e emblemas
  • Tipografia
  • Thumbnails
  • Alertas
  • Barras de progresso
  • E mais!

JavaScript

E, além de prover toda a parte visual para sua aplicação web, o TB também oferece a parte de interação destes componentes visuais! Através de seus plugins próprios para jQuery, é possível obter interações como:

  • Transições
  • Modais
  • Dropdowns
  • Scrollspys
  • Abas
  • Tooltips
  • Popovers
  • Alertas
  • Botões
  • Colapsáveis
  • Carrosséis
  • Autocompletes

É bom demais ou não é? 😉

Recursos para Twitter Bootstrap

E, se não fosse bom o suficiente, existem diversos projetos complementares ao Twitter Bootstrap para que sua força e poder de desenvolvimento seja ainda mais potencializado!

  • Globo BootstrapÉ fácil traduzir um projeto de sucesso no mundo inteiro e colocar o nome da sua marca… De qualquer maneira, está aí o Globo Bootstrap, que é a tradução do TB para a Língua Portuguesa (sinceramente, a qualidade não está tão boa e não há garantias que acompanhe as atualizações do projeto original Segundo Alexandre Magno, toda a comunidade web é bem vinda a contribuir com o projeto, inclusive traduções, e a ideia é continuar na ativa)
  • Built With Bootstrap. Uma galeria com sites feitos com Twitter Bootstrap que mostra todo o potencial do framework
  • Bootswatch. Algumas pessoas criticam que os sites feitos com o TB se parecem demais. Para os que compartilham desta opinião, não tem mais o que reclamar com o Bootswatch, que é uma coletânea de estilos para o Twitter Bootstrap
  • {wrap}bootstrap. Se quiser investir em templates prontos feitos com TB, esse é o lugar!
  • Font Awesome. Com Font Awesome é possível estender os ícones-fonte do Bootstrap, ficando com uma gama de possibilidades bem maior para compor o visual do seu site.
  • Bootsnipp. Snippets HTML grátis para várias situações comuns de UI para Bootstrap.
  • Fuel UX. Fuel UX estende o Twitter Bootstrap com controles JavaScript adicionais. Complemente as interações de seus projetos em TB com combobox, datagrid, pillbox, busca e spinner.
  • X-editable. Se você precisa de um “edit in place” em seus projetos, o X-editable vai servir perfeitamente. Ele é um edit in place para se trabalhar com Twitter Bootstrap (e possui versões para jQuery UI e jQuery puro).
  • Bootstrap Shortcodes. Para os que adoram usar WordPress (eu!), eis uma coletânea de shortcodes para implementar facilmente os elementos visuais do TB.
  • Datepicker for Bootstrap. Se faltava um datepicker para o seu projeto com Bootstrap, agora não falta mais!

Conclusão

Com Twitter Bootstrap é possível dar vida a um projeto em poucas horas, já que sua curva de aprendizado é curtíssima. À medida em que se o vai usando, mais e mais prática é adquirida e, cada vez mais, a produtividade e agilidade em desenvolver o front-end é alcançada. Este é um projeto realmente diferenciado no mundo do desenvolvimento web e seus autores, definitivamente, contribuíram de forma positiva para a melhoria e facilitação do trabalho de seus pares.


CSS Blocks: introdução à API

Veja neste artigo uma introdução à API de CSS Blocks e comece a entender porque este é um dos melhores compiladores CSS da atualidade.

No primeiro artigo sobre CSS Blocks (o primeiro brasuca, aliás!) apresentamos o otimizador de CSS da LinkedIn, explicando um pouco sobre o porquê de sua existência e seus princípios-base. Agora, vamos a mais algumas explicações de código para entender melhor o que CSS Blocks é capaz de fazer.

Como uma breve recapitulação, CSS Blocks é um compilador inspirado em CSS Modules, BEM e Atomic CSS que, usando o OptiCSS, promete entregar estilos bem mais enxutos e performáticos. No momento da publicação deste artigo, é possível usá-lo nas templating languages JSX/React e Glimmer (com WebpackBroccoli ou Ember-CLI) — por se tratar de um projeto open source, a tendência é que mais e mais opções surjam bem rapidamente.

O que é um “Bloco”?

O nome da coisa é CSS Blocks, “Blocos CSS”; mas, segundo a metáfora de desenvolvimento escolhida, o que seria um “Bloco”?

Um Bloco é uma folha de estilo isolada, escrita em seu próprio arquivo, que contém todos os conjuntos de regras para quaisquer elementos e seus vários modos e estados de interação para uma unidade discreta de estilo — como um componente, por exemplo.

Normalmente, um único bloco conterá estilos para um componente ou conceito específico, mas é totalmente natural — e incentivado — um template usar vários Blocos e os compor juntos na marcação.

Um Bloco pode conter:

  • Seletor :scope
  • Seletores de classe
  • Seletores de estado
  • Seletores de sub-estado

Seletor :scope

O conjunto de regras de escopo contém estilos aplicados à raiz da sub-árvore de estilo com escopo. Trocando em miúdos, todos os outros elementos atribuídos a estilos de um Bloco devem estar contidos na sub-árvore do documento de um elemento atribuído ao escopo desse Bloco. Usa-se a pseudo-classe :scope para representar esses estilos.

O seletor :scope pode conter a propriedade especial block-name que torna possível fornecer um nome específico para o Bloco para um debugging mais fácil e respectiva geração de classe BEM. Se nenhum nome de bloco for fornecido, infere-se o nome do bloco a partir do nome do arquivo.

Sim, você leu corretamente: a compilação final de CSS Blocks gera nomes de classes seguindo a metodologia BEM!

Por exemplo:

Seletores de classe

Blocos podem conter outras classes que podem ser aplicadas a elementos dentro da sub-árvore de estilo escopada. São apenas seletores de classe comuns, mas são locais para esse Bloco e isolados de todas as outras classes com nomes iguais em outros Blocos.

Juntos, o seletor :scope e todos os seletores de classe (.class) declarados definem a interface completa dos elementos estilizados disponíveis para quem vai usar um Bloco.

Seletores de Estado

Estados representam um modo ou estado de interação no qual :scope ou uma classe — denominada Elemento Originário do Estado — pode estar. Os Estados são gravados como seletores de atributos com o namespace especial state.

Seletores de sub-estado

Estados no seletor :scope ou um seletor de classe podem conter sub-estados para um estilo mais granular. Os sub-estados de um Estado são mutuamente exclusivos, ou seja, um elemento só pode estar em um sub-estado de um Estado por vez.

Restrições na API de CSS Blocks

CSS Blocks implementa um subconjunto estrito de CSS. Isso significa que alguns dos recursos que normalmente poderiam ser usados em um arquivo em um arquivo de Bloco foram intencionalmente restringidos para garantir que a compilação final possa gerar estilos da maneira mais otimizada possível.

A equipe principal de desenvolvimento do CSS Blocks já planeja melhorias neste sentido; em breve, estas restrições serão bem menores.

Para ficar claro:

  • Permitido:
  • Proibido (por enquanto):
    • !important (você já deveria tê-lo banido, de qualquer maneira)
    • tag[attribute] que não seja de Estado, #id e seletores *
    • Os Combinadores Lógicos :matches():not():something() e :has()
    • Importante: seletores devem se manter rasos (shallow)

No contexto de CSS Blocks, “seletores rasos” significa:

Apenas 1 combinador por seletor

Seletores de Combinadores Hierárquicos (” “ e “>“) devem ser um estado de :scope, sub-estados ou pseudo-classes

Seletores de irmão (“+” e “~“) devem ter como target a mesma classe ou :scope usado no seletor-chave

Como todo o código é analisado e compilado estaticamente (statically) antes de atingir o navegador, obviamente um erro bastante útil será gerado caso alguma dessas restrições de sintaxe seja violada.

Conclusão

É difícil tentar decorar todas essas peculiaridades; com o tempo de uso de CSS Blocks, naturalmente isso vai se internalizar. De qualquer maneira, é bom saber que existe uma tabela bem útil mostrando o que é permitido e proibido na API — que, devido à incipiência de CSS Blocks, deve ser alterada (para melhor) bem rapidinho e com bastante frequência.

Para ficar claro, eis o que acontece na fase de Compilação de CSS Blocks:

O processo de otimização vai além; existem mais passos até que o output final aconteça — ou você achou que CSS Blocks servia só para escrever BEM de maneira mais complicadinha? Mas isso já é assunto para outro artigo…


Diquinhas marotas de CSS Grid (parte 1)

Conheça dicas e macetes (muitas vezes) não tão óbvios sobre CSS Grid e aprimore suas habilidades no melhor que o front-end tem a oferecer para layouts.

Argumentos a favor de CSS Grid já não são mais necessários; a comunidade de webdevs já sabe que CSS Grid Layout é a tecnologia front-end do futuro do presente e chegou para ficar.

Mesmo depois de já conhecer os fundamentos de CSS Grid, é interessante ficar ciente de algumas diquinhas marotas para abrir o horizonte de possibilidades de uso de CSS Grid.

Vamos lá!

Valores menores que -1 podem ser usados para grid-row-end e grid-column-end

Em muitos exemplos e tutoriais sobre CSS Grid, é possível conhecer a possibilidade de usar grid-column-start: 1 e grid-column-end: -1 (ou a shorthand 1 / -1) para abranger (span) um elemento do primeira até a última linha.

Por exemplo, é possível definir grid-column: 1 / -2 para abranger as células entre a primeira e a segunda até a última linha.

É possível usar valores negativos para grid-column/row-start

Outra coisa interessante sobre valores negativos é que também é possível usá-los em grid-column/row-start. A diferença entre valores positivos e negativos é que, com valores negativos, a colocação (placement) virá do lado oposto. Se se definir grid-column-start: -2 o item será colocado na segunda à última linha.

Pseudo-elementos são tratados como grid items

Pode parecer óbvio que os pseudo-elementos gerados com CSS se tornam grid items se estiverem em um grid container, mas não para todos…

Eis uma demonstração rápida sobre isso — em que é possível se ver que os elementos gerados se tornam itens de grid e flex se estiverem dentro de um container correspondente:

Propriedades de CSS Grid podem ser animadas

De acordo com a especificação CSS Grid Layout Module Level 1, há 5 propriedades de CSS Grid que podem ser animadas:

  1. grid-gap
  2. grid-row-gap
  3. grid-column-gap
  4. grid-template-columns
  5. grid-template-rows

Atualmente, funcionam animações apenas de grid-gapgrid-row-gap e grid-column-gap(somente em Firefox e Firefox Mobile).

O valor de grid-column/row-end pode ser menor que o valor inicial

O valor de grid-column-end e/ou grid-row-end pode ser menor que o respectivo equivalente de início.

O item no código acima começará na 4ª linha e terminará na 2ª ou, em outras palavras, começará na 2ª linha e terminará na 4ª.

Usando a palavra-chave “span” em grid-column/row-start e grid-column/row-end

Um item de grid, por padrão, abrange uma única célula. Se for preciso mudar isso, a palavra-chave span pode ser bastante conveniente. Por exemplo, configurar grid-column-start: 1 e grid-column-end: span 2 fará com que o item se estenda por 2 células, da 1ª à 3ª linha.

Também é válido usar a palavra-chave span com grid-column-start. Se se definir grid-column-end: -1 e grid-column-start: span 2, o grid item será colocado na última linha e ocupará 2 células, da última para a 3ª da a última linha.

grid-template-areas e linhas nomeadas implícitas

Se for preciso criar template areas em uma grid, obter-se-á automaticamente 4 linhas nomeadas implícitas, 2 nomeando row-start e row-end e 2 para column-start e column-end. Adicionando o sufixo -start ou -end ao nome da área, eles são aplicáveis como qualquer outra linha nomeada.

Conclusão

CSS Grid Layout é uma tecnologia recente e as possibilidades no front-end só estão se iniciando. Com o passar do tempo (e evolução da especificação), certamente todos seremos presenteados com novas capacidades e, como sempre acontece, dicas e macetes de uso serão descobertos pela comunidade. Aguardemos ansiosamente!


Desenvolvimento Orientado a Modinha (DOM)

Você é adepto do Desenvolvimento Orientado a Modinha? Saiba como escapar dos hypes tecnológicos e se preservar através de importantes análises e dicas.

Você já trabalhou  com equipes que usam aquela metodologia de desenvolvimento infalível, o Desenvolvimento Orientado a Modinha? Você mesmo já usou (e/ou está usando) a mais nova tecnologia de software que aquela grande empresa lançou mês passado? Precisamos conversar sobre Hype Driven Development.

Equipes de desenvolvimento de software muitas vezes tomam decisões sobre arquitetura de software ou pilhas tecnológica com base em opiniões imprecisas, mídias sociais e, em geral, sobre o que é considerado “quente” (hype), em vez de sólida pesquisa e qualquer consideração séria do impacto esperado em seus projetos. Essa tendência pode ser chamada de Desenvolvimento Orientado a Modinha ou DOM —  originalmente, Hype Driven Development. Obviamente, existe uma abordagem mais profissional, chamada por alguns de Engenharia de Software Sólido (Solid Software Engineering). Saiba mais sobre como ele funciona e descubra o que você pode fazer em vez disso.

Nova tecnologia, nova esperança

Qual seu hype favorito?  🙂

Soa familiar? Uma equipe escolhendo tecnologia mais recente, mais “quente” para aplicar no projeto e alguém lê uma postagem em um blog, vê que é tendência no Twitter e todos acabaram de voltar de uma conferência onde houve uma grande conversa sobre isso. Logo a equipe começa a usar esta nova tecnologia brilhante — ou paradigma de arquitetura de software –, mas em vez de ir mais rápido (como prometido) e construir um produto melhor,  começa a se deparar com sérios problemas.

A velocidade de desenvolvimento diminui, todos ficam desmotivados, têm problemas para entregar a próxima versão do projeto para a produção. Algumas equipes ainda mantêm a correção de bugs em vez de fornecer novos recursos. São necessários “apenas mais alguns dias” para resolver tudo…

Desenvolvimento Orientado a Modinha ou Hype Driven Development

Desenvolvimento Orientado a Modinha (ou Hype Driven Development) vem em muitos sabores e toca seu projeto de muitas maneiras diferentes:

  • Desenvolvimento Orientado a Reddit. Quando uma equipe ou indivíduo decide sobre a tecnologia/arquitetura/design com base no blogueiro popular que escreveu o que está quente no Reddit, Hacker News, blog do Twitter, Facebook, GitHub ou outras mídias sociais.
  • Desenvolvimento Orientado a Conferência. Observe cuidadosamente o que acontece depois que pessoas (e programadores) retornam de uma conferência: elas ficam inspiradas. E isso é uma espada de dois gumes: começar a usar o mais novo paradigma/biblioteca/framework/arquitetura sem pesquisa suficiente pode ser uma estrada para o inferno.
  • Desenvolvimento Orientado ao Cara que Fala Mais. As decisões mais influentes são as do que está falando o tempo todo sobre esse novo framework/biblioteca/tecnologia que ele não tem experiência, mas fala sobre isso o tempo todo e finalmente a equipe decide adotar a coisa.
  • Desenvolvimento Orientado a Gem/lib/plugin. Um viés especialmente forte na comunidade Ruby On Rails, em que é possível ver um Gemfile por tanto tempo que a única coisa que leva mais tempo é para carregar o aplicativo. Vem da idéia de que cada problema em Rails deve ser resolvido através de um gem — sendo que, às vezes, apenas uma ou duas linhas de código dariam conta do recado ao invés de resolver o problema acrescentando mais problemas com libs, plugins, gems e/ou frameworks.
  • Desenvolvimento Orientado a Stack Overflow. Certamente uma das mais comuns de acontecer, dá-se quando programadores copiam e colam soluções do Stack Overflow (ou encontradas na web, em geral) sem realmente entendê-las.

A raiz de todo o mal?

O problema com hypes é que eles facilmente levam a más decisões. Tanto a decisões arquitetônicas ruins, quanto a decisões tecnológicas sobre stacks costumam assombrar uma equipe meses ou mesmo anos mais tarde. No pior caso, elas podem levar a outra situação muito problemática em engenharia de software: A Grande Reescrita (The Big Rewrite).

A raiz de todo o mal parece estar nas mídias sociais, nas quais novas idéias se espalham muito mais rápido do que são testadas; muito mais rápido do que as pessoas são capazes de compreender os seus prós e contras.

A anatomia de um hype

A maioria dos hypes têm uma estrutura similar a esta:

“Ciclo do Hype” (clique para ampliar)

Passo 1: Problema real e solução

Eles começam em alguma empresa com um problema. Uma equipe dentro de alguma empresa decide que a solução para o problema está além da pilha tecnológica atual, processo ou arquitetura. A empresa cria uma nova estrutura, biblioteca ou paradigma e logo o problema é resolvido.

Passo 2: Buzz & Keywords

A equipe está animada para mostrar seu trabalho para o resto do mundo e logo eles escrevem posts e fazem palestras e conferências. O problema muitas vezes não é trivial, então eles se orgulham de apresentar os resultados impressionantes de uma solução “da casa”. As pessoas ficam entusiasmadas com a nova tecnologia. O maior problema é que nem todos que ficam animados são capazes de compreender exatamente qual era o problema inicial e todos os detalhes da solução — afinal, tratava-se de um problema não-trivial com uma solução não-trivial.

Leva mais do que um tweet, bate-papo ou post no blog para explicar. Com ferramentas de comunicação como mídias sociais, artigos de blogs e conferências-relâmpago, ocorre muito ruído na comunicação e a mensagem fica “borrada” ao longo do caminho.

Passo 3: Obsessão

Toda força do hype leva desenvolvedores a lerem artigos e a participarem de conferências sobre a tecnologia. Logo as equipes de todo o mundo começam a usar a usá-la. Devido à mensagem “borrada”, algumas delas tomam decisões precipitadas de uso da tecnologia — mesmo que ela não resolva qualquer um de seus problemas reais. No entanto, a equipe tem expectativa de que esta nova tecnologia vai ajudar.

Passo 4: Desapontamento

Conforme os sprints passam, a tecnologia não melhora a vida da equipe tanto quanto as pessoas esperavam, mas traz muito trabalho extra. Há muita reescrita de código e aprendizagem extra para a equipe. As equipes diminuem a velocidade, a administração fica chateada. Todos se sentem enganados.

Passo 5: Realização

Finalmente, a equipe faz uma retrospecção e percebe quais são os prós e contras da nova tecnologia e para que finalidade ela seria mais relevante. Todos ficam mais sábios… Até o próximo hype aparecer.

Exemplos reais de hypes

É só pensarmos um pouquinho para lembrar de alguns exemplos reais do “Ciclo do Hype”, em ocasiões que trouxeram muitos infortúnios para muitas equipes de desenvolvimento pelo mundo.

React.js

  1. Problema real e solução. SPAs, como o próprio Facebook, têm tantos eventos de mudança de estado que é difícil manter o controle do que está acontecendo e manter o estado do aplicativo consistente.
  2. Buzz & Keywords. “Funcional”, “DOM Virtual”, “Componentes”.
  3. Obsessão. “Facebook criou a estrutura front-end do futuro! Vamos escrever tudo em React de agora em diante!”
  4. Desapontamento. Há muito trabalho, mas nenhum retorno rápido sobre o investimento.
  5. Realização. React é ótimo para SPAs avançados com muitas notificações em tempo real, mas não necessariamente vale a pena para aplicativos mais simples.

“TDD está morto”

  1. Problema real e solução. David Heinemeier Hansson (criador do framework Ruby on Rails) percebe que é difícil fazer TDD com Rails — já que ele não tem uma boa arquitetura, que comporta OOP — e faz uma escolha pragmática: não escrever mais testes antecipadamente; não trabalhar mais com TDD.
  2. Buzz & Keywords. O hype começa com um post no blog de DHH e uma conferência. Termo-chave do hype: “TDD está morto”.
  3. Obsessão. “Vamos pular os testes! Nosso Guru diz isso. Nós não escrevemos eles de qualquer maneira. Agora, pelo menos, não estamos fingindo. Finalmente somos honestos.”
  4. Desapontamento. Há muito trabalho, mas nenhum retorno rápido sobre o investimento.
  5. Realização. “TDD não está morto ou vivo. TDD está sujeito a tradeoffs, incluindo o risco de mudanças de API, habilidades dos participantes e design existente.” — Kent Beck.

Microservices

  1. Problema real e solução. Grandes aplicações monolítica têm escalonamento difícil. Há um ponto em que é possível dividí-las em serviços. Será mais fácil de escalar em termos de req/sec e mais fácil de escalar entre várias equipes.
  2. Buzz & Keywords. Palavras-chave do hype: “Escalabilidade”, “Baixo Acoplamento”, “Monolítico”.
  3. Obsessão. “Temos um ‘código de espaguete’ porque temos uma arquitetura monolítica! Precisamos reescrever tudo para microservices!”
  4. Desapontamento. Agora é mais lento desenvolver o aplicativo. E difícil de implantar e se passa muito tempo rastreando bugs em vários sistemas.
  5. Realização. Microservices exigem habilidadess “devops” na equipe. Antes de se chegar a graves questões de escalonamento, são um um investimento excessivo. Microservices são extraídos, não escritos.

NoSQL

  1. Problema real e solução. Bancos de Dados SQL têm problemas com cargas elevadas e dados não estruturados. Equipes de todo o mundo começam a desenvolver uma nova geração de BDs.
  2. Buzz & Keywords. Palavras-chave do hype: “Escalabilidade”, “BigData”, “Alta Performance”.
  3. Obsessão. “Nosso banco de dados é muito lento e não é grande o suficiente! Precisamos do NoSQL!”
  4. Desapontamento. “Precisamos usar JOIN nas tabelas? Isso é problemático”. Operações SQL simples se tornam cada vez mais desafiadoras. O desenvolvimento fica lento e os principais problemas não são resolvidos.
  5. Realização. NoSQL são ferramentas para resolver problemas muito específicos — tanto volumes extremamente elevados de dados, dados não estruturados ou cargas muito altas. SQL é realmente uma ótima ferramenta, capaz de lidar com alta carga e volumes de dados enormes se for bem usada.

Elixir e Phoenix (ou sua dobradinha favorita de linguagem/framework)

  1. Problema real e solução. Frameworks web como o Ruby On Rails não lidam bem com aplicativos de alto desempenho, aplicativos distribuídos e websockets.
  2. Buzz & Keywords. Palavras-chave do hype: “Escalabilidade”, “Alta Performance”, “Distribuído”, “Tolerante a Falhas”.
  3. Obsessão. “Nosso aplicativo é lento e nosso bate-papo não é escalável!”
  4. Desapontamento. “Aprender programação funcional e abordagem distribuída não é tão fácil. Agora estamos muito lentos.”
  5. Realização. Elixir e Phoenix formam um excelente framework, mas demanda um esforço significativo para aprender. Haverá retorno a um longo prazo se você precisa especificamente de um app de alto desempenho.

E a lista continua…

O espaço lotado da Engenharia da Computação apresenta muitas áreas em que hypes são comuns. No mundo do JavaScript, por exemplo, novos frameworks  são criados todos os dias. Node.js, Programação Reativa, Meteor.js, Front-end MVC, React.js. Na engenharia de software nascem novas arquiteturas: Domain Driven Development, Hexagon, DCI…

Qual é o seu hype favorito?  🙂

Boas práticas para evitar o DOM

Aprenda sobre uma tecnologia não somente de blogs, mas com a experiência.

Então, se não podemos confiar no que a internet diz e opiniões de outras pessoas, como tomar decisões inteligentes em relação ao Desenvolvimento Orientado a Modinha? Eis algumas dicas e boas práticas.

Teste e pesquise antes de decidir

Aprenda sobre uma tecnologia não somente de blogs, mas com a experiência. A caráter de testes, invista 1 ou 2 dias para construir um protótipo de alguma funcionalidade na nova tecnologia antes de tomar uma decisão. Deixe a equipe analisar os prós e contras. É possível usar algumas tecnologias competitivas e permitir que diferentes partes da equipe construam protótipos com tecnologias diferentes.

Participar de hackathons é uma ótima maneira de construir a consciência de uma equipe através da análise de tradeoffs de diferentes tecnologias. Tome 1 ou 2 dias para toda a equipe testar todas as tecnologias que estão em ascensão. Isso permitirá que a equipe tome decisões inteligentes por si mesma, com base em sua própria experiência.

Quando arriscar?

A princípio, quando o retorno do investimento é enorme. A maioria das tecnologias são criadas para resolver um problema específico. Você tem esse problema? É um problema grande? Será que vai economizar muito tempo? Será que o uso da tecnologia paga o custo da curva de entrada e reescrita? E se inicialmente retardarmos o desenvolvimento pelo fator de dois? Ou quatro? Ainda vale a pena?

Algumas equipes são mais rápidas do que outras em entregar valor, chegando ao ponto de ficarem entediadas ao realizarem entregas de maneira mais fácil. Essas equipes podem introduzir novas tecnologias com mais freqüência — por outro lado, se a equipe tem problemas com entregas, este um forte indício para proceder com cautela.

Trabalhe com as pessoas certas

Ter uma formação técnica sólida é essencial: pessoas que conhecem diferentes paradigmas, compreendem a teoria da programação (por exemplo, algoritmos, concorrência etc) e têm boa cultura de engenharia tendem a ser menos suscetíveis a hypes.

Experiência também conta muito. Hypes impressionam mais desenvolvedores jovens. Com o passar dos anos, as pessoas que viram muitas tecnologias e estiveram em problemas muitas vezes tendem a ter uma visão mais equilibrada da tecnologia e sabem escolher melhor.

Conclusão sobre Desenvolvimento Orientado a Modinha

Desenvolvimento Orientado a Modinha (ou Hype Driven Development) não é novidade. Acontece de de um hype realmente se consolidar no mercado e se tornar “a nova melhor prática”, mas a quantidade de hypes é tão grande que, estatisticamente, poucos são os que alcançam o status de “paradigma” e se mantêm lá.

As dicas de testar e pesquisar, saber quando arriscar e trabalhar com as pessoas certas — com ênfase aos não tão jovens e/ou aventureiros — realmente surtem resultados. Seguí-las pode determinar o sucesso ou fracasso de seus negócios no mundo dos softwares.

bom senso sempre foi um dos melhores aliados de todos nós. Parece que é hora de começar a dar mais atenção a este velho amigo.


A maneira 100% correta de fazer breakpoints em CSS

Depois de anos usando breakpoints, será que a maioria dos desenvolvedores front-end realmente já pararam para pensar se estão fazendo do jeito certo?

Para o próximos 2 ou 3 minutos, esqueça o que é CSS (e o que são breakpoints em CSS); esqueça o que é desenvolvimento para web; esqueça o que são digital user interfaces. E, ao esquecer estas coisas, permita que sua mente vagueie.

Que volte no tempo, para a sua época de escola — aquele tempo mais simples, quando suas maiores preocupações eram desenhar formas e manter sua incontinência sob controle.

Dê uma olhada nessas bolinhas:

Observe como alguns deles estão agrupados e alguns espalhados. Prosseguindo ao exercícios mental, divida-as em 5 grupos e depois desenhe um círculo em torno de cada um destes grupos.

Provavelmente a solução para a questão terá sido algo como isso:

Claro, o grupamento desses 2 pontos à direita poderia ter sido de outra maneira. Na verdade, toda a demarcação também poderia ter sido diferente do “usual”, resultando em algo mais ou menos como:

Parece que desse jeito não ficou muito bom, foi um “agrupamento bobo”… Certo?

Mas isso é basicamente o que 99% dos desenvolvedores front-end fazem para definir breakpoints que correspondem à largura exata de dispositivos populares (320px768px1024px)!

Palavras mais ou menos como essas já entraram em seus ouvidos ou saíram de sua boca?

O breakpoint “medium” é até 768px ou inclui 768px? E isso é landscape no iPad ou é o breakpoint “large”? Oh, “large” é 768px para cima. O “small” é 320px, certo? De 0 a 319px.

É curioso que o método acima, o “agrupamento bobo”, esteja tão difundido… Mas, então, qual deveria ser a maneira correta de fazer breakpoints em CSS?

Provavelmente a resposta para este problema, como para tantos outros, se resuma a uma terminologia desalinhada. Neste caso específico, misturas indiscriminadas de termos como “limites” (boundaries) e “intervalos” (ranges) nas discussões e implementações de breakpoints.

Fazendo uma suposição, provavelmente você tem uma variável em Sass $large com o valor de 768px. Esse é o limite inferior (lower boundary) ou superior (upper boundary) do intervalo (range) conhecido como “large”?

Se for o inferior, então não deve haver $small, já que ele teria que ser 0, certo?

E se for o superior, então como foi definido um breakpoint $large-and-up? Deve ser uma media query com min-width de $medium, confere? E se está se referindo a apenas um limite quando se refere a “large”, então haverá confusão mais tarde, porque uma media query é sempre um intervalo (range).

Essa situação é caótica e estamos perdendo tempo pensando nisso. Então aqui vão 3 sugestões:

  1. Crie breakpoints do jeito certo
  2. Nomeie breakpoints corretamente
  3. Seja declarativo

Crie breakpoints do jeito certo

No final das contas, qual é “o jeito certo” para criar breakpoints?

Lembra da divisão das bolinhas em grupos? Basta fazer a coisa direito que se chegará a algo como:

600px900px1200px e 1800px (se for preciso servir algo especial a pessoas com monitores gigantes).

Essa divisão representada os 14 tamanhos de tela mais comuns:

A partir daí, torna-se possível idealizar um sistema que permita o fluxo fácil de palavras entre pessoas vestidas com ternos, designers, desenvolvedores e testadores:

Nomeie breakpoints corretamente

Evidentemente, você pode nomear seus breakpoints da maneira que quiser, até como papa-bear e baby-bear. Mas, geralmente, quando pessoas de um time de desenvolvimento se sentam para resolver alguma questão, é interessante que os nomes dados não sejam um empecilho. Se nomear um tamanho para um tablet em orientação de retrato facilitar isso, tudo bem — alguns poderiam até chamar isso de… “iPad portrait”.

Mas alguns podem alegar que “o cenário está mudando”. “Telefones estão ficando maiores e tablets menores”.

Acontece que o CSS dos projetos geralmente têm uma vida-média de uns 3 ou 5 anos (a menos que seja o Gmail). O iPad esteve conosco por 2 vezes durante esse tempo e ainda não foi destronado — e sabemos que a Apple já não fabrica novos produtos; simplesmente remove coisas dos existentes (botões, buracos etc.).

Então, para o bem e para o mal, 1024×768 está aqui para ficar. Não vamos enterrar nossas cabeças na areia.

Conclusão: comunicação é importante! Não dispense propositalmente vocabulário útil.

Seja declarativo

Que se entenda por “declarativo” que o CSS deve definir o que ele quer que aconteça e não como isso deve acontecer. O “como” pode ficar implícito em algum tipo de mixin ou coisa assim.

Como discutido anteriormente, parte da confusão sobre breakpoints é que variáveis que definem um limite de um intervalo (boundary of a range) são usadas como o nome do intervalo. $large: 600px simplesmente não faz sentido se “large” for um intervalo. É o mesmo que declarar var coordinates = 4;.

Em função disso, é conveniente esconder esse tipo de detalhe dentro de um mixin ao invés de o expor para ser usado no código. Ou, fazendo melhor, sequer usar variáveis.

No começo, o trecho de código abaixo servia apenas como um exemplo simplificado. Mas realmente ele tem potencial para fazer uma boa cobertura de casos. Para vê-lo em ação, confira este pen — o uso de Sass é opcional; a lógica se aplica a qualquer outro pré-processador ou CSS puro exatamente do mesmo jeito.

@mixin for-phone-only {
@media (max-width: 599px) { @content; }
}
@mixin for-tablet-portrait-up {
@media (min-width: 600px) { @content; }
}
@mixin for-tablet-landscape-up {
@media (min-width: 900px) { @content; }
}
@mixin for-desktop-up {
@media (min-width: 1200px) { @content; }
}
@mixin for-big-desktop-up {
@media (min-width: 1800px) { @content; }
}
// usage
.my-box {
padding: 10px;
@include for-desktop-up {
padding: 20px;
}
}

Perceba que é proposital forçar o uso dos sufixos -up/-onlyAmbiguidade gera confusão.

Uma crítica óbvia pode ser que isso não lida com media queries personalizadas. Mas há boas novas: se você quiser uma media query personalizada, escreva uma media query personalizada!

Outra crítica pode ser relativa à quantidade de mixins criados. Certamente, um único mixin com o tamanho necessário sendo passado seria o mais sensato a ser feito. Algo assim:

@mixin for-size($size) {
@if $size == phoneonly {
@media (max-width: 599px) { @content; }
} @else if $size == tabletportraitup {
@media (min-width: 600px) { @content; }
} @else if $size == tabletlandscapeup {
@media (min-width: 900px) { @content; }
} @else if $size == desktopup {
@media (min-width: 1200px) { @content; }
} @else if $size == bigdesktopup {
@media (min-width: 1800px) { @content; }
}
}
// usage
.my-box {
padding: 10px;
@include for-size(desktop-up) {
padding: 20px;
}
}

Claro, isso funciona. Mas você não receberá erros em tempo de compilação (compile-time errors) se passar um nome sem suporte. E passar em uma variável Sass significa expor 8 variáveis apenas para passar para um switch em um mixin — sem mencionar que a sintaxe @include for-desktop-up {...} é mais bonita do que @include for-size(desktop-up) {...}.

Ainda uma outra crítica a esses snippets pode ser a repetição de 900px e também 899px. Certamente, deveria-se usar apenas variáveis e subtrair 1 quando necessário.

Se quiser fazer isso, vá em frente, mas há 2 razões principais a serem consideradas:

  1. Essas não são coisas que mudam com frequência. Estes também não são números que são usados em qualquer outro lugar na base de código. Nenhum problema é causado pelo fato de não serem variáveis — a menos que você queira expor seus breakpoints de Sass a um script que injete um objeto JS com essas variáveis na sua página.
  2. A sintaxe fica nojenta quando você quer transformar números em strings com Sass. Eis o preço a ser pago por acreditar que repetir um número duas vezes é o pior de todos os males:
@mixin for-size($range) {
$phone-upper-boundary: 600px;
$tablet-portrait-upper-boundary: 900px;
$tablet-landscape-upper-boundary: 1200px;
$desktop-upper-boundary: 1800px;
@if $range == phoneonly {
@media (max-width: #{$phone-upper-boundary – 1}) { @content; }
} @else if $range == tabletportraitup {
@media (min-width: $phone-upper-boundary) { @content; }
} @else if $range == tabletlandscapeup {
@media (min-width: $tablet-portrait-upper-boundary) { @content; }
} @else if $range == desktopup {
@media (min-width: $tablet-landscape-upper-boundary) { @content; }
} @else if $range == bigdesktopup {
@media (min-width: $desktop-upper-boundary) { @content; }
}
}
// usage
.my-box {
padding: 10px;
@include for-size(desktop-up) {
padding: 20px;
}
}

Por fim, alguém pode estar pensando “Eu não deveria basear meus breakpoints em conteúdo, não em dispositivos?”. Basicamente, a resposta é: sim… Para sites com um único layout — ou se existirem vários layouts e existem algum prazer mórbido em ter um conjunto diferente de breakpoints para cada um deles.

Para sites complexos, “do mundo real”, a prática sugere escolher alguns breakpoints para serem usados em todo o site.

Conclusão sobre a maneira 100% correta de fazer breakpoints em CSS

Brincadeiras de título à parte, certamente não existe uma maneira “100% correta” para se fazer ou usar breakpoints. Mas é difícil negar que a abordagem apresentada nesse artigo certamente pode trazer interessantes reflexões sobre o tema.

Sendo assim, considere os conteúdos apresentados como sugestões de técnicas a serem seguidas e, depois de as experimentar, julgue se fazem ou não sentido dentro dos projetos que você e/ou sua equipe participam.


Erros comuns em desenvolvimento web para campanhas de SEO

Conheça erros comuns em desenvolvimento web para campanhas de SEO e saiba como evitá-los

Uma boa campanha de SEO acontece quando várias ações de otimização são realizadas, conjunta e simultaneamente. E, certamente, uma dos aspectos da estratégia de uma ação de SEO são as ações técnicas tomadas no desenvolvimento web.

Este é um artigo traduzido do original “Why my SEO campaign failed? Part 2: Common Web Development mistakes“, do blog Web SEO Analytics, e sofreu pequenas modificações.

Passar muitos argumentos no URL

Quando o site é dinâmico, os desenvolvedores web precisam ter uma referência sobre o qual a página, o produto ou categoria o visitante quer ver. Normalmente um ID é necessário para recuperar os dados do banco de dados. Em outros casos, devido à complexidade do projetoou devido a más técnicas de programação, mais variáveis são necessárias para identificar uma determinada página. Aqui está um exemplo de um URL dinâmico:

Infelizmente, este tipo de URL não é amigável nem para pessoas, nem para mecanismos de busca. Segundo é possível ler nas Diretrizes Técnicas das Diretrizes para Webmasters da Central do Webmaster Google,

Se você decidir usar páginas dinâmicas (por exemplo, o URL que contém um caractere “?”), saiba que nem todos os spiders de mecanismos de pesquisa rastreiam as páginas dinâmicas e estáticas. Isso ajuda a manter os parâmetros curtos e a quantidade desses parâmetros pequena.

Por isso, é altamente recomendado usar algum tipo de reescrita de URL, como mod_rewrite, para converter as URLs dinâmicas para URLs amigáveis. Qual é o risco, se isso não for feito? Bem, se há muitos parâmetros em URLs: os motores de busca podem não indexar as páginas; além disso, geralmente  URLs não amigáveis não contém palavras-chave importantes no endereço, então, não raramente você pode conseguirá rankings inferiores para essas páginas do que se elas tivessem URLs amigáveis.

Usar muito JavaScript, frames/iframes, AJAX, Flash e Silverlight

JavaScript, frames/iframes, AJAX, Flash e Silverlight são ferramentas úteis e alguns deles, quando bem usados, melhoram a experiência do usuário. Mas nenhum deles é search engine friendly.

As mesmas Diretrizes Técnicas do Google citadas, indicam:

Use um navegador de texto como o Lynx para examinar o seu site, pois muitos spiders de mecanismos de pesquisa veem o site do mesmo modo que o Lynx. Se recursos especiais como JavaScript, cookies, IDs de sessão, frames, DHTML ou Flash permitirem que você veja todo o site em um navegador de texto, os spiders dos mecanismos de pesquisa poderão ter dificuldade em rastrear o seu site.

Se o objetivo é que o site seja amigável aos mecanismos de busca, devemos verificar se eles podem ser vistos usando browsers de texto simples como o Lynx (que é como o googlebot “vê” os sites). É possível usar emuladores do Lynx ou desabilitar CSS e imagens diretamente no navegador (se usar, Firefox, uma ótima opção é usar o plugin Web Developer).

Não usar o atributo alt em imagens e não otimizar o caminho das imagens

Os motores de busca (e computadores, em geral) não são muito bons em identificar o que é representado em uma imagem. Portanto, a fim de compreender sobre o que uma imagem é, os bots analisam o nome e o atributo “alt” das imagens.

O Google Image Search pode trazer uma quantidade significativa de tráfego. Se você não garantir o “apoio” a mecanismos que permitam a otimização de imagens, você pode perder uma boa fonte de tráfego. Assim, garanta que você use corretamente ambos, o atributo alt e o nome da imagem – usar um CMS que permita esse tipo de otimização é uma boa dica.

Usar métodos incorretos para oferecer suporte a idiomas diferentes

Quando você tem sites multilíngue, tenha certeza de que a arquitetura está correta. Não há uma única forma “correta” para fazer isso. Basicamente, há três maneiras corretas para suportar um site em vários idiomas e cada um dos métodos a seguir tem alguns prós e contras:

  • Subdomínios. Exemplo: fr.example.com, gr.example.com, etc
  • Subdiretórios. Exemplo: www.example.com/fr/, www.example.com/gr/, etc
  • Diferente domínios. Exemplo: www.example.fr, www.example.gr, etc

A dica é evitar o envio de conteúdo baseado em IP sem ter a mesma versão do site disponível para todos. Também não implementar soluções ruins como passar o idioma como uma variável GET, por exemplo www.example.com/?lang=fr.

Não se preocupar com o tempo de carregamento da página

Recentemente o Google informou que passou a usar a velocidade de carregamento dos websites em seus algoritmos de classificação (apesar de isso não estar valendo para sites de todos os países do mundo). Há um debate sobre se esse recurso deve ser incluído, uma vez que não tem nada a ver com a relevância de um site. No entanto, a velocidade aumenta a experiência do usuário. Além disso, ter um site leve, que carregue rapidamente, pode melhorar seu ROI e diminuir a carga do seu servidor (conheça 8 maneiras de melhorar a performance de um site).

7 dicas de desenvolvimento web

Algumas dicas para guiar o desenvolvimento de suas páginas web são:

  • Colocar menus, cabeçalhos e rodapés em arquivos separados, a fim de realizar mudanças globais rápidas (funções “include);
  • Tentar usar subdomínios em sites multi idioimas;
  • Usar caminhos absolutos para cada página, imagem, CSS e javascript do site;
  • Usar canonicals para evitar conteúdo duplicado;
  • Usar redirecionamento 301 ao invés de 302 quando o caminho para a página mudar e nunca apagar páginas;
  • Redirecione corretamente as versões sem “www” para as que tenham “www” e vice-versa;
  • Não adicionar IDs de sessão nas URLs.

E você, conhece algum outro erro comum em desenvolvimento web que pode atrapalhar uma campanha de SEO e o que fazer para evitar/corrigir?


Dominando o “this” em JavaScript

A palavra-chave “this” em JavaScript confunde desenvolvedores novos e experientes. Leia este artigo e domine o “this” em JavaScript!

A palavra-chave this em JavaScript confunde desenvolvedores JavaScript novos e experientes. Este artigo pretende elucidar a questão de uma vez, deixando claro como usar this corretamente em todos os cenários, incluindo situações mais peculiares em que normalmente this se revela mais difícil de ser compreendido.

Em JavaScript, usa-se this de forma semelhante ao uso de pronomes em linguagens naturais, como o inglês ou francês. Escreve-se: “João está correndo rápido porque ele está tentando pegar o trem”. Note o uso do pronome “ele”. Poderia se ter escrito: “João está correndo rápido porque João está tentando pegar o trem”. Não se reutiliza “João” dessa maneira, pois se assim fosse, nossa família, amigos e colegas nos abandonariam… De uma maneira graciosamente semelhante, em JavaScript se usa a palavra-chave this como um atalho, um referente; ou seja, o sujeito no contexto ou o sujeito do código em execução.

Exemplo:

Se se usa person.firstName e person.lastName, tal como no último exemplo, o código se torna ambíguo. Considere que poderia haver outra variável global (você estando ciente dela ou não) com o nome “person”. Em seguida, as referências a person.firstName poderiam tentar acessar a propriedade firstName da variável global person e isso poderia levar a erros difíceis de serem depurados. Portanto, usa-se a palavra-chave this não apenas para fins “estéticos” (isto é, como um referente), mas, também, para fins de precisão. Seu uso realmente torna o código mais inequívoco, assim como o pronome “ele” tornou a frase mais clara, informando que se estava referindo ao João específico do início da frase.

Assim como o pronome “ele” é usado para se referir ao antecedente (substantivo a que um pronome se refere), a palavra-chave this é similarmente usada para se referir a um objeto a que a função (onde this é usado) está vinculada. Esta palavra-chave não se refere apenas ao objeto, mas também contém o valor do objeto. Assim como o pronome, isso pode ser pensado como um atalho (ou um substituto razoavelmente não-ambíguo) para se referir ao objeto no contexto (o “objeto antecedente”).

O básico sobre this em JavaScript

Primeiramente, é preciso saber que todas as funções em JavaScript têm propriedades, assim como os objetos têm propriedades. E quando uma função é executada, ela obtém a propriedade this — uma variável com o valor do objeto que invoca a função na qual this é usado.

A referência ao this sempre se refere a (e contém o valor de) um objeto — um objeto singular — e normalmente é usado dentro de uma função ou método, embora possa ser usado fora de uma função no escopo global.

Quando em modo estrito (strict mode), this mantém o valor undefined em funções globais e em funções anônimas que não estão vinculadas a nenhum objeto.

this é usado dentro de uma função (digamos função “A”) e ele contém o valor do objeto que invoca a função A. Isso é preciso para acessar métodos e propriedades do objeto que invoca a função A, especialmente porque nem sempre é possível saber o nome do objeto invocador e, às vezes, não há nenhum nome para usar para se referir ao objeto invocando. Na verdade, this é realmente apenas um atalho-referência ao “objeto antecedente” (ou o objeto invocador).

Reflita sobre este exemplo básico que ilustra o uso de this em Javascript:

E também considere este exemplo em jQuery:

Explicando melhor o exemplo jQuery anterior: o uso de $( this ), que é a sintaxe da jQuery para esta palavra-chave em JavaScript, é usado dentro de uma função anônima, que é executada no “on click” do botão. A razão pela qual $( this ) está vinculado ao objeto de botão é porque a jQuery vincula $( this ) ao objeto que invoca o método de clique. Portanto, $( this ) terá o valor do objeto jQuery ($( 'button' )) mesmo que $( this ) seja definido dentro de uma função anônima que não pode acessar a variável “this” na função externa.

Importante ressaltar que o botão é um elemento DOM na página HTML e também é um objeto; neste caso, é um objeto jQuery porque está envolvido na função jQuery $().

A maior pegadinha com this em JavaScript

Se você entender este princípio de JavaScript, você entenderá a palavra-chave “this”: não é atribuído um valor a this até que um objeto invoque a função na qual this é definido.

Para fins didáticos, considere onde this está definido como “Função this”. Mesmo que pareça que this se refere ao objeto onde ele é definido, isso só acontece quando um objeto chama a “Função this” a que this está atualmente atribuído. E o valor atribuído é baseado exclusivamente no objeto que invoca a “Função this”.

this tem o valor do objeto sendo invocado na maioria das circunstâncias. No entanto, existem alguns cenários nos quais this não tem o valor do objeto sendo invocado. Cenários estes visto mais à frente.

O uso de this em escopo global

No escopo global, quando o código está sendo executado no navegador, todas as variáveis globais e funções são definidas no objeto window. Portanto, quando se usa this em uma função global, ele se refere a (e tem o valor de) o objeto window global — não no strict mode, como observado anteriormente –, que é o contêiner principal de toda a aplicação JavaScript ou página da web.

Deste modo:

Quando this é mal compreendido e se torna complicado

A palavra-chave this é mais mal compreendida em “métodos emprestados”; quando se atribui um método que usa this para uma variável; quando uma função que usa this é passada como uma função de callback e; quando this é usado dentro de uma closure (uma função interna).

Um pouco sobre “contexto” antes de continuarcontexto em JavaScript é semelhante ao assunto de uma frase na escrita normal. Na frase “João é o vencedor quem devolveu o dinheiro.” o sujeito da sentença é João e é possível afirmar que o contexto da sentença também é João porque o foco da sentença está nele neste momento particular da sentença. Mesmo o pronome “quem” está se referindo a João, o antecedente. E tal como é possível usar um ponto-e-vírgula para mudar o assunto da frase, também é possível ter um objeto que é o contexto atual e mudar o contexto para outro objeto invocando a função com outro objeto.

Similarmente, em código JavaScript:

Ajustando this quando usado em um método callback

As coisas ficam um pouco cabeludas quando passamos um método (que usa this) como um parâmetro para ser usado como uma função de retorno (callback). Por exemplo:

No código acima, uma vez que o botão ($( 'button' )) é um objeto e se está passando o método user.clickHandler() no clique como um callback, sabe-se que this dentro do método user.clickHandler() não mais se refere ao objeto userthis agora se refere ao objeto em que o método user.clickHandler é executado porque este é definido dentro do método user.clickHandler. E o objeto que invoca user.clickHandler é o objeto de botão — user.clickHandler será executado dentro do método de clique do objeto-botão.

Importante observar que, mesmo que se esteja chamando o método clickHandler() através de user.clickHandler (o que é preciso fazer, já que “clickHandler” é um método definido no “user”), o método clickHandler() será executado com o objeto button como contexto para que “this” agora se refere. Então, this agora se refere ao objeto de botão ($( 'button' )).

Neste ponto, deve ser claro quando o contexto muda — quando se executa um método em algum outro objeto do qual o objeto foi originalmente definido, a palavra-chave this já não se refere ao objeto original, no qual this foi originalmente definido, mas se refere ao objeto que invoca o método onde this foi definido.

Solução para corrigir this quando um método é passado como uma função de callback

Como realmente se quer que this.data faça referência à propriedade de dados no objeto “user”, é possível usar os métodos bind()apply() ou call() para definir especificamente o valor de this.

Ao invés dessa linha:

Deve-se usar bind() para clickHandler, assim:

Ajustando this dentro de um closure

Outro exemplo de quando this é mal compreendido é quando se usa um método interno ou closure. É importante observar que closures não podem acessar a função externa dessa variável usando a palavra-chave this porque essa variável é acessível somente pela própria função e não por funções internas. Por exemplo:

this dentro da função anônima não pode acessar o this da função externa, então ele se refere ao objeto global window (quando o strict mode não está sendo usado).

Solução para manter this dentro de funções anônimas

Para sanar a questão, usa-se uma prática comum em JavaScript: atribuir o valor de this a uma variável antes de entrar no forEach:

É bastante comum na comunidade JavaScript escolher o nome “that” para este tipo de “contorno”, caso em que a atribuição da variável (e posteriores referências) ficariam como:

Ajustando this quando método é atribuído a uma variável

Se se atribui um método que usa this a uma variável, o valor de this quase escapa à imaginação. Como em:

Solução para manter this quando um método é atribuído a uma variável

É possível sanar a questão definindo especificamente o valor de this com o método bind:

Ajustando this em “métodos emprestados”

“Métodos emprestados” é uma prática comum no desenvolvimento em JavaScript. Veja o exame da relevância de this no contexto de métodos emprestados.

this do método avg não se referirá ao objeto gameController; ele se referirá ao objeto appController porque está sendo chamado no appController.

Solução para manter this quando um método é atribuído a uma variável

Para corrigir o problema com a garantia de que o this dentro do método appController.avg() se refere a gameController, usa-se o método apply() assim:

O objeto gameController toma emprestado o método avg() de appControllerthis dentro do método appController.avg() será definido para o objeto gameController porque se passa o objeto gameController como o primeiro parâmetro de apply() — o primeiro parâmetro no método apply() sempre define o valor de this explicitamente.

Palavras finais sobre o this em JavaScript

Como visto, this fica um pouco problemático em situações onde o contexto original muda, especialmente em funções de callback, quando invocado com um objeto diferente ou em métodos emprestados. Lembre-se: this é atribuído ao valor do objeto que invocou a função. Mas, ao terminar de ler este artigo, certamente você aprender e/ou revisou o suficiente sobre this em JavaScript e agora tem as ferramentas e técnicas necessárias para trabalhar nos cenários mais inóspitos.

Até lá, bons códigos e boa sorte!


Ser um generalista não é uma coisa ruim

Já pensou em ser um profissional de web “generalista” ao invés de especialista? Leia este artigo e conheça os prós e contras dessa abordagem na carreira.

Nos últimos anos tem havido um afastamento do profissional web generalista para especialista, como estrategistas de conteúdo, arquitetos de experiência do usuário e codificadores front-end. Onde uma vez havia um único emprego, agora existem muitos, com esferas cada vez mais estreitas de responsabilidade.

Mas enquanto a maioria está se tornando mais especializada, muitos têm rejeitado a abordagem, permanecendo “generalistas” — incluindo a ampliação de seus interesses para áreas como marketing, psicologia, estratégia de negócios e outros. Não surpreendentemente, isso pode atrair críticas negativas de alguns pares que veem os generalistas negativamente.

Por que ser um “generalista” é algo ruim?

Parte da crítica se baseia na complexidade da web. Por exemplo, saber tudo sobre web designjá foi possível, mas agora é irrealista. Mas o fato de que o web design se tornou tão complexo significa que precisamos de generalistas para olhar além dos “silos de especialistas”.

O perigo é que, sem generalistas, os especialistas ficam tão envolvidos em seus silos que lhes é difícil trabalhar com especialistas em outras disciplinas. O generalista é necessário para encorajar a colaboração cruzada e para olhar além dos silos em desenvolvimentos emergentes na web.

Não confunda ser um generalista com não possuir habilidades

A percepção é que os generalistas são comuns e relativamente não-qualificados, porque todos começamos como um quando adentramos no desenvolvimento web. Mas essas pessoas não são verdadeiros generalistas.

Um generalista é alguém que é bem informado a respeito de uma ampla gama de assuntos. Isto não descreve a maioria dos desenvolvedores web — e, certamente, aqueles que estão começando. É importante não confundir ser um generalista com não ser qualificado.

Para facilitar o entendimento dos generalistas em desenvolvimento para web, alguns remetem ao termo “Pau-para-toda-obra”. Mas isso também é problemático, porque pode trazer uma conotação negativa em alguns casos. De qualquer maneira, os generalistas se sentem orgulhosos de suas capacidades de amplo conhecimento em diversas áreas.

Ser um especialista não é a única maneira de conseguir bons trabalhos

Não podemos negar que existe uma “percepção geral” de que a especialização é uma maneira muito melhor de se diferenciar em um mar de generalistas, que muitas vezes leva a empregos melhores — tanto em sentido pecuniário, quanto em satisfação pessoal.

Certamente, especializar-se é uma maneira de se diferenciar, ninguém pode negar este fato. Mas não a única maneira. Pode-se, também, confiar no trabalho de qualidade, no conhecimento de certos setores e até na amplitude da experiência e do conhecimento. Quanto aos especialistas mais qualificados para trabalhar em projetos maiores, isso também não é verdade.

Grandes projetos envolvem grandes equipes, e um generalista é muitas vezes necessário para reunir os diferentes especialistas e fazê-los trabalhar juntos de forma eficaz.

Generalistas também são chamados “passantes”, já que conseguem passar pelas diversas áreas do desenvolvimento web, facilitando a comunicação entre diferentes grupos de profissionais.

Isso significa que devemos todos rejeitar a especialização e nos tornarmos generalistas? De modo nenhum! Mas, em muitas situações, um generalista é necessário.

Você deve ser um generalista?

Como sabemos, não há nada de errado com a especialização. O que se está querendo chamar atenção é que, em certas circunstâncias, ser um generalista tem suas vantagens — e propicia vantagens para muitos profissionais trabalhando juntos num mesmo projeto web.

Aqui estão algumas circunstâncias que vêm à mente:

  • Prosperar na variedade. Generalistas têm mais oportunidades do que outros para explorar novos desenvolvimentos, técnicas e tecnologias. Se você é levado a constantemente aprender coisas e enfrentar novos desafios, então a variedade constante de disciplinas na web pode muito bem lhe servir.
  • Sua equipe de web é pequena. Pequenas equipes em grandes organizações, agências, produtoras etc, precisam de generalistas. Essas equipes exigem que todos façam o que é preciso ser feito, o que, inevitavelmente, exige que você cuide de muitas tarefas.
  • Freelancer. Trabalhar por si próprio muitas vezes exige que você seja Pau-para-toda-obra. A maioria dos clientes vai precisar de você para ajudá-los com tudo o que é relacionado à web. Especializar-se atuando como freelancer é possível, mas, certamente, não é a norma.
  • Pesquisa e Desenvolvimento. Em organizações e agências maiores, alguém precisa manter um olho em tecnologias emergentes. Enquanto especialistas vão fazer isso dentro de seus nichos, tendências inevitavelmente surgirão ao longo do tempo . O generalista será aquele que irá identificar essas novas oportunidades e avaliar quando investir nelas.
  • Você gere seu próprio negócio. Ser um generalista quando se gere o próprio negócio de desenvolvimento web não só permite se manter informado sobre uma variedade de tópicos e vendê-los aos clientes, como ajuda a entender o que as pessoas relacionadas à empresa fazem e se certificar de que as disciplinas funcionam bem em conjunto.

Enquanto alguns de nós devemos nos tornar generalistas por escolhas de carreira ou temperamento, há também boas razões para escolher este caminho em detrimento de outro.

Por que se tornar um generalista?

Os generalistas se sentem orgulhosos de suas capacidades de amplo conhecimento em diversas áreas.

Tornar-se um generalista é, em muitos aspectos, um excelente caminho a se tomar na carreira web. Para começar, ele mantém suas opções abertas: um generalista está sempre procurando novas áreas para explorar e, por isso, está idealmente posicionado para se deslocar para novos campos, como mobile ou HTML5.

Mantenha-se ágil e se adapte às mudanças

O perigo é que, como especialista, você se torna tão obscurecido por sua área de especialização que você não pode detectar novas oportunidades ou, pior ainda, não pode antecipar uma eventual retirada do mercado lenta de seu nicho. Considere aqueles que sabem como programar em nada mais que ColdFusion ou Flash… Essas tecnologias estão completamente mortas? Ainda não, mas os sinais mostram que é questão de tempo.

O potencial para mais trabalho

Ao ser capaz de se adaptar rapidamente a novas circunstâncias, um generalista raramente fica sem trabalho. Além do mais, ele pode criar a maioria dos produtos do início ao fim. Não só muitos generalistas acham isso gratificante, mas também maximiza a lucratividade, já que eles raramente precisam terceirizar. Isso está alinhado com as expectativas do cliente, que, geralmente, é que o fornecedor entregue a maioria de suas necessidades web — claro, pode haver ocasiões em que você precisa recorrer a especialistas.

Mas, antes de você resolver abandonar o caminho de ser um especialista, é justo compartilhar alguns perigos de ser um generalista.

Perigos de ser um generalista

Mais uma vez: o mote não é sugerindo que ser um generalista é certo para todos ou que algo está errado ao se especializar.  Mas ser um verdadeiro generalista não é um mar de rosas.

A luta para mostrar seu valor

Certamente, um dos maiores desafios para ser um generalista é se estabelecer como um expert e se destacar na multidão.

Generalistas muitas vezes são vistos quase como párias dos profissionais de web. Mas a verdade é que verdadeiros generalistas, aqueles com conhecimento extenso a respeito de uma ampla gama de assuntos, são muito raros. Os clientes compreendem que eles têm que pagar mais por habilidades altamente especializadas, mas não reconhecem a necessidade de pagar tanto por um conjunto amplo de habilidades diversas.

Além disso, generalistas raramente são os inovadores — se você é o tipo de pessoa que se importa com essas coisas. Eles não recebem a glória de desenvolver novas técnicas CSS ou estabelecer novos estilos de design. Em vez disso, os generalistas marcham atrás da vanguarda, selecionando os elementos que valem a pena adotar no mainstream.

A corrida constante pelo aprendizado

Generalistas continuamente têm de digerir o conteúdo de uma enorme variedade de fontes e decidir o que é de valor e o que se deve ignorar. Isso é incrivelmente exigente e, não raramente, alguma nova tecnologia ou tendência pode ser “descartada” para somente mais tarde, devido a movimentos vários da indústria, descobrir que vale a atenção.

Um generalista está sempre procurando novas áreas para explorar.

Se você não tem um perfil de ser estudioso/curioso, então ser um generalista certamente não é para você. Um generalista investe muito tempo todos os dias para ler blogs de especialistas que inovam para que possa ficar atualizado — também é preciso assimilar o que é aprendido, o que envolve tentar/testar uma variedade de técnicas.

E, certamente, algumas dessas novas técnicas podem simplesmente estar além das habilidades de um generalista.

Os limites de um generalista

Cair na armadilha de querer experimentar praticamente qualquer coisa que atravessa seu caminho é comum para um generalista. Embora admirável, essa qualidade pode acarretar prejuízo: generalistas podem desperdiçar horas tentando fazer o que um especialista poderia fazer em minutos. Pior ainda, o resultado pode ser não tecnicamente impecável e prejudicial à sua reputação.

Generalistas precisam conhecer seus limites — seja por saber quando chamar um especialista para ajudar ou simplesmente aceitar que eles não podem ser envolvidos em certas tarefas.

Conclusão sobre generalistas na web

É importante que haja um contrapeso ao impulso cada vez maior para a especialização. Mas é mais do que isso. Também é preciso haver um “respeito recém-encontrado” em relação aos generalistas: um reconhecimento de que o desenvolvimento de uma compreensão ampla dos aspectos cada vez mais complexos da web demanda tanta habilidade e esforço como se tornar um especialista em uma área.

Finalmente, este artigo também pode ser considerado um apelo àqueles que se consideram generalistas: levem seu papel a sério! Sejam generalistas verdadeiramente eficazes, que podem oferecer serviços valiosos para seus clientes e colegas e assumir compromisso de forma profissional.

Dessa maneira, certamente generalistas não ficarão carentes de bons trabalhos.


Os melhores bancos de imagens (stock images) grátis

Lista com os melhores bancos de imagens grátis (free stock images) em uma compilação sensacional para usar imagens em qualquer projeto web.

Todos nós já fizemos uma busca por imagens no Google. Mas em função do acordo antipirataria antipirataria com a Getty Imagesa empresa decidiu remover o botão “Ver imagem”. Também pensamos que fosse algum topo de brincadeira de mal gosto, mas é a sério mesmo! Se você fizer uma busca por imagens neste exato momento, já vai notar a falta do amado botãozinho…

A opção de arrastar uma imagem para a barra de busca (“busca reversa”) continua lá — e para os que não descuidaram dos mistérios profundos do clique com o botão direito do mouse, o impacto pode não ser assim tão grande –, mas o grande público, com a ausência da opção, certamente vai começar a visitar muito mais sites do que fazia antes, se é que vocês me entendem.

Fazendo do limão que a Google nos deu uma deliciosa limonada, segue lista dos melhores sites para conseguir imagens grátis para serem usadas — as famosas stock photos. Isso mesmo: os melhores bancos de imagens grátis que podem ser usadas à vontade, imagens sem direitos autorais. E estamos falando de boas imagens, de alta resolução, para serem usadas em qualquer projeto web!

Pexels

Sem dúvida alguma, Pexels é um dos melhores serviços de banco de imagens de graça que existem atualmente. Grande parte das imagens “hero” aqui do desenvolvimento para web são de lá. Dê uma passeada pelos posts para ter uma amostra da qualidade das imagens que o site oferece.

Para virar fã de vez, todas as imagens estão sob a licença Creative Commons Zero (CC0), que, na prática, significa que são de domínio público e é permitido usá-las à vontade, para qualquer fim, com ou sem edição, inclusive comercialmente.

O objetivo do Pexels é oferecer “high quality and completely free stock photos“, quer dizer, fotos de alta qualidade e completamente grátis. Até o momento, estão conseguindo. Com louvor.

Foter

Uma outra excelente opção quando o assunto é banco de imagens gratis é o Foter. Ao oferecer “Premium Royalty-Free Stock Photos“, ele também é uma alternativa de peso que deve ser sempre altamente considerado ao se procurar boas imagens.

Mas qual é o segredo para ser um stock de imagens com mais de 220 milhões de opções? Eles usam a API do Flickr para buscar fotos licenciadas sob Creative Commons!

Fazer uma busca por algum termo do interesse/necessidade ou navegando pelas categorias do Foter, rapidamente você vai comprovar que ele também é uma das melhores opções de banco de imagens disponíveis atualmente.

Pixabay

A primeira coisa que pode ser lida ao entrar no Pixabay é: Imagens gratuitas de alta qualidade. Mas talvez você encontre algo a mais: vídeos! Para entender melhor, não é preciso mais do que as própria explicação que consta no site:

Imagens e vídeos gratuitos que você pode usar em qualquer lugar: Pixabay é uma vibrante comunidade de criativos, compartilhando imagens e vídeos livres de direitos autorais. Todos os conteúdos são lançados no Creative Commons CC0, o que os torna seguros de usar sem pedir permissão ou dar crédito ao artista — mesmo para fins comerciais.

Com quase 1,5 milhão de opções (e crescendo), talvez você se arrependa de não consultar o Pixabay quando estiver procurando por imagens.

Unsplash

Há 3 regras do Unplash que você deve saber:

  1. As imagens são grátis para uso pessoal e comercial;
  2. Nenhuma atribuição é necessária e;
  3. Novas fotos são adicionadas diariamente.

A empresa canadense oferece incontáveis opções de imagens para serem usadas à vontade que podem ser encontradas através de busca, categorias ou coleções próprias, organizadas e disponibilizadas também de maneira gratuita.

Acesse e navegue um pouquinho pela Unsplash para comprovar a qualidade. Realmente não fica devendo nada para qualquer outro serviço de stock image similar.

Visual Hunt

Se você entra em um stock de imagens e quer opções, qual é o número de opções de imagens disponíveis bom o suficiente? Se a resposta é algo em torno de 350 milhões de fotos grátis, então certamente este é o momento de conhecer o Visual Hunt.

High quality free photos in one place“. Esse é o lema do Visual Hunt. Para tanto, eles são uma espécie de agregado de vários stocks de imagens, coletando diversas fotos pela web à fora e as juntando em um só lugar — também usando aquela ajudinha marota da API Flickr.

A maioria das imagens têm licença CC0, são divididas por categorias e tags e a busca é bastante eficiente. Ah, e eles deixam fazer o embed diretamente do site!

StockSnap

Sendo um auto-denominado serviço de curadoria de imagens, a frase que o pessoal da StockSanap gosta de divulgar é: “StockSnap is the best place on the internet to find beautiful free stock photos”, ou, em outras palavras, o melhor banco de imagens grátis da internet. Para saber se é verdade ou não que seja “o melhor”, você mesmo vai ter que entrar para conferir.

Todas as imagens — que podem ser encontradas pela busca, categorias ou uma seção especial de “tendências” — também estão sob Creative Commons Zero. Use sem pudores!

Contribua com os bancos de imagens grátis

Certamente a lista de sites de stock photos apresentados no artigo não pretende ser uma completamente abrangente. Existem literalmente milhares de sites que disponibilizam bancos de imagens e seria uma maluquice querer colocar todos em uma só listagem.

Mas estes são excelentes sites, de renome e reconhecimento mundiais. E sabe como chegaram a este status? A maioria deles permite a contribuição de qualquer um que julgue que suas imagens sem realmente de qualidade e devam ser compartilhadas sem limites com o mundo.

Se você gosta de dar uns cliques e gostaria de ajudar com estes fabulosos serviços de banco de imagens, veja quais desses lhe agradam mais, faça seu login e comece a fazer do mundo das imagens grátis um lugar ainda melhor!


Porque CSS Grid é melhor que Bootstrap para criar layouts

Com o advento de CSS Grid, o framework front-end Bootstrap pode não ser mais tão necessário… Saiba mais sobre os poderes de CSS Grid para layouts.

CSS Grid é uma nova maneira de criar layouts na web. Pela primeira vez, temos um sistema de layout adequado disponível nativamente nos navegadores, o que oferece uma série de benefícios.

Esses benefícios se tornam especialmente claros se você compara CSS Grid com o framework de front-end mais popular: Bootstrap — lembrando que o “mais popular” não necessariamente é o melhor. Não só é possível desenvolver layouts que anteriormente eram impossíveis sem JavaScript, mas o código fica mais fácil de manter e entender.

Marcação mais simples

Trocar Bootstrap por CSS Grid fará do código HTML mais limpo. Embora este não seja o benefício mais importante, é provável que seja o que primeiro se notará.

Para exemplificar, imagine um layout genérico para um site para que seja possível comparar o código necessário. Aqui está:

Um pouco de estilo foi colocado no exemplo, mas isso não tem nada a ver com a comparação entre CSS Grid e Bootstrap, o que servirá de licença para manter essa parte do CSS fora dos exemplos de código.

Bootstrap

Primeiramente, eis a marcação necessária para criar este site com Bootstrap:

Há duas coisas que merecem atenção aqui:

  • Cada linha deve ser sua própria <div>
  • É preciso usar nomes de classes (col-xs-12)
  • À medida que esse layout cresce em complexidade, o mesmo acontece com o HTML

Se se tratasse de um site responsivo, as coisas não seriam melhores:

CSS Grid

Agora, eis a maneira CSS Grid de se fazer (poderiam ter sido usados elementos semânticos aqui, mas optou-se por <div>s para facilitar a comparação com o exemplo usando Bootstrap):

É possível constatar instantaneamente que essa marcação é mais simples! Nada de nomes feios de classes ou <div>s adicionais necessárias para cada linha. É apenas um container para a grid com itens dentro.

E, ao contrário do Bootstrap, essa marcação não aumentará muito em complexidade à medida que o layout cresce em complexidade.

No entanto, enquanto o exemplo Bootstrap não exige que se adicione CSS, o exemplo CSS Grid, claro, exige isso. Especificamente, é preciso adicionar:

Muito mais flexibilidade

Digamos que seja preciso alterar o layout de acordo com o tamanho da tela. Por exemplo, o menu ficar na linha superior quando estiver sendo visualizado em viewports menores. Algo como:

CSS Grid

Fazer isso com CSS Grid é bem simples. Basta simplesmente adicionar uma media query e alterar como os itens se dispõem. No entanto, o que se quer é:

O fato de ser possível reorganizar o layout desta forma, sem se preocupar com a maneira como o HTML está escrito, pode ser chamado de Independência da Ordem no Código (Source-Order Independence), e é uma grande vitória para desenvolvedores e designers!

CSS Grid permite que o HTML seja usado para o que foi criado: marcação de conteúdo, deixando tudo o que é visual para o CSS.

Bootstrap

Comparativamente, se fosse preciso fazer o mesmo com Bootstrap, seria preciso mudar o HTML… Teria-se que mover a tag do menu para a linha superior, além do cabeçalho, pois o menu está “preso” na segunda linha.

Fazer isso com base em uma media query não é algo trivial. Não pode ser feito usando apenas HTML e CSS; seria preciso começar a mexer com JavaScript.

Sem sombra de dúvidas, este exemplo ilustra um dos maiores benefícios ao se trabalhar com CSS Grid.

Sem limitação de 12 colunas

Este não é um problema tão grande, mas que é no mínimo irritante. Como a grid de Bootstrap é dividida em 12 colunas (por padrão), pode ser que haja problemas em situações que exijam, por exemplo, um layout de 5 colunas. Ou 7. Ou 9.

Com CSS Grid, este não é o caso. É possível fazer uma grid com exatamente a quantidade necessária de colunas. Aqui está um exemplo de uma grid de 7 colunas:

Isso é feito configurando grid-template-columns para repeat(7, 1fr), tal como:

Lembrando que Bootstrap 4 usa Flexbox, o que torna isso possível também — mas não era até então.

Suporte atual de navegadores a CSS Grid

Falando sobre o suporte de navegades a CSS Grid, no momento da publicação deste artigo ele está em 87,56% — no Brasil sendo até um pouco maior, chegando a 90%.

Morten Rand-Eriksen mostra que CSS Grid é uma oportunidade para refletir a maneira como se pensa sobre a compatibilidade com versões anteriores:

CSS Grid é um módulo de layout (layout module); permite alterar o layout de um documento sem interferir com sua ordem (Source-Order Independence). Em outras palavras, a CSS Grid é uma ferramenta puramente visual e, usada corretamente, não deve afetar a comunicação dos conteúdos no documento. A partir disso, segue uma verdade simples, mas surpreendente: a falta de suporte a CSS Grid em um navegador antigo não deve afetar a experiência do visitante, mas torná-la diferente.

Em outras palavras, uma vez que você se tenha separado o conteúdo do visual, o resultado é que o conteúdo será servido a todos os visitantes. No entanto, CSS Grid irá melhorar a experiência de todos aqueles que receberam suporte para isso através de um layout melhor.

Conclusão

Por fim, cabe uma citação de Jen Simmons, “developer advocate” na Mozilla. Ela descreve bem o sentimento da maioria dos desenvolvedores ao conhecer CSS Grid:

Quanto mais eu uso CSS Grid, mais convencida fico de que não há nenhum benefício a ser obtido em adicionar qualquer camada de abstração. CSS Grid é a estrutura de layout. Diretamente no navegador.


Página 1 de 812345...Última »