La discusión sobre la selección del marco JavaScript principal de WordPress continúa con aportes de los líderes de la comunidad de código abierto

El canal Slack #core-js de WordPress organizó una reunión animada y productiva esta mañana dirigida por Andrew Duthie. La discusión se centró menos en las comparaciones de marcos específicos y más en el papel que desempeñará un marco en la construcción de interfaces basadas en JavaScript para WordPress. A los colaboradores se unieron los principales desarrolladores y líderes de las comunidades de React y Vue, los ingenieros de Chrome y otras partes interesadas de fuera de la comunidad de WordPress.

“Este chat se centrará en gran medida en la identificación de los requisitos en la creación de funciones principales, la superposición con los autores de complementos y temas, y los patrones para reducir el bloqueo del marco”, dijo Duthie. “Idealmente, esto es de un nivel más alto que simplemente debatir los méritos de marcos específicos en el vacío, y debe verse como una oportunidad para colaborar entre proyectos para establecer un camino a seguir para WordPress que proporcionará flexibilidad y resistencia para futuras rotaciones”.

Duthie comenzó preguntando qué papel debería desempeñar un marco en el flujo de trabajo de un desarrollador de WordPress y también pidió a los contribuyentes del marco que ofrecieran sus perspectivas sobre recomendaciones para interfaces extensibles. Esta pregunta brindó a los asistentes la oportunidad de opinar sobre temas como la compatibilidad con componentes web, la interoperabilidad de bloques independientes del marco para Gutenberg y cómo esto podría afectar el ecosistema de complementos de WordPress.

“No estoy un poco de acuerdo con la idea de que cualquier núcleo (en este caso, Gutenberg) que se utilice para impulsar algunas de las complejidades de la creación de una aplicación con estado será el estándar de facto para el desarrollo de complementos”, dijo el ingeniero de Gutenberg, Matias Ventura. “El marco real aquí, en términos generales, será lo que expone WordPress y las API”.

Con un enfoque agnóstico del marco para construir Gutenblocks, la biblioteca en la que el núcleo decide construir no tiene que convertirse en el estándar de facto para los desarrolladores de complementos, pero muchos fuera del equipo de Gutenberg creen que inevitablemente terminará así en la práctica. Hay equipos completos de ingenieros esperando esta decisión que se comprometen a adoptar cualquier marco por el que apueste WordPress.

"Para brindar una perspectiva sobre cómo la decisión de WP sobre un marco afecta a los desarrolladores posteriores, soy un desarrollador de la Universidad de Boston y nuestro plan es centrarnos en cualquier marco que WP decida, incluso si Gutenberg tiene una API completamente agnóstica", dijo Adam Pieniazek. . “Principalmente somos una tienda de WP (~ 1,000 sitios de instalación de WP potencian la mayoría/una gran parte de nuestra presencia pública en la web) y terminamos creando enormes personalizaciones además de WP que a menudo requieren profundizar en el núcleo para ver qué sucede realmente en segundo plano. . Personalmente, me gusta más Vue que React, pero si WP decide sobre React, BU se centrará en desarrollar experiencia en React para cuando necesitemos mirar/depurar más allá de la API. No significa que no usaremos Vue, pero no será nuestro enfoque principal”.

Los comentarios de Pieniazek se hacen eco de los del cofundador de Gravity Forms, Carl Hancock, quien dijo que su equipo está listo para adoptar cualquier biblioteca que seleccione WordPress.

“La gente terminará adoptando cualquier uso principal en su mayor parte a pesar de los arcoíris y las mariposas que algunos afirman en relación con la creación de una capa de abstracción para que los desarrolladores de complementos/temas puedan usar lo que quieran”, dijo Hancock en el #core- canal js a principios de esta semana.

Muchos participantes de fuera de la comunidad de WordPress parecían estar de acuerdo con un enfoque agnóstico del marco y ninguno estaba ansioso por imponer un marco único a todos los desarrolladores que trabajan con WordPress. La preocupación restante es cómo funciona esto en la práctica y si pone a los desarrolladores en la posición confusa de usar un marco sobre otro marco.

“Dado que Gutenberg en sí mismo se convertirá en una plataforma para construir, el mejor nivel de separación es si el marco se usa para construir el núcleo, pero no está expuesto como API para construir bloques”, dijo el ingeniero de AMP Paul Bakaus. “Esto le da a uno la opción de reemplazar la base subyacente cuando sea necesario”.

El ingeniero de Gutenberg, Riad Benguella, resumió el enfoque que el equipo ha estado discutiendo:

Creo que lo que tratamos de comunicar es algo como:

– WordPress Core va a usar este marco X internamente
– Si quieres usarlo, creemos que es bueno
– Si desea usar algo más, puede hacerlo con la misma facilidad con la que usaría el marco elegido por Core.

Benguella también dijo que uno de los objetivos de Gutenberg es "establecer las bases sobre cómo extenderemos la interfaz de usuario de WordPress en el futuro". Una vez que se envíe, es probable que el equipo fije su mirada en otras partes de wp-admin y las construya de la misma manera.

