Um olhar abrangente no front-end em 2018

Kaelan Cooter Blocked Unblock Seguir Seguindo 28 de dezembro de 2018

Pegue um café, acomode-se e leia devagar. Nosso comentário não falta muito.

O desenvolvimento para a Web sempre foi um campo em rápida evolução – dificultando o acompanhamento de todas as mudanças no navegador, lançamentos de bibliotecas e novas tendências de programação que podem inundar sua mente ao longo do ano.

A indústria está crescendo a cada ano, tornando mais difícil para o desenvolvedor médio manter-se. Então, vamos dar um passo atrás e rever o que mudou na comunidade de desenvolvimento web em 2018.

Nós testemunhamos uma evolução explosiva do Javascript nos últimos anos. À medida que a Internet se tornou ainda mais importante para a economia global, poderosas partes interessadas comerciais, como o Google e a Microsoft, perceberam que precisavam de ferramentas melhores para criar a próxima geração de aplicativos da web.

Isto levou à maior onda de mudanças para o Javascript desde o seu início, começando com o ECMAScript 2015 (também conhecido como ES6). Agora existem lançamentos anuais que nos trouxeram novos recursos interessantes como classes, geradores, iteradores, promessas, um sistema de módulos completamente novo e muito mais.

Isso lançou uma era de ouro do desenvolvimento web. Muitas das ferramentas, bibliotecas e frameworks mais populares hoje se tornaram populares logo após o lançamento do ES2015. Mesmo antes dos principais fornecedores de navegadores suportarem até metade do novo padrão, o projeto do compilador Babel permitiu que milhares de desenvolvedores tivessem uma vantagem inicial e experimentassem os novos recursos.

Os desenvolvedores de front-end, pela primeira vez, não estavam comprometidos com o navegador mais antigo que sua empresa suporta, mas eram livres para inovar em seu próprio ritmo. Três anos e três edições ECMAScript mais tarde, esta nova era de desenvolvimento web não mostra sinais de abrandamento.

Novos recursos de linguagem JS

Em comparação com edições anteriores, o ECMAScript 2018 foi bastante leve em termos de recursos, adicionando somente propriedades de descanso / dispersão de objeto , iteração assíncrona e Promise . Por fim , todos os quais foram suportados por Babel e core-js por um tempo agora. A maioria dos navegadores e Node.js são todos do ES2018, exceto o Edge, que suporta apenas o Promise. Para muitos desenvolvedores, isso significa que todos os recursos de idiomas que eles precisam são suportados em todos os navegadores que eles suportam – alguns se perguntam se o Babel é realmente mais necessário.

Novos recursos de expressão regular

O Javascript sempre tem faltado alguns dos recursos de expressão regular mais avançados que outras linguagens como o Python têm – ou seja, até agora. O ES2018 adiciona quatro novos recursos:

  • Lookbehind assertions , fornecendo o complemento que faltava para as afirmações antecipadas que estiveram na linguagem desde o caminho de volta em 1999.
  • s (dotAll) flag , que corresponde a qualquer caractere único, exceto terminadores de linha.
  • Grupos de captura nomeados , que facilitam o uso de expressões regulares, permitindo a pesquisa baseada em propriedade para grupos de captura.
  • Escape da propriedade Unicode , que possibilita escrever expressões regulares que estão cientes do unicode.

Embora muitos desses recursos tenham soluções alternativas e bibliotecas alternativas há anos, nenhum deles poderia corresponder à velocidade que as implementações nativas fornecem.

Novos recursos do navegador

Houve uma incrível quantidade de novas APIs de navegadores JavaScript lançadas este ano. Quase tudo melhorou – segurança na Web, computação de alto desempenho e animações, para citar alguns. Vamos dividi-los por domínio para ter uma ideia melhor do impacto deles.

WebAssembly

Embora o suporte ao WebAssembly v1 tenha sido adicionado aos principais navegadores no ano passado, ele ainda não foi amplamente adotado pela comunidade de desenvolvedores. O WebAssembly Group possui um roteiro de recursos ambicioso para recursos como coleta de lixo , integração de módulos ECMAScript e encadeamentos . Talvez com esses recursos, começaremos a ver uma adoção generalizada em aplicativos da web.

