A discussão sobre a seleção do WordPress Core JavaScript Framework continua com a contribuição dos líderes da comunidade de código aberto

O canal Slack #core-js do WordPress organizou uma reunião animada e produtiva esta manhã liderada por Andrew Duthie. A discussão se concentrou menos em comparações de estruturas específicas e mais no papel que uma estrutura desempenhará na construção de interfaces baseadas em JavaScript para WordPress. Os colaboradores se juntaram aos principais desenvolvedores e líderes das comunidades React e Vue, engenheiros do Chrome e outras partes interessadas de fora da comunidade WordPress.

“Este bate-papo se concentrará principalmente na identificação de requisitos na construção de recursos principais, sobreposição com autores de plugins e temas e padrões para reduzir o bloqueio do framework”, disse Duthie. “Idealmente, isso é um nível mais alto do que simplesmente debater os méritos de estruturas específicas em um vácuo e deve ser visto como uma oportunidade de colaborar entre projetos para definir um caminho a seguir para o WordPress que fornecerá flexibilidade e resiliência para futuras rotações.”

Duthie começou perguntando qual o papel que um framework deveria desempenhar no fluxo de trabalho de um desenvolvedor WordPress e também pediu aos colaboradores do framework que oferecessem suas perspectivas sobre recomendações para interfaces extensíveis. Essa pergunta deu aos participantes a oportunidade de avaliar tópicos como suporte a componentes da Web, interoperabilidade de bloco independente de estrutura para Gutenberg e como isso pode afetar o ecossistema de plugins do WordPress.

“Eu discordo um pouco da ideia de que qualquer núcleo (neste caso Gutenberg) usado para alimentar alguns dos meandros da construção de um aplicativo com estado será o padrão de fato para o desenvolvimento de plugins”, disse o engenheiro de Gutenberg, Matias Ventura. “A estrutura real aqui, em termos gerais, será o que o WordPress expõe e as APIs.”

Com uma abordagem agnóstica de estrutura para construir Gutenblocks, a biblioteca em que o núcleo decide construir não precisa se tornar o padrão de fato para desenvolvedores de plugins, mas muitos fora da equipe do Gutenberg acreditam que inevitavelmente acabará assim na prática. Há equipes inteiras de engenheiros esperando por essa decisão que se comprometem a adotar qualquer framework em que o WordPress aposte.

“Para fornecer alguma perspectiva sobre como a decisão do WP em um framework impacta os desenvolvedores downstream, sou um desenvolvedor na Universidade de Boston e nosso plano é focar em qualquer framework que o WP decida, mesmo que Gutenberg tenha uma API completamente agnóstica”, disse Adam Pieniazek. . “Somos principalmente uma loja WP (~ 1.000 sites WP instalados alimentam a maioria/muito de nossa presença pública na web) e acabamos criando enormes personalizações em cima do WP que geralmente exigem mergulho no núcleo para ver o que está realmente acontecendo em segundo plano . Eu gosto mais do Vue do que do React pessoalmente, mas se o WP decidir pelo React, a BU se concentrará na construção de experiência no React para quando precisarmos espiar/depurar além da API. Isso não significa que também não usaremos o Vue, mas não será nosso foco principal.”

O feedback de Pieniazek ecoa o do cofundador da Gravity Forms, Carl Hancock, que disse que sua equipe está pronta para adotar qualquer biblioteca que o WordPress selecionar.

“As pessoas vão acabar adotando o que o núcleo usa na maior parte, apesar dos arco-íris e borboletas que alguns estão reivindicando no que se refere à criação de uma camada de abstração para que os desenvolvedores de plugins/temas possam usar o que quiserem”, disse Hancock no #core- js no início desta semana.

Muitos participantes de fora da comunidade WordPress pareciam estar de acordo com uma abordagem agnóstica de estrutura e nenhum estava ansioso para forçar uma única estrutura em todos os desenvolvedores que trabalham com o WordPress. A preocupação restante é como isso funciona na prática e se isso coloca os desenvolvedores na posição confusa de usar um framework em cima de um framework.

“Como o próprio Gutenberg se tornará uma plataforma para a qual construir, o melhor nível de separação é se a estrutura for usada para construir o núcleo, mas não for exposta como API para construtores de blocos”, disse o engenheiro da AMP Paul Bakaus. “Isso dá a opção de substituir a base subjacente sempre que necessário.”

O engenheiro de Gutenberg, Riad Benguella, resumiu a abordagem que a equipe vem discutindo:

Acho que o que tentamos comunicar é algo como:

– WordPress Core vai usar este framework X internamente
– Se você quiser usar, achamos bom
– Se você quiser usar outra coisa, você pode tão facilmente quanto usaria o framework escolhido pelo Core

Benguella também disse que um dos objetivos de Gutenberg é “estabelecer a base de como estendemos a interface do usuário do WordPress no futuro”. Assim que for lançado, a equipe provavelmente focará em outras partes do wp-admin e as construirá da mesma maneira.