"Si todas las partes de la interfaz de usuario de WP se pueden ampliar a través de una interfaz estándar, ya sea una API simple de 'inactividad de datos, actividad de eventos' o esperar un WC, creo que esto separaría claramente las preocupaciones de 'qué marco usar para el núcleo ' frente a 'qué marco usar para el desarrollo de extensiones'”, dijo el creador de Vue.js, Evan You.

Cuando se le preguntó su opinión sobre si React se convertiría en un marco principal para WordPress, el mantenedor de React, Dan Abromov, dudó en abogar por que WordPress adoptara la biblioteca. Su respuesta subrayó la necesidad de tener un enfoque agnóstico del marco para extender Gutenberg y futuras revisiones de la interfaz de WP.

"Realmente no conozco bien WordPress, por lo que es difícil para mí decir si es una buena opción para el caso de uso o no", dijo Abramov. “Por lo general, usamos React para interfaces de usuario altamente interactivas y descubrimos que se adapta bien al tamaño de la aplicación. También estoy feliz de responder preguntas técnicas al respecto. Pero creo que, en general, las personas tienen opiniones firmes sobre, por ejemplo, las plantillas frente a la expresividad, y no creo que obligar a React a todos sea la mejor manera”.

“Yo también siento lo mismo”, dijo Evan You. "Forzar un marco único para todos, independientemente de cuál, en mi opinión, no es una buena idea porque alienará al grupo de desarrolladores que no están en ese marco e impone un mayor riesgo de estabilidad a largo plazo".

Abramov también dijo que la gente ya está "muy amargada y divisiva" sobre el tema de seleccionar un marco. También tuiteó un sentimiento similar antes de la reunión.

Cuando leo hilos de discusión (por ejemplo, sobre WordPress) tengo la sensación de que la gente percibe a todos los equipos como hostiles a los demás. eso es falso

— Dan (@dan_abramov) 26 de septiembre de 2017

Piense en ello como cuidar un jardín. Eres bienvenido a pasar el rato en el nuestro. Otros jardines también son geniales.

— Dan (@dan_abramov) 26 de septiembre de 2017

“Creo que es importante (y técnicamente factible) separar 'qué marco usar para el núcleo' y 'qué marco usan los desarrolladores de la comunidad para las extensiones'”, dijo Evan You.

“Sí, creo que hay un objetivo aquí para no tener opiniones sobre lo que estamos exponiendo a los autores de complementos, siempre que las API/interfaces que exponemos sean lo suficientemente flexibles (y fáciles) para crear las UI y las interacciones que necesitan implementar. dijo Andrew Duthie.

El tema del soporte de la interoperabilidad de componentes web para Gutenblocks también fue parte de la discusión durante la reunión.

“Si bien son menos poderosos que la mayoría de los marcos actuales en este momento, es probable que se conviertan en un estándar W3C, lo que garantiza que se mantengan y evolucionen”, dijo Felix Arntz. “Además, una vez que el soporte del navegador está completamente disponible, hay menos funcionalidad para implementar mediante un marco real construido en la parte superior”.

El representante de Polymer.js, Justin Fagnani, dijo que no estaba de acuerdo con que sean "menos potentes" y señaló que los componentes web ya son un estándar W3C.

“Creo que WP también está en una posición única para ayudar a impulsar el soporte para componentes web de forma nativa en todas partes”, dijo Darren Ethier, desarrollador principal de EventEspresso. “Casi todos los marcos tienen la capacidad de trabajar con la especificación del componente web ahora. Es solo una cuestión de implementación adecuada”.

Varios participantes hicieron referencia a custom-elements-everywhere.com, un sitio que muestra el progreso de los marcos JS populares en la comunicación de elementos personalizados de una manera que promueve la interoperabilidad. Matias Ventura preguntó a los desarrolladores centrales de React y Vue cómo los componentes web (y su futuro) encajan en cada marco en este momento.

“En React, tenemos algo de compatibilidad con componentes web, pero no lo hemos convertido en una gran prioridad ya que los casos de uso parecían escasos en el pasado, especialmente porque agregar componentes web no tenía mucho sentido en una aplicación propia en la que controlar toda la pila, pero de todos modos tenemos algo de apoyo para ellos y estoy feliz de entretenerme agregando más, ya sea ahora o en el futuro”, dijo Sophie Alpert.

“En un nivel alto, creo que los marcos como React/Vue brindan lo que realmente no se aborda en los componentes web: actualizaciones DOM eficientes y declarativas que reaccionan a los cambios de estado”, dijo Evan You. “Esta es también la razón por la que Polymer existe encima del WC. Siempre he reconocido el valor de WC como interfaz de interoperabilidad”.

En general, los asistentes a la reunión fueron respetuosos, colaborativos y ansiosos por contribuir con su experiencia para ayudar a los colaboradores de WordPress a encontrar la mejor manera de avanzar en el proceso de selección del marco. La discusión continuará en la reunión de la próxima semana y probablemente en los comentarios de una próxima publicación de Make/Core que resuma la reunión.