Implicações de pensar em blocos em vez de bolhas

Gutenberg é um editor baseado em JavaScript (mais especificamente, é um editor baseado em React), que em breve transformará a experiência de criação de conteúdo para WordPress e (em um próximo estágio quando o Gutenberg for transformado em um construtor de sites) a experiência de criar Sites WordPress.

Gutenberg, o construtor de sites, exigirá uma maneira diferente de pensar como estabelecer as bases de um site. No que já podemos chamar de modelo “antigo”, os sites WordPress são criados dando estrutura por meio de templates ( header.php , index.php , sidebar.php , footer.php ), e buscando o conteúdo da página a partir de um único blob de código HTML. No novo modelo, a página tem componentes (React) colocados em toda a página, cada um deles controlando sua própria lógica, carregando seus próprios dados e auto-renderização.

Para apreciar visualmente a próxima mudança, o WordPress está saindo disso:

…para isso:

Acredito que mudar de blobs de código HTML para componentes para construção de sites é nada menos que uma mudança de paradigma. O impacto de Gutenberg é muito mais do que uma mudança de PHP para JavaScript: há coisas que poderiam ser feitas no passado que possivelmente não farão mais sentido. Da mesma forma, um novo mundo de possibilidades se abre, como interações de usuário ricas e poderosas. Os desenvolvedores da Web não deixarão de criar seus sites em um idioma para criar seus sites em outro idioma porque o site não será mais o mesmo; será um site completamente diferente que será construído.

Leitura recomendada : A anatomia completa do editor WordPress Gutenberg

Gutenberg ainda não foi totalmente adotado pela comunidade WordPress, por muitas razões. Por um lado, a nova arquitetura é baseada em uma infinidade de ferramentas e tecnologias (React, NPM, Webpack, Redux e assim por diante) que é muito mais difícil de aprender e dominar do que a antiga baseada em PHP. E embora possa valer a pena aprender uma nova pilha que oferece novas funcionalidades, nem todo site mom&pop precisa desses recursos novos e brilhantes.

Afinal, não é coincidência que 30% de todos os sites em todo o mundo sejam sites WordPress: a maioria deles são sites realmente simples, como blogs, e não redes sociais dinâmicas como o Facebook. Por outro lado, a inclusão do WordPress significa que qualquer pessoa pode construir um site simples – até mesmo pessoas sem experiência em codificação, como designers, profissionais de marketing de conteúdo e blogueiros.

Mas a complexidade da nova arquitetura deixará muitas pessoas de fora (nem quero pensar em depurar meu site em código JavaScript minificado). E por outro lado, assim que o Gutenberg for lançado, o React, apoiado pelo Facebook, será adicionado a até 30% de todos os sites do mundo – da noite para o dia. Muitas pessoas se sentem desconfortáveis ​​em dar tanto poder a qualquer tipo de biblioteca JavaScript, enquanto muitas outras desconfiam do Facebook. Para aliviar essa preocupação, Gutenberg abstrai o React para também habilitar a codificação em outros frameworks ou bibliotecas; entretanto, na prática, o React será, sem dúvida, a biblioteca JavaScript predominante.

E, no entanto, a perspectiva de ser oferecido um novo mundo de possibilidades é realmente doce. No meu caso, estou animado. No entanto, meu entusiasmo não é sobre a tecnologia (React) ou sobre a implementação (Gutenberg), mas sobre o conceito, que é criar sites usando componentes como unidade de construção. No futuro, a implementação pode mudar para outra plataforma, como o Vue, mas o conceito permanecerá.

Prever quais novos recursos poderemos implementar nem sempre é fácil. Leva tempo para se adaptar a um novo paradigma, e tendemos a usar novas ferramentas da maneira antiga até que nos demos conta de como usar as novas ferramentas para atingir novos objetivos. Mesmo os arquivos PDF (que são uma representação da impressão, a tecnologia predominante antes do nascimento da web) ainda são uma visão comum na web, negligenciando as vantagens que a web tem sobre a impressão.

“Imitar papel em uma tela de computador é como arrancar as asas de um 747 e usá-lo como ônibus na estrada.”

-Ted Nelson

