O hype
Se você está trabalhando com desenvolvimento web / mobile / UI / UX e não tem morado debaixo de uma rocha nos últimos dois anos, provavelmente já ouviu falar de Web Components e Polymer.
A frase de marketing diz “Os componentes da Web inauguram uma nova era de desenvolvimento da Web com base em elementos personalizados encapsulados e interoperáveis que estendem o próprio HTML”; muitas pessoas estão genuinamente entusiasmadas com um conceito que promete desafiar profundamente e mudar a maneira como escrevemos aplicativos para web e móveis.
jQuery e toda uma infinidade de frameworks de desenvolvimento web construídos sobre ele de repente parecem sair de moda e se tornar obsoletos agora. Mesmo o futuro do Angular e do React é questionado por alguns, já que os elementos centrais do Polymer se sobrepõem a parte da funcionalidade já implementada por esses frameworks. Por outro lado, li inúmeros artigos e vi algumas apresentações mostrando como você pode integrar o Polymer em seu projeto Backbone / Marionette / React / Whatever.js existente / em andamento.
Verificação da realidade
Bem, deixando a história de marketing de lado, vamos tentar olhar além do hype. Não vou entrar em detalhes técnicos (geralmente é aí que está o diabo), mas as especificações do Web Component certamente já existem há algum tempo e, embora todos concordem que precisamos desesperadamente de uma maneira melhor de lidar com os problemas. Com relação ao endereçamento, os principais navegadores não têm sido exatamente rápidos em fornecer o suporte nativo. No momento, o Chrome parece ser o único a oferecer uma implementação completa , os caras da Mozilla ainda estão debatendo se devem suportar importações de HTML ou não, enquanto os caras da Microsoft estão, como sempre, completamente fora do circuito (não, aparentemente eles também não o farão em espartano ).
Algumas pessoas disseram “sem problemas, podemos polyfill os outros navegadores” (em inglês simples, polyfill significa compensar os recursos ausentes fornecendo implementações de JavaScript não nativas escritas em JavaScript). E assim nasceram X-Tag , Bosonic e Polymer . Entre eles, Polymer parece ser a virada de jogo para ficar de olho, por uma série de razões, a mais notável porque parece fantástica e funciona muito bem (no Chrome), especialmente desde a adição de elementos de papel de design de material .
Então, qual é o problema se os outros navegadores contemporâneos são polyfilled ?
Podemos usar Polymer hoje, certo?
Bem, talvez … mas certifique-se de verificar e verificar tudo novamente. Por um motivo, polyfills são ótimos, mas o desempenho é um dos problemas aos quais você deve prestar atenção especial. Não confie no hype, decida por si mesmo. Reserve um tempo para estudar esses exemplos em vários navegadores, sistemas operacionais e dispositivos e certifique-se de ficar de olho no console do desenvolvedor para ver o que acontece nos bastidores.
Podemos integrar o Polymer em nossos aplicativos baseados em Backbone + Marionette / Angular / React, não podemos?
Tecnicamente falando, sim, você pode. Mas isso não significa que você deva. Às vezes, começar da tabula rasa é apenas melhor. Deixe-me dar a você apenas um motivo (que deve pertencer ao bom senso) que muitas vezes os desenvolvedores entusiasmados com uma nova tecnologia optam por ignorar:
- jQuery: 82 KB (ou Zepto: 24 KB)
- Underscore.js: 15 KB
- Backbone.js: 20 KB
- Marionette.js: 39 KB
- WebCompoments.js: 103 KB
E provavelmente seu aplicativo exigirá muito mais, já que você provavelmente está usando um controle deslizante amigável, Google Maps, etc … e talvez Twitter Bootstrap. E alguns deles também vêm com muito código CSS (por sinal, o CSS também é executado e, às vezes, a execução pode ser cara ).
Como uma observação lateral, uma parte importante desse código inevitavelmente fornece funcionalidade duplicada / obsoleta.
Tudo isso soma centenas de KB de código JavaScript / CSS altamente compactado que o navegador precisa baixar, entender e executar, sem nem mesmo considerar a carga útil real do aplicativo. E esse é um caso otimista porque Backbone.js + Marionette.js é uma estrutura enxuta para a funcionalidade que fornece.
Tudo isso pode não parecer muito hoje em dia, mas nem todo mundo tem um plano de dados 4G ilimitado e o smartphone carro-chefe mais recente. Desenvolvedores e pessoas que entendem de tecnologia geralmente o fazem, a maioria das pessoas normais não :-). O que significa que eles terão apenas a experiência de UX polyfilled e menos do que a ideal.
Já vi muitos projetos web / móveis promissores terminando terrivelmente errados por causa da confusão de códigos UX . Às vezes, os desenvolvedores sem experiência real na web apenas “jogam um modelo ThemeForest ou skin no topo” de um aplicativo empresarial, às vezes eles se acostumam a trabalhar no iMac ou MacBook Pro mais recente que simplesmente esquecem que há pessoas lá fora usando laptops Windows ou telefones Android baratos.
Portanto, o ponto principal é este: se você for corajoso o suficiente para adotar o Polymer hoje, talvez deva considerar não misturá-lo com a base de código “legada” baseada em jQuery. Nem sempre são complementares e o mix certamente apresentará um custo, além dos benefícios.
Estou escrevendo código em CofeeScript / TypeScript, LESS / Stylus e Jade / HAML template engine, e empacoto tudo com o Browserify. Posso “inserir” o Polymer em meu fluxo de trabalho?
Bem, bom pra você. Você provavelmente é adepto da concisão e da simplicidade, como eu :-).
A má notícia é que você não pode integrar facilmente o Polymer em seu fluxo de trabalho – e novamente, talvez não devesse. Entre outras coisas, CoffeeScript (que eu uso constantemente e adoro, aliás) pareceu compensar algumas das carências do JavaScript pré-ES6 / 7, e alguns deles agora são polyfilled por webcomponents.js; O Polymer foi feito com o Bower em mente e vem com uma ferramenta de empacotamento específica chamada vulcanize (uma decisão às vezes criticada por membros da comunidade JS).
Se você está construindo um projeto baseado em polímero, não há razão real para adicionar browserify à mistura, exceto para mostrar que é possível.
Sou viciado em LiveReload; desde que o descobri, simplesmente não consigo trabalhar sem ele. Funciona com WebComponents / Polymer, certo?
Para pessoas que (ainda?) Não ouviram falar sobre isso, LiveReload é uma ferramenta / conjunto de ferramentasisso traz um enorme aumento na produtividade do desenvolvedor, recarregando automaticamente os ativos da web conforme eles mudam (imagens, fontes, folhas de estilo, scripts), sem recarregar a página inteira. Embora isso possa parecer um pouco à primeira vista, é realmente inestimável: considere que você está trabalhando em um aplicativo dinâmico dependente do contexto e, durante o processo de desenvolvimento, precisa fazer alguns ajustes visuais modificando algumas folhas de estilo. Sem o LiveReload, você teria que clicar em “atualizar”, o que não é grande coisa … mas e se demorar alguns minutos para chegar ao mesmo ponto no fluxo de trabalho do aplicativo? Além disso, se o lado do servidor for .NET, reiniciar o processo de depuração no Visual Studio leva uma eternidade.
A má notícia é que o LiveReload não funciona bem com o Polymer . Fiquei bastante desapontado ao descobrir isso, mas não acontece. Atualizar um elemento irá disparar um recarregamento completo da página , enquanto modificar uma folha de estilo vinculada não irá disparar um recarregamento . O que acaba com o propósito do LiveReload.
“Mas eu vi um tutorial sobre como configurar um aplicativo Polymer e eles mencionaram LiveReload” , você pode dizer. Sim, as pessoas demonstraram cenários de ferramentas front-end para o Polymer, mas aparentemente o propósito era principalmente “acadêmico” e eles não se preocuparam muito com o assunto de como o LiveReload realmente funciona …
Não acredite apenas na minha palavra, vá em frente, experimente você mesmo.
Então, devo usar WebComponents & Polymer hoje?
Não estou dizendo que você não deveria. Pelo contrário. Precisamos fazer as coisas avançar; precisamos de uma web melhor, precisamos desesperadamente de ferramentas melhores para construí-la e o Polymer definitivamente tem o potencial para ser uma ferramenta melhor. Mas não deixe sua empolgação, o hype do marketing ou o burburinho do dia-a-dia da tecnologia atrapalhar seu julgamento. Tome uma decisão informada e não espere uma bala de prata.
Pessoalmente, depois de duas semanas estudando e brincando, ainda tenho sentimentos confusos sobre isso.
Não tenho certeza se usaria para um site público com um público amplo e não conhecedor de tecnologia.
Mas parece uma aposta segura para construir um aplicativo empacotado com PhoneGap para dispositivos Android …
Pensamentos finais
Tudo o que escrevi acima é apenas uma opinião pessoal sobre o estado prático das coisas hoje , 17 de fevereiro de 2015, pois estou avaliando a Polymer como uma alternativa para um projeto pessoal. Mas a tecnologia está mudando e evoluindo constantemente, então certifique-se de tirar suas próprias conclusões.
Este artigo foi publicado inicialmente no LinkedIn aqui em 17 de fevereiro de 2015.