A evolução do Google e de sua marca

O Google evoluiu, e muito com o tempo. E neste tempo também aprendemos a ‘evolui-lo’. A internet se tornou algo gigantesco nestes últimos 20 anos, e se tem uma empresa e uma marca que pode ser considerada como pioneira, inovadora e pivô de tudo isso é o Google.

Tive grande resistência a usar este buscador no começo. Eu era mais simpático ao Cadê, e até ao Yahoo. Mas, com as vindas do Gmail, Orkut, Youtube, tive que ceder.

Hoje o Google lança sua nova marca, novamente remodelada, em um vídeo que mostra como não apenas a marca em si evoluiu, mas os conceitos e os produtos como um todo.

Não gosto de monopólio, gosto da ampla concorrência. Mas, quem conseguir inovar e fazer a diferença, sempre alcançará um degrau a mais que os demais. Isso é fato, isso é mérito. Isso é o mundo em que vivemos.

Anúncios

Google traz o Material Design Lite com CSS, HTML e JavaScript

O Material Design Lite (MDL) do Google permite adicionar o look and feel do Material Design em websites. O Material Design é a linguagem visual padrão para Android e que, agora, o Google propõe como multiplataforma.

De acordo com o Google, o MDL têm os requisitos para que seja caracterizado como “lite”:

  • Tem poucas dependências de forma que é fácil de instalar e usar;
  • Não depende de frameworks, permitindo que os desenvolvedores façam sua integração com qualquer cadeia disponível de ferramentas para front-end;
  • Sua base de código é relativamente pequena;
  • Têm foco restrito, implementando as boas práticas do material design e não é um framework abrangente.

O MDL não é a primeira implementação de HTML/CSS/JS do material design e existem alternativas como o Materialize e Material Bootstrap. A principal vantagem que o MDL trás em relação a estas opções desenvolvidas pela comunidade, de acordo com o Google, é que o MDL foi desenvolvido “com a colaboração das equipes de Material Design e Chrome UX e é constantemente revisado buscando aderência às especificações do material design”.

Antes do MDL, o Polymer era a implementação canônica de material design para CSS/JS. Porém, comparado ao MDL, o Polymer tem escopo maior e vai além do domínio visual, incluindo componentes para comunicação de dados e componentes não especificados pelo material design.

Até o presente momento, o MDL não é otimizado nem suporta o uso de componentes individuais, por exemplo, um botão. Ainda sim, para desenvolvedores que querem usar apenas uma parte dos componentes MDL, é possível criar uma distribuição MDL customizada comentando componentes indesejados do material-design-lite.css e scripts inadequados do Gulpfile. Feito isso, basta executar gulp.

O MDL segue a convenção BEM de forma que os nomes para cada classe css são consistentes, isolados e expressivos. O Google detalha quais boas práticas eles seguiram ao aplicar BEM no desenvolvimento do MDL. Por outro lado, o BEM pode levar a explosão no comprimento dos nomes de classes e, de acordo com o feedback inicial, o MDL parece ser sensível a esse problema, por exemplo, ao necessitar de dezessete nomes de classe diferente para um simples card que é um conceito básico do material design.

O Google afirma que o MDL funciona em todos os navegadores modernos (Chrome, Firefox, Opera, Microsoft Edge e Safari) com degradação suave em navegadores como o IE9. Também sugerem referenciar a CDN para incluir o MDL no website, mas também é possível baixar ou importá-lo via npm ou Bower.

Fonte: InfoQ Brasil

WebAssembly: um formato universal para binário e texto

A Mozilla, a Google, a Microsoft e a Apple decidiram desenvolver um formato binário para a web. Chamado de WebAssembly, este formato pode ser o resultado compilado de qualquer outra linguagem, assim permitindo que aplicações executem no navegador ou em qualquer outro agente.

Alguns anos atrás, foi discutido no InfoQ.com quais as vantagens de haver um bytecode universal para a web (Veja o Debate: Precisamos de um Bytecode Universal para a Web?), exaltando as dificuldades em criar uma. O principal problema mencionado era o desentendimento entre os principais fornecedores de navegadores: A Mozilla empurrava asm.js, a Google estava atrás do PNaCl, a Apple estava trabalhando em FLTJIT, enquanto a Microsoft não mostrou interesse em qualquer um deles. Mas isso mudou, todos os quatro principais fornecedores de navegadores chegaram a um acordo sobre a criação do WebAssembly ou WASM/wasm, um formato binário para a web. Alguns chamam isso de bytecode, mas wasm não é um bytecode no sentido tradicional, como Brendan Eich observou:

“WebAssembly é de fato uma codificação AST após um processo de compressão, não uma pilha bytecode, mas pode ainda chamar de bytecode se preferir”.

O projeto estava em modo cauteloso até o momento, mas agora foi tornado público com presença no GitHub e um grupo na comunidade W3C. WebAssembly permite que os programas escritos em outras linguagens (e não somente JavaScript) possam executar no navegador ou em qualquer outro agente de JS, como no servidor, em dispositivo móvel ou loT. Este formato irá eventualmente substituir o asm.js e PNaCl. De acordo com o documento de projeto, que ainda não é definitivo, o WASM usa um binário porque “proporciona eficência: e reduz o tamanho do download e acelera a decodificação, permitindo até mesmo grandes bases de código tenham tempo de inicialização rápida”. O WASM tem um formato de texto que o acompanha que pode ser utilizado por depuradores e outas ferramentas do desenvolvedor. As Ferramentas devem ser capaz de traduzir a partir de um formato para o outro, sem qualquer perda de informação.

Um primeiro passo temporário na implementação do WebAssembly foi feito: traduzindo o formato em código correspondente asm.js, por isso já pode ser executado em navegadores que suportam: Firefox, Edge e Chrome. Já existe também um polyfill prototype criado para esta finalidade, e os resultados iniciais mostram que o formato binário gzipped é 20-30% menor do que o correspondente gzipped asm.js, e que decodificação wasm é 23 vezes mais rápida do que a análise do código fonte correspondente no asm.js. O WASM será posteriormente suportado pelas VMs dos navegadores.

WebAssembly vai trazer primeiro programas C/C++ para a web, no entanto, mais tarde pode ser aprimorado para suportar qualquer outra linguagem. Um backend em LLVM e um port do clang são planejados. O WASM executará no “mesmo universo semântico como JavaScript”, apoiará chamadas assíncronas para/de JavaScript, permitindo acessar toda as APIs do navegador e obedecer a mesma política de segurança que estão sujeitos os programas atuais implementados em JavaScript. Uma aplicação de cliente pode ser escrito completamente em WASM ou poderia ter o código de negócios no WASM e a UI em HTML/CSS/JavaScript.

Anunciado no aniversário de 20 anos do JavaScript e no mesmo dia que a Ecma anuncionou a versão finalES6, o WebAssembly não é boa notícia para JavaScript: o WASM fará com que seja possível codificar para a web em qualquer linguagem que irá compilar. JavaScript irá competir diretamente com outras linguagens. Devemos esperar para ver Java ou C# compilado para WASM?

WebAssembly se beneficiará de lições aprendidas em desenvolvimento asm.js e PNaCl, uma vez que as respectivas equipes de Mozilla e Google estão envolvidos na sua criação. Tendo a Microsoft e Apple apoiando é muito promissor para o projeto. O único problema é o tempo: geralmente projetos desenvolvidos por várias grandes corporações consome muito tempo. O processo de padronização é lento na maioria do casos.

Post original por InfoQ Brasil