Neste artigo, analisarei várias implicações da construção de sites por meio de uma arquitetura baseada em componentes (como o conceito) e por meio de Gutenberg (como a implementação), incluindo quais novas funcionalidades ele pode oferecer, quanto melhor ele pode integrar com o desenvolvimento atual do site tendências e o que isso significa para o futuro do WordPress.

Versatilidade estendida e disponibilidade de conteúdo

Um efeito colateral muito importante de tratar todo o conteúdo como blocos é que ele permite direcionar pedaços de HTML individualmente e usá-los para diferentes saídas. Enquanto o conteúdo inserido no blob HTML é acessível apenas pela página da Web, como chunks ele pode ser acessado por meio de uma API e seus metadados estão prontamente disponíveis. Pegue elementos de mídia – como vídeos, áudio ou imagens. Como um bloco autônomo, o vídeo pode ser reproduzido em um aplicativo, o áudio pode ser reproduzido como um podcast e as imagens podem ser anexadas ao e-mail ao enviar um resumo – tudo isso sem precisar analisar o código HTML.

Da mesma forma, o conteúdo dos blocos pode ser adaptado para diferentes mídias: desde a menor tela até as maiores, touchscreen ou desktop, comandado por voz ou por toque, 2D/AR/VR, ou quem sabe o que o futuro pode trazer. Por exemplo, um bloco de áudio permite que o áudio seja reproduzido em um Apple Watch, comandado por voz através do sistema In-car ou um AWS Echo, ou como um item flutuante em nosso mundo virtual ao usar um headset VR. Os blocos também podem facilitar a configuração de uma única fonte de verdade para o conteúdo a ser publicado em diferentes saídas, como um site responsivo, AMP, aplicativo móvel, e-mail ou qualquer outro, como foi feito pela NPR por meio do Create Once , abordagem Publish Everywhere (COPE).

Nota : Para mais informações sobre esses tópicos, sugiro assistir à palestra de Karen McGrane Content in a Zombie Apocalypse.

Os blocos também podem melhorar a experiência do usuário. Se estiver navegando no site por meio de 3G, os blocos podem ser renderizados automaticamente em um modo de conexão lenta para exibir imagens de baixa qualidade e pular o carregamento de vídeos. Ou pode aprimorar o layout, como oferecer a exibição de uma galeria de imagens com um clique em qualquer ponto da página da Web, e não apenas no local em que foi incorporada no artigo.

Essas experiências podem ser alcançadas separando o conteúdo da forma, o que implica que a apresentação e o significado do conteúdo são desacoplados, e apenas o significado é salvo no banco de dados, tornando os dados da apresentação secundários e salvando-os em outro local. O HTML semântico é uma expressão deste conceito: devemos sempre usar <em> que implica significado, em vez de <i> que é uma forma de apresentação (para fazer o caractere ser exibido em itálico), pois assim esse conteúdo estará disponível para outros meios, como voz (Alexa não consegue ler em itálico, mas pode dar ênfase à frase).

Obter uma separação completa do conteúdo do formulário é muito difícil, pois o código de apresentação geralmente será adicionado dentro do bloco, por meio de marcação HTML (adicionar a classe “pull-right” já implica apresentação). No entanto, arquitetar o site usando blocos já ajuda a atingir algum nível de separação no nível do layout. Além disso, blocos criados para fazer apenas uma coisa, e fazê-lo muito bem, podem fazer uso de HTML semântico adequado, ter uma boa separação de preocupações em sua própria arquitetura em relação a HTML, JS e CSS (para que portá-los para outras plataformas pode exigir apenas um esforço mínimo) e ser acessível, pelo menos no nível do componente.

Nota : Uma regra geral: quanto mais inclusivo for um componente, mais preparado ele estará para médiuns ainda a serem inventados.