“Se todas as partes da interface do usuário do WP puderem ser estendidas por meio de uma interface padrão, seja uma API simples de 'data down, events up' ou esperando um WC, acho que isso separaria claramente as preocupações de 'qual framework usar para core ' versus 'qual framework usar para desenvolvimento de extensão'”, disse Evan You, criador do Vue.js.

Quando perguntado sobre seus pensamentos sobre o React se tornar uma estrutura primária para o WordPress, o mantenedor do React, Dan Abromov, hesitou em defender a adoção da biblioteca pelo WordPress. Sua resposta enfatizou a necessidade de ter uma abordagem agnóstica de framework para estender o Gutenberg e futuras revisões da interface WP.

“Eu realmente não conheço bem o WordPress, então é difícil para mim dizer se é uma ótima opção para o caso de uso ou não”, disse Abramov. “Geralmente usamos o React para interfaces de usuário altamente interativas e descobrimos que ele se adapta bem ao tamanho do aplicativo. Também estou feliz em responder a perguntas técnicas sobre isso. Mas acho que, em geral, as pessoas têm opiniões fortes sobre, por exemplo, modelagem versus expressividade, e não sinto que forçar o React a todos seja o melhor caminho.”

“Eu também sinto o mesmo”, disse Evan You. “Forçar uma estrutura única para todos, independentemente de qual, a IMO não é uma boa ideia, porque é obrigada a alienar o grupo de desenvolvedores que não estão nessa estrutura e impõe um risco maior de estabilidade a longo prazo.”

Abramov também disse que as pessoas já estão “muito amargas e divisivas” sobre o assunto de selecionar um framework. Ele também twittou um sentimento semelhante antes da reunião.

Quando leio tópicos de discussão (por exemplo, sobre WordPress) há uma sensação de que as pessoas percebem cada equipe como hostil a outras. Isso é falso.

— Dan (@dan_abramov) 26 de setembro de 2017

Pense nisso como cuidar de um jardim. Você está convidado a sair no nosso. Outros jardins também são ótimos

— Dan (@dan_abramov) 26 de setembro de 2017

“Acredito que seja importante (e tecnicamente viável) separar 'qual framework usar para o núcleo' e 'qual framework os desenvolvedores da comunidade usam para extensões'”, disse Evan You.

“Sim, acho que há um objetivo aqui de não ter opinião sobre o que estamos expondo aos autores de plugins, desde que as APIs/interfaces que expomos sejam suficientemente flexíveis (e fáceis) para construir as UIs e interações que eles precisam implementar, disse Andrew Duthie.

O tópico de suporte à interoperabilidade de componentes web para Gutenblocks também fez parte da discussão durante a reunião.

“Embora menos poderosos do que a maioria das estruturas reais neste momento, eles provavelmente se tornarão um padrão W3C, garantindo que eles permaneçam e evoluam”, disse Felix Arntz. “Além disso, uma vez que o suporte ao navegador está totalmente disponível, há menos funcionalidades para implementar por uma estrutura real construída em cima.”

O representante do Polymer.js, Justin Fagnani, disse que discorda que eles sejam “menos poderosos” e observou que os componentes da web já são um padrão W3C.

“Acho que o WP também está posicionado de forma única para ajudar a impulsionar o suporte para componentes da Web nativamente em todos os lugares”, disse o desenvolvedor principal do EventEspresso, Darren Ethier. “Praticamente todos os frameworks têm a capacidade de trabalhar com a especificação do componente web agora. É apenas uma questão de implementação adequada.”

Vários participantes fizeram referência ao custom-elements-everywhere.com, um site que exibe o progresso de estruturas JS populares na comunicação de elementos personalizados de uma maneira que promove a interoperabilidade. Matias Ventura perguntou aos desenvolvedores principais do React e Vue como os componentes web (e seu futuro) se encaixam em cada framework no momento.

“No React, temos algum suporte a componentes da Web, mas não o tornamos uma grande prioridade, já que os casos de uso pareciam escassos no passado, especialmente porque a adição de componentes da Web não fazia muito sentido em um aplicativo primário em que você controle toda a pilha – mas temos algum suporte para eles, no entanto, e estou feliz em adicionar mais, agora ou no futuro”, disse Sophie Alpert.

“No alto nível, acho que frameworks como React/Vue fornecem o que não é realmente abordado em componentes da web: atualizações de DOM eficientes e declarativas reagindo a mudanças de estado”, disse Evan You. “É também por isso que o Polymer existe em cima do WC. Sempre reconheci o valor do WC como uma interface de interoperabilidade.”

No geral, os participantes da reunião foram respeitosos, colaborativos e ansiosos para contribuir com seus conhecimentos para ajudar os contribuidores do WordPress a encontrar o melhor caminho a seguir no processo de seleção da estrutura. A discussão continuará na reunião da próxima semana e provavelmente nos comentários de um próximo post Make/Core resumindo a reunião.