Parte do problema é que o WebAssembly requer muita configuração para iniciar e muitos desenvolvedores que usam JavaScript não estão acostumados a trabalhar com linguagens compiladas tradicionais. O Firefox lançou um IDE on-line chamado WebAssembly Studio, que facilita o acesso ao WebAssembly. Se você deseja integrá-lo em um aplicativo existente, agora há muitas ferramentas para escolher. O Webpack v4 adicionou suporte embutido experimental para módulos WebAssembly fortemente integrados aos sistemas de compilação e módulo e com suporte ao mapa de origem.

A ferrugem surgiu como uma linguagem favorita para compilar no WebAssembly. Ele oferece um ecossistema robusto de pacotes com carga , desempenho confiável e uma sintaxe fácil de aprender . Já existe um ecossistema emergente de ferramentas que integram o Rust com Javascript. Você pode publicar pacotes do Rust WebAssembly no NPM usando o wasm-pack . Se você usa o Webpack, agora pode integrar perfeitamente o código Rust em seu aplicativo usando o rust-native-wasm-loader .

Se preferir não abandonar o Javascript para usar o WebAssembly, você está com sorte – agora há várias opções para escolher. Se você estiver familiarizado com o Typescript, há o projeto AssemblyScript que usa o compilador oficial do Binaryen juntamente com o Typescript.

Portanto, ele funciona bem com as ferramentas existentes de Datilografe e WebAssembly. Walt é outro compilador que adere à sintaxe Javascript (com dicas do tipo tipo Datilografado) e compila diretamente para o formato de texto WebAssembly. Tem zero dependências, tempos de compilação muito rápidos e integração com o Webpack. Ambos os projetos estão em desenvolvimento ativo e, dependendo de seus padrões, podem não ser considerados “prontos para produção”. Independentemente disso, eles valem a pena conferir.

Memoria compartilhada

Os aplicativos JavaScript modernos geralmente fazem cálculos pesados em Web Workers para evitar o bloqueio do thread principal e interromper a experiência de navegação. Embora os trabalhadores estejam disponíveis há vários anos, suas limitações impediram sua adoção mais ampla. Os trabalhadores podem transferir dados entre outros segmentos usando o método postMessage , que clona os dados enviados (mais lentos) ou usa objetos transferíveis (mais rápido). Assim, a comunicação entre threads é lenta ou unidirecional. Para aplicativos simples, isso é bom, mas impediu a construção de arquiteturas mais complexas usando os trabalhadores.

SharedArrayBuffer e Atomics são novos recursos que permitem que aplicativos JavaScript compartilhem um buffer de memória fixa entre contextos e executem operações atômicas neles. No entanto, o suporte ao navegador foi temporariamente removido depois que foi descoberto que a memória compartilhada torna os navegadores vulneráveis a um ataque de temporização conhecido anteriormente como Specter . O Chrome reativou o SharedArrayBuffers em julho, quando lançaram um novo recurso de segurança que mitigou a vulnerabilidade. No Firefox, ele é desativado por padrão, mas pode ser reativado . O Edge removeu o suporte completamente e a Microsoft não indicou quando ele será reativado. Espero que, no próximo ano, todos os navegadores tenham estratégias de mitigação para que esse recurso crítico em falta possa ser usado.

Tela de pintura

APIs gráficas, como Canvas e WebGL, são suportadas há vários anos, mas sempre foram limitadas à renderização apenas no thread principal. A renderização pode, portanto, ser bloqueada. E isso leva a más experiências do usuário. A API OffscreenCanvas resolve esse problema permitindo que você transfira o controle de um contexto de tela (2D ou WebGL) para um trabalhador da Web. O trabalhador pode então usar as APIs do Canvas como normal, enquanto renderiza sem problemas no encadeamento principal sem bloquear.

Dada a significativa economia de desempenho, você pode esperar que bibliotecas de gráficos e desenhos procurem apoiá-lo em breve. O suporte do navegador agora está limitado ao Chrome, o Firefox o suporta atrás de uma bandeira e a equipe do Edge não fez nenhuma indicação pública de suporte. Você pode esperá-lo emparelhar bem com SharedArrayBuffers e WebAssembly, permitindo que um Worker seja renderizado com base nos dados existentes em qualquer thread, a partir do código escrito em qualquer idioma, tudo sem uma experiência de usuário janky. Isso pode tornar realidade o sonho de jogos de ponta na web e permitir gráficos ainda mais complexos em aplicativos da web.

Há um grande esforço em andamento para trazer novas APIs de layout e desenho para o CSS. O objetivo é expor partes do mecanismo CSS aos desenvolvedores da Web para desmistificar algumas das “magias” do CSS. A CSS Houdini Task Force da W3C, formada por engenheiros dos principais fornecedores de navegadores, tem trabalhado arduamente nos últimos dois anos publicando várias especificações preliminares que estão agora nos estágios finais do projeto.