Infelizmente, o Gutenberg não foi projetado com esse propósito em mente, então os blocos também contêm bastante marcação HTML para apresentação. Por exemplo, um bloco de imagem de uma imagem externa tem como significado apenas o URL da imagem, a descrição alt e a legenda (e possivelmente também a largura e a altura); depois de criar um bloco de imagem, o seguinte trecho de código foi salvo no banco de dados (a classe aligncenter é para apresentação, e a marcação <div class="wp-block-image" /> seria completamente redundante se armazenasse apenas o significado):

 <!-- wp:image {"align":"center"} --> <div class="wp-block-image"> <figure class="aligncenter"> <img src="https://cldup.com/cXyG__fTLN.jpg" alt="Beautiful landscape"/> <figcaption>If your theme supports it, you'll see the "wide" button on the image toolbar. Give it a try.</figcaption> </figure> </div> <!-- /wp:image -->

Além disso, os blocos são salvos dentro do conteúdo do post (que é um grande blob HTML) em vez de cada um ter uma entrada própria no banco de dados. Os blocos reutilizáveis ​​(também chamados de blocos globais) têm sua própria entrada, o que me faz temer que os desenvolvedores possam converter blocos padrão em blocos reutilizáveis ​​apenas para um hack rápido para acessá-los diretamente no banco de dados.

Da mesma forma, estou preocupado que, se não forem projetados adequadamente, os blocos possam causar estragos em nossos sites. Por exemplo, desenvolvedores desavisados ​​podem ignorar a regra do menor poder, usando JavaScript não apenas para funcionalidade, mas também para CSS e marcação. Além disso, a funcionalidade de renderização do lado do servidor (SSR) do Gutenberg não é isomórfica (ou seja, não permite que uma única base de código produza a saída para o código do cliente e do lado do servidor), portanto, os blocos dinâmicos devem implementar a função para gerar o código HTML também como PHP para oferecer aprimoramento progressivo (sem o qual o site fica inacessível durante o carregamento inicial).

Em resumo, os blocos são um passo na direção certa para disponibilizar o conteúdo do WordPress em qualquer formato e para qualquer meio, mas não são uma solução definitiva, ainda há muito trabalho a ser feito.

atuação

O desempenho importa. Sites mais rápidos levam a usuários mais felizes, o que leva a melhores taxas de conversão. A equipe da Etsy, por exemplo, oferece novos recursos, por mais legais que sejam, se eles fizerem com que o tempo de carregamento do site ultrapasse um limite crítico (recomendo assistir à palestra de Allison McKnight sobre Desenvolvimento de desempenho a longo prazo e slides), enquanto a equipe do Twitter reprojetou seu site há vários anos para oferecer suporte à renderização do lado do servidor para mostrar o conteúdo o mais rápido possível e implementa continuamente várias pequenas alterações que se somam para fornecer uma experiência rápida ao usuário.

Sendo o JavaScript tão atraente para os desenvolvedores, eles não sofrem restrições em seu uso, o que é um problema real: JavaScript é muito caro em termos de desempenho e deve ser usado com muito cuidado.

Tal como está agora, Gutenberg está longe de ser o ideal: enquanto a criação de uma postagem com o editor antigo (para o qual precisamos instalar o Editor Clássico) requer o carregamento de cerca de 1,4 MB de JavaScript, o Gutenberg carrega cerca de 3,5 MB de JavaScript, apenas para sua experiência (ou seja, sem instalar nenhum bloco adicional):

Isso significa que, como está agora, 3,5 MB é a linha de base, e o tamanho do carregamento só aumentará a partir daí à medida que o administrador do site instalar mais blocos. Como foi visto em um artigo recente na Smashing Magazine, criar um bloco de depoimentos exigia 150 KB de JavaScript minificado. Quantos blocos um site padrão exigirá? Quantos MB de JavaScript o site médio precisará baixar?

As implicações são várias: por um lado, um site pesado está fora do alcance do próximo bilhão de usuários, que têm acesso principalmente em conexões lentas e compram planos de dados que representam uma parcela significativa de seu salário. Para eles, cada MB de dados faz a diferença: enviar mensagens do Whatsapp é acessível, baixar vários MBs de scripts só para carregar um site não é.

É verdade que o usuário do site não precisará interagir com o Gutenberg, pois o Gutenberg é simplesmente para construir o site, não para usá-lo: Gutenberg é um editor de back-end, não um editor de front-end (e talvez nunca be — pelo menos como parte do núcleo do WordPress). No entanto, os criadores de conteúdo serão penalizados e já são um alvo considerável. Além disso (como argumentei anteriormente), os usuários podem acabar sendo penalizados também por meio de blocos dinâmicos, que podem criar sua marcação por meio de JavaScript do lado do cliente em vez do PHP do lado do servidor.