A CSS Paint API está entre as primeiras a chegar aos navegadores, chegando ao Chrome 65 em janeiro. Ele permite que os desenvolvedores criem uma imagem usando uma API semelhante ao contexto, que pode ser usada sempre que uma imagem for solicitada no CSS. Ele usa a nova interface do Worklet , que são basicamente construções do tipo Worker , leves e de alto desempenho destinadas a tarefas especializadas. Como Trabalhadores, eles são executados em seu próprio contexto de execução, mas, diferentemente de Workers, eles são independentes de thread (o navegador escolhe em qual encadeamento eles são executados) e eles têm acesso ao mecanismo de renderização.

Com um Worklet Paint, você pode criar uma imagem de fundo que é redesenhada automaticamente quando o elemento está contido nas alterações. Usando as propriedades do CSS, você pode adicionar parâmetros que acionam o re-desenho quando alterados e podem ser controlados via Javascript. Todos os navegadores, exceto o Edge, prometeram suporte, mas, por enquanto, há um polyfill . Com essa API, começaremos a ver as imagens componentizadas usadas de maneira semelhante à que vemos agora nos componentes.

Animações

A maioria dos aplicativos da web modernos usa animações como parte essencial da experiência do usuário. Estruturas como o Material Design do Google as tornaram partes essenciais de sua linguagem de design , argumentando que elas são essenciais para tornar experiências de usuário expressivas e fáceis de entender. Dada a sua importância elevada, tem havido um impulso recentemente para trazer uma API de animações mais poderosa para JavaScript, e isso resultou na API de animação da Web (WAAPI).

Como observa o CSS-Tricks , o WAAPI oferece uma experiência de desenvolvimento significativamente melhor do que apenas as animações CSS, e você pode facilmente registrar e manipular o estado de uma animação definida em JS ou CSS. O suporte a navegadores no momento é limitado principalmente ao Chrome e ao Firefox, mas há um polyfill oficial que faz tudo o que você precisa.

O desempenho sempre foi um problema com as animações da Web, e isso foi resolvido com a introdução do Worklet de animação . Essa nova API permite que animações complexas sejam executadas em paralelo – o que significa animações de taxa de quadros mais altas que não são afetadas pelo thread principal jank. Os Worklets de animação seguem a mesma interface da API do Web Animations, mas dentro do contexto de execução do Worklet.

Ele deve ser lançado no Chrome 71 (a próxima versão a partir do momento da gravação) e em outros navegadores provavelmente no próximo ano. Há um repositório oficial e exemplo de repositório disponível no GitHub se você quiser testá-lo hoje.

Segurança

O ataque de cronometragem do Specter não foi o único susto de segurança da Web do ano. A vulnerabilidade inerente do NPM foi escrita muito no passado e, no mês passado, recebemos um lembrete alarmante . Esta não foi uma violação de segurança do próprio NPM, mas um único pacote chamado fluxo de eventos que é usado por muitos pacotes populares. O NPM permite que os autores de pacotes transfiram a propriedade para qualquer outro membro, e o hacker convenceu o proprietário a transferi-lo para eles. O hacker então publicou uma nova versão com uma nova dependência de um pacote que eles criaram chamado flatmap-stream , que tinha código projetado para roubar carteiras bitcoin se o pacote malicioso fosse instalado junto com o pacote copay-dash .

Esses tipos de ataques só se tornarão mais comuns, considerando-se o modo como o NPM funciona e a propensão para as comunidades de instalar pacotes aleatórios de NPM que pareçam úteis. A comunidade deposita muita confiança nos donos de pacotes, confiança que tem sido questionada grandemente. Os usuários do NPM devem saber de cada pacote que estão instalando (dependências de dependências incluídas), usar um arquivo de bloqueio para bloquear versões e se inscrever em alertas de segurança como os fornecidos pelo Github .

A NPM está ciente das preocupações de segurança da comunidade e tomou medidas para melhorá-la no último ano. Agora você pode proteger sua conta NPM com autenticação de dois fatores , e o NPM v6 agora inclui um comando de auditoria de segurança .

Monitoramento