Há também o problema do inchaço da funcionalidade duplicada adicionada por plugins de terceiros. Antigamente, um site WordPress pode ter carregado várias versões do jQuery, o que era relativamente fácil de corrigir. Atualmente, há uma enorme variedade de bibliotecas de código aberto para escolher para implementar uma funcionalidade necessária (arrastar e soltar, calendários, componentes de seleção múltipla, carrosséis, etc.), portanto, é mais provável que um site com dezenas de blocos de terceiros terá a mesma funcionalidade implementada por diferentes bibliotecas, criando um inchaço desnecessário. Além disso, há um pouco de inchaço adicionado ao próprio Gutenberg: como os blocos são registrados no frontend, o cancelamento do registro de um bloco já registrado é feito carregando um script adicional. Na minha opinião, este é um dos maiores desafios para os contribuidores do Gutenberg: implementar um processo simplificado que permita a qualquer pessoa (não apenas desenvolvedores experientes com Webpack) remover bibliotecas indesejadas e empacotar apenas o conjunto mínimo de recursos necessários para o aplicativo .

Finalmente, mencionei novamente que o Gutenberg suporta renderização do lado do servidor, mas como pode não ser fácil de manter, os desenvolvedores podem ficar tentados a não confiar nele. Nesse caso, há o custo de idas e voltas adicionais necessárias para obter os dados dos endpoints REST, apenas para renderizar o layout, durante o qual o usuário estará aguardando.

Na minha opinião, o desempenho será um dos grandes desafios para o Gutenberg, aquele que pode fazer ou quebrar em termos de adoção generalizada, e ainda há muito trabalho a ser feito, principalmente visando o próximo estágio quando o Gutenberg se tornar um site construtor.

Padrões da Web

Como mencionado anteriormente, Gutenberg abstrai o React para fornecer uma abordagem agnóstica de estrutura para blocos de construção que, se implementados corretamente, podem evitar que o WordPress seja bloqueado ao React. A comunidade WordPress é cautelosa ao mesclar qualquer estrutura JavaScript no núcleo do WordPress, em grande parte porque o Backbone.js, pouco depois de ser adicionado ao núcleo do WordPress, viu um declínio acentuado na popularidade e, além de alimentar o Media Manager, muitos recursos não foram realizados com isso. Mesmo que o React seja a biblioteca JavaScript mais popular no momento, não há razão para acreditar que esse sempre será o caso (como o desdobramento do jQuery pode atestar), e o WordPress deve estar preparado para quando esse dia finalmente chegar (o que, dada a rápida ritmo da tecnologia, pode acontecer mais cedo do que o esperado).

A melhor forma de evitar o bloqueio a qualquer biblioteca é através de padrões web e, mais especificamente neste caso, a implementação de blocos através de componentes web. Os componentes da Web são componentes fortemente encapsulados que operam com as APIs do navegador, portanto, não requerem nenhuma biblioteca JavaScript para trabalhar. No entanto, eles podem ser implementados por meio de qualquer estrutura JavaScript do lado do cliente.

Mesmo que o React ainda não forneça uma integração perfeita com os componentes da web, eventualmente (ou melhor, esperançosamente) o fará. Conforme explicado na documentação do React, componentes web e componentes React podem funcionar junto com:

“React e Web Components são construídos para resolver problemas diferentes. Os Web Components fornecem encapsulamento forte para componentes reutilizáveis, enquanto o React fornece uma biblioteca declarativa que mantém o DOM sincronizado com seus dados. Os dois objetivos são complementares. Como desenvolvedor, você é livre para usar o React em seus Web Components, ou usar Web Components no React, ou ambos.”

A partir de hoje, as perspectivas dessa situação não parecem muito promissoras: não consegui encontrar nenhum tutorial para blocos de construção com componentes da web. Acredito que a comunidade deveria focar algum esforço nessa causa, incentivando os desenvolvedores a começarem a construir blocos usando componentes da web, e quanto mais cedo melhor, já que Gutenberg nos obriga a aprender novas tecnologias de qualquer maneira, agora. É uma oportunidade de estabelecer uma base sólida com padrões da web, desde o início.

Interoperabilidade entre sites, homogeneização de sites

Um bloco é uma entidade menor do que um tema ou plugin, portanto, eventualmente, os blocos serão acessíveis por conta própria e adquiridos por meio de mercados de blocos recém-criados. Muito provavelmente haverá inicialmente uma explosão cambriana de blocos, já que muitos players do ecossistema correm para ser os primeiros a comercializar suas soluções, levando a médio e longo prazo à consolidação dos mais bem-sucedidos.

Depois que a poeira baixar, alguns blocos se destacarão e se tornarão os vencedores, obtendo a maior parte do mercado em suas categorias específicas. Se/quando isso acontecer, será motivo de preocupação e júbilo: preocupação com uma nova onda de homogeneização da web (como aconteceu com o Bootstrap), pois sites usando os mesmos componentes podem acabar com a mesma aparência , um júbilo sobre uma maior interoperabilidade entre sites por depender dos mesmos componentes e das mesmas APIs, o que pode abrir as portas para novas oportunidades.

Estou particularmente entusiasmado com a expansão da interoperabilidade entre sites. É uma área que pode, a longo prazo, desfazer reinos como o do Facebook: em vez de depender de um gateway monopolista para compartilhar informações, sites com diferentes comunidades podem facilmente compartilhar dados entre si, diretamente. Este não é um conceito novo: o movimento IndieWeb trabalha há muito tempo para permitir que qualquer pessoa possua seus próprios dados em seus próprios servidores, fazendo com que os sites conversem entre si por meio de microformatos. Por exemplo, seu padrão web Webmention permite que dois sites tenham uma conversa, na qual cada comentário e resposta é armazenado em ambos, e o Micro.blog oferece um tipo de Twitter, mas baseado na web aberta, na qual as postagens na linha do tempo do usuário são coletados de feeds RSS e JSON de sites inscritos. Esses empreendimentos são maravilhosos, mas ainda têm um impacto muito pequeno, pois há algum nível de conhecimento técnico necessário para fazer parte deles. A arquitetura baseada em componentes de Gutenberg pode potencialmente produzir um impacto muito mais amplo: blocos populares podem permitir que dezenas de sites WordPress conversem entre si, eventualmente permitindo que até 30% de todos os sites na web façam parte de uma rede descentralizada e fracamente acoplada .

Esta área vai precisar de muito trabalho, porém, antes de ser viável. Não acho que os endpoints REST padrão sejam a melhor interface de comunicação, pois não foram concebidos para esse fim (o pessoal do micro.blog propôs uma solução melhor por meio de sua interface JSON, que é baseada na especificação RSS). Além disso, o próprio REST está se tornando obsoleto pelo GraphQL, então eu não colocaria grandes esperanças nele a longo prazo. Também estou envolvido em encontrar uma maneira melhor, para a qual estou trabalhando atualmente em um tipo diferente de API, que pode recuperar todos os dados necessários em apenas uma solicitação e oferece suporte à extensibilidade por meio de uma arquitetura baseada em componentes.

Também espero que a integração com serviços em nuvem seja mais proeminente, pois os provedores podem liberar seus próprios blocos para interagir com seus próprios serviços. Como um componente é uma unidade autônoma, apenas arrastar e soltar o bloco na página já faz todo o trabalho da perspectiva do usuário, tornando muito fácil construir sites poderosos com pouco ou nenhum conhecimento. Por exemplo, um provedor de armazenamento de imagens como o Cloudinary pode liberar um bloco que corta automaticamente a imagem de acordo com a janela de visualização do dispositivo ou solicita a imagem como WebP, se houver suporte, ou outros casos de uso.

Em resumo, a consolidação do mercado de blocos pode trazer homogeneização da aparência e sensação, o que seria um evento lamentável e deve ser evitado, e poderosos recursos de interoperabilidade e compartilhamento de dados entre sites e integração com serviços em nuvem.