A Reporting API é um novo padrão que visa facilitar aos desenvolvedores a descoberta de problemas com seus aplicativos, alertando quando os problemas ocorrem. Se você usou o console do Chrome DevTools nos últimos anos, talvez tenha visto as mensagens de aviso de [intervenção] para usar APIs obsoletas ou fazer coisas potencialmente inseguras. Essas mensagens foram limitadas ao cliente, mas agora você pode relatá-las às ferramentas de análise usando o novo ReportingObserver .

Existem dois tipos de relatórios:

  • Deprecações , que avisam quando você está usando uma API obsoleta e informa quando ela deve ser removida. Ele também informará o nome do arquivo e o número da linha de onde ele foi usado.
  • Intervenções , que avisam quando você está usando uma API de maneira não intencional, perigosa ou insegura.

Enquanto ferramentas como LogRocket fornecem aos desenvolvedores insights sobre erros em seus aplicativos. Até agora, não havia nenhuma maneira confiável de ferramentas de terceiros registrarem esses avisos. Isso significa que os problemas passam despercebidos ou se manifestam como mensagens de erro difíceis de depurar. No momento, o Google Chrome suporta a API ReportingObserver, e outros navegadores o apoiarão em breve.

CSS

Embora o Javascript tenha recebido toda a atenção, houve vários novos recursos CSS interessantes que chegaram aos navegadores este ano.

Para quem não sabe, não existe uma especificação CSS3 unificada análoga ao ECMAScript. O último padrão unificado oficial foi o CSS2.1, e o CSS3 passou a se referir a qualquer coisa publicada depois disso. Em vez disso, cada seção é padronizada separadamente como um "Módulo CSS". O MDN tem uma excelente visão geral de cada padrão de módulo e seu status.

A partir de 2018, alguns recursos mais recentes agora são totalmente suportados em todos os principais navegadores (isso é 2018, o IE não é um navegador principal). Isso inclui flexbox , propriedades personalizadas (variáveis) e layout de grade .

Embora tenha havido conversas no passado de adicionar suporte a regras aninhadas em CSS (como LESS e SASS), essas propostas não foram a lugar algum. Em julho, o grupo de trabalho CSS do W3C decidiu dar outra olhada na proposta, mas não está claro se é uma prioridade.

Node.js

O Node continua a fazer excelentes progressos, mantendo-se em conformidade com os padrões ECMAScript e, a partir de dezembro, eles suportam todo o ES2018 . Por outro lado, eles têm sido lentos em adotar o sistema de módulos ECMAScript e, portanto, estão faltando um recurso crítico que está impedindo a paridade de recursos com navegadores, que suportam módulos ES por mais de um ano. O nó realmente adicionou o suporte experimental na versão 1.1.4.0 por trás de um sinalizador, mas isso requer que os arquivos usem a nova extensão .mjs, levando a preocupações sobre a adoção lenta e o impacto que isso teria no ecossistema de pacotes avançados do Node.

Se você quer dar um salto e preferir não usar o suporte experimental experimental, existe um projeto interessante do criador do Lodash, chamado esm, que dá ao módulo Node ES suporte com melhor interoperabilidade e desempenho do que a solução oficial. .

Ferramentas e Frameworks

Reagir

React teve dois lançamentos notáveis este ano. O React 16.3 é fornecido com suporte para um novo conjunto de métodos de ciclo de vida e uma nova API de Contexto oficial. O React 16.6 adicionou um novo recurso chamado “Suspense” que dá ao React a capacidade de suspender a renderização enquanto os componentes esperam que uma tarefa seja concluída, como busca de dados ou divisão de código .

O tópico mais discutido sobre o React deste ano foi a introdução do React Hooks . A proposta foi projetada para facilitar a gravação de componentes menores sem sacrificar recursos úteis que até agora estavam limitados a componentes de classe. O React será fornecido com dois ganchos integrados, o Gancho do Estado, que permite que os componentes funcionais usem o estado, e o Gancho do Efeito , que permite realizar efeitos colaterais nos componentes da função. Embora não haja planos para remover classes do React, a equipe do React claramente pretende que os Ganchs sejam centrais no futuro do React. Depois que eles foram anunciados, houve uma reação positiva da comunidade ( alguns podem dizer overhyped ). Se você estiver interessado em aprender mais, confira a visão abrangente do post do blog de Dan Abramov .