Integração com bibliotecas de padrões

Uma biblioteca de padrões é uma coleção de elementos de design de interface do usuário, cada um deles geralmente composto por trechos de HTML, JS e CSS. Um bloco é um componente autônomo, geralmente composto de bits de HTML, JS e CSS. Portanto, os blocos são evidentemente adequados para serem documentados/construídos com bibliotecas de padrões. Ter os blocos enviando suas bibliotecas de padrões seria um grande negócio, pois poderia permitir que as equipes não começassem a implementar a biblioteca de padrões do site apenas no nível do site, mas como uma agregação e refinamento das bibliotecas de minipadrões de todos os blocos necessários.

Acredito que algo semelhante ao processo de racionalização para a produção de pacotes JavaScript bloatless que mencionei anteriormente acontece neste caso, mas em relação a UI/UX/Documentação. Seria um desafio e uma oportunidade para os contribuidores do Gutenberg implementar um processo que tornasse fácil para os desenvolvedores de blocos criar bibliotecas de padrões para seus blocos que, quando agregados, podem resultar em uma biblioteca de padrões coerente para o site. Bem implementado, esse recurso pode reduzir os custos de construção de sites de uma perspectiva de documentação/manutenção.

O que será do WordPress?

Gutenberg certamente tornará os sites mais atraentes, mesmo que ao custo de um nível de conhecimento necessário que nem todos serão capazes de lidar. A longo prazo, isso pode levar a maior qualidade e menor quantidade. Vindo da máxima do WordPress de “Democratizing Publishing”, isso pode se tornar um problema.

Estou entusiasmado com o Gutenberg, mas mais como o conceito de uma arquitetura baseada em componentes, do que a implementação baseada em React. Em termos gerais, concordo com o que Matt Mullenweg disse durante o WordCamp Europe 2018 para justificar Gutenberg:

“A base do WordPress que agora nos serviu bem por quinze anos não durará pelos próximos quinze.”

No entanto, também acredito que o WordPress de quinze anos no futuro pode acabar sendo completamente diferente do que conhecemos hoje. Eu me pergunto se o WordPress acabará sendo principalmente o editor baseado no cliente, e não muito mais: a iniciativa de integrar Gutenberg ao Drupal, com o objetivo de fazer Gutenberg se tornar o editor da web aberta, oficializará o WordPress como um CMS headless operando por meio de terminais REST. Este é um bom desenvolvimento por si só, mas tornará o WordPress o back-end dispensável: se qualquer outra plataforma de back-end fornecer recursos melhores, não há mais motivo para ficar com o back-end do WordPress. Afinal, o Gutenberg do lado do cliente poderá trabalhar com qualquer um deles, enquanto a simplicidade de criar um site com WordPress será perdida, nivelando o campo de jogo com todas as outras plataformas.

Em particular, não ficaria surpreso se os desenvolvedores sentirem que manter duas bases de código (uma em JavaScript e outra em PHP) para renderizar blocos dinâmicos é muito desgastante e decidirem mudar para plataformas que suportam renderização isomórfica do lado do servidor. Se esse cenário realmente acontecer, Matt decidiria mudar o back-end do WordPress para Node.js?

É principalmente por causa dessa questão que me atrevo a dizer que o WordPress de 15 anos a partir de agora pode ser uma entidade muito diferente do que é hoje. Quem sabe o que irá acontecer?

Conclusão

Ao tornar os componentes a nova unidade para sites de construção, a introdução do Gutenberg será transformadora para o WordPress. E como em qualquer mudança de paradigma, haverá vencedores e perdedores. Diferentes partes interessadas considerarão o Gutenberg um desenvolvimento positivo ou negativo, dependendo de sua própria situação: enquanto a qualidade de um site aumentará, o preço de construir tal site contratando desenvolvedores que possam lidar com sua complexidade também aumentará, tornando-o menos acessível e menos populares.

Estes são tempos emocionantes, mas também momentos cruciais. A partir de agora, o WordPress pode lentamente começar a ser uma entidade diferente do que estamos acostumados, e podemos eventualmente precisar pensar sobre o que é o WordPress e o que ele representa, tudo de novo.