No ano que vem, a React planeja lançar um novo recurso chamado Concurrent Mode (anteriormente conhecido como “async mode” ou “async rendering”). Isso permitiria que o React processasse árvores de componentes grandes sem bloquear o encadeamento principal. Para aplicativos grandes com árvores de componente profundas, a economia de desempenho pode ser significativa. Não está claro exatamente como a API se parece no momento, mas a equipe da React pretende finalizá-la em breve e lançá-la no próximo ano. Se você estiver interessado em adotar esse recurso, verifique se sua base de código é compatível adotando os novos métodos de ciclo de vida lançados no React 16.3.

Reagir continua a crescer em popularidade, e de acordo com a pesquisa State of JavaScript 2018 64% dos entrevistados usam e usam novamente (+ 7,1% desde o ano passado), comparado a 28% para Vue (+ 9,2%) e 23 % para angular (+ 5,1%).

Webpack

O Webpack 4 foi lançado em fevereiro , trazendo enormes melhorias de desempenho, modos integrados de produção e desenvolvimento, otimizações fáceis de usar, como divisão e redução de código, suporte experimental ao WebAssembly e suporte a módulos ECMAScript. O Webpack agora é muito mais fácil de usar do que as versões anteriores e os recursos anteriormente complicados, como divisão e otimização de código, agora são muito simples de configurar. Combinado com o Typescript ou Babel, o webpack continua a ser a ferramenta fundamental para desenvolvedores web e parece improvável que um concorrente venha e substitua-o em um futuro próximo.

Babel

Babel 7 foi lançado em agosto , o primeiro grande lançamento em quase três anos. As principais mudanças incluem tempos de construção mais rápidos , um novo namespace de pacote e a suspensão dos vários pacotes de presets ECMASCript de “estágio” e anual em favor de preset-env , o que simplifica muito a configuração do Babel ao incluir automaticamente os plugins necessários para os navegadores que você suporta. Esta versão também adiciona o polifilling automático , que elimina a necessidade de importar todo o polyfill Babel (que é bastante grande) ou importar explicitamente os polyfills de que você precisa (o que pode ser demorado e propenso a erros).

O Babel também suporta agora a sintaxe de Typescript , tornando mais fácil para os desenvolvedores usarem Babel e Typescript juntos. O Babel 7.1 também adicionou suporte para a nova proposta de decoradores , que é incompatível com a proposta obsoleta amplamente adotada pela comunidade, mas que combina com o que os navegadores apoiarão. Felizmente, a equipe do Babel publicou um pacote de compatibilidade que facilitará a atualização.

Elétron

O Electron continua a ser a maneira mais popular de empacotar aplicativos JavaScript para a área de trabalho, embora isso seja uma controvérsia ou não. Alguns dos aplicativos de desktop mais populares agora usam o Electron para reduzir os custos de desenvolvimento, facilitando o desenvolvimento de aplicativos entre plataformas.

Uma queixa comum é que os aplicativos que usam o Electron tendem a usar muita memória, já que cada aplicativo empacota uma instância inteira do Chrome (que consome muita memória). Carlo é uma alternativa eletrônica do Google que usa a versão do Chrome instalada localmente (o que é necessário), resultando em um aplicativo que exige menos memória. O próprio Electron não fez muito progresso com a melhoria do desempenho, e as atualizações recentes se concentraram na atualização da dependência do Chrome e pequenas alterações na API.

Datilografado

Datilografado aumentou muito em popularidade no ano passado, emergindo como um genuíno desafiante ao ES6 como o sabor dominante do JavaScript. Como a Microsoft lança novas versões mensalmente, o desenvolvimento progrediu rapidamente no último ano. A equipe do Typescript enfatizou muito a experiência do desenvolvedor, tanto para a linguagem em si quanto para as ferramentas do editor que a cercam.

Lançamentos recentes adicionaram mais formatação de erro de desenvolvedor e poderosos recursos de refatoração como atualização automática de importação e organização de importação , entre outros. Ao mesmo tempo, o trabalho continua melhorando o sistema de tipos com recursos recentes como tipos condicionais e tipo desconhecido .

O State of JavaScript Survey 2018 observa que quase metade dos entrevistados usa o TypeScript, com uma forte tendência de alta nos últimos dois anos. Em contraste, o principal concorrente, o Flow, estagnou em popularidade, com a maioria dos desenvolvedores dizendo que eles não gostavam de sua falta de ferramentas e do momento popular. O Typescript é admirado por facilitar aos desenvolvedores escrever códigos robustos e elegantes, apoiados por um poderoso suporte a editores. Seu patrocinador, a Microsoft, parece estar mais disposto a apoiá-lo do que o Facebook com o Flow, e os desenvolvedores notaram claramente.