Gutenberg: Elegir el marco de JavaScript para Gutenberg (~ WordPress)

Mi voto es con VueJS

Yo elijo VueJS

Vue tiene una gran comunidad y debería ser la mejor opción.

JS angular

Votaré por VueJS. Como se describió anteriormente, es amigable para principiantes y se usa con éxito con Laravel. Eso la convierte en la elección perfecta.

También votaré por Vue JS

Tenga en cuenta que solo gritar "Prefiero Vue" o "Quiero XY" no ayuda realmente con la toma de decisiones aquí. Si quieres votar, te sugiero que uses reacciones de emoji o algo así en lugar de saturar un hilo que posiblemente podría actuar como un lugar para documentar los hallazgos al evaluar diferentes marcos.

Iré con Vue. Es más fácil de aprender y adaptarse. Además, es menos controvertido que Preact.

A la cuestión de la "dependencia de la persona clave" que surge de vez en cuando, ¿no es eso lo que son todos los complementos de funciones de WordPress o tecnología desconocida? Koop construyó el antiguo manejo de medios, Weston hizo un montón de trabajo de personalización, Matías y algunos otros están trabajando en Gutenberg, casi todos los cambios importantes en WordPress que se han producido en los últimos años han tenido un pequeño grupo de personas trabajando en él. o entenderlo.

Podría estar viendo esto de manera incorrecta, pero la "dependencia de la persona clave" para cualquier elección parece una pista falsa. Con la adopción, la dependencia de la persona clave se elimina por completo. WordPress también fue una vez un proyecto clave de dependencia de personas (Mike y Matt). Creo que es un argumento débil para evitar la adopción.

Una vez más, podría estar pensando en esto completamente mal, pero es un hilo común de pensamientos que veo aparecer de vez en cuando y no entiendo su aparentemente gran importancia.

Para agregar al comentario de

¡Votaría por VueJS! Es, con mucho, el más fácil de adaptar por parte de la comunidad.

Creo que los componentes web (sin Polymer, pero con lit-html o similar si se necesita un DOM virtual) deben considerarse seriamente. ¡Usar la plataforma y los estándares es mucho mejor que cualquier biblioteca o marco! Contribuye a una estructura de componentes sólida y segura en el futuro, que es naturalmente interoperable con todos los marcos. (Vue, Angular, React, aunque actualmente en un grado diferente: https://custom-elements-everywhere.com/)

• https://blog.revillweb.com/why-web-components-are-so-important-66ad0bd4807a
• https://medium.com/@velmu/go -long-on-web-components-b1e0689f64e4

Me complace ayudar a este proyecto a probar Vue o el componente web si es necesario.

Consulte también PR # 2463 para Gutenberg _ "Interoperabilidad de bloques agnóstica del marco (Vanilla, Vue)" _

Sugeriría inclinarse hacia Vue.js por un par de razones.

1. Historial comprobado dentro del framework PHP Laravel.
2. Parece ser fácil de aprender y adoptar para que más personas puedan contribuir.
3. Si nos estamos alejando de React, hagámoslo un cambio limpio y definitivo (Usar Preact parece que nos aferramos a él (React) en cierto sentido).

Solo mi opinión, pero parece que es la mejor opción y muchas otras personas parecen favorecer a Vue, ya que al menos es algo a considerar de todos modos.

Vue parece tener un mayor impulso y un mejor apoyo de la comunidad que Preact. Resuelve más problemas (porque viene con la gestión estatal) y tiene una curva de aprendizaje más suave. La documentación es _excelente_.

Mi preocupación con Preact es que es demasiado parecido a React para sentirse legalmente seguro (las patentes de React pueden cubrir Preact), y demasiado diferente a React para ser un puerto simple (hay _ suficientes_ diferencias para romper bibliotecas auxiliares, complementos, etc.).

¡Vue todo el camino bebé!

• [x] [Gitlab] (https://about.gitlab.com/2016/10/20/why-we-chose-vue/)
• [x] [HN] (https://news.ycombinator.com/item?id=14410190)
• [x] [PixelJets] (http://pixeljets.com/blog/why-we-chose-vuejs-over-react/)

Estrellas de Github -> Aquí
Estaría absolutamente encantado para el desarrollador de WordPress si Vue.js 🖖

Vue ha desarrollado una gran comunidad a lo largo del tiempo, además de actualizaciones periódicas del marco.

PD. únete a https://chat.vuejs.org para disfrutar de una experiencia de comunidad increíble ... algunos desarrolladores realmente tontos allí :)

@jbreckmckye No es mi intención descarrilar la conversación, pero ¿entiendes de qué se trata la cláusula de patente? Se trata de proteger a Facebook de las demandas de patentes de otras empresas. Por ejemplo, digamos que mi empresa fabrica refrigeradores inteligentes y usamos react en la interfaz de usuario. Digamos que tenemos una patente sobre esto, y luego FB comienza a infringir esa patente ... si demandamos, ya no podemos usar React.

No tiene nada que ver con las patentes en reacción (que ni siquiera estoy seguro de que Facebook tenga ... de lo contrario, preact, vue y cualquier otra persona con un marco similar ya habría sido demandado)

Como miembro principal de Vue.js, me gustaría abordar el problema del factor de bus. Sabemos que este es un punto que se ha planteado mucho en la actualidad, ahora estamos implementando medidas para abordar algunas de las preocupaciones.

1) Cuenta de organización de Vue.js para npm, para que podamos publicar como equipo más fácilmente
2) Gestión interna de detalles para mantener todo funcionando (sitios web, etc.)
3) Inicializar un colectivo abierto, para atraer a los colaboradores y apoyar a la comunidad en crecimiento. https://medium.com/the-vue-point/vue-is-now-on-opencollective-1ef89ca1334b
4) El ecosistema de Vue ha crecido rápidamente y cada vez más contribuciones del repositorio central provienen de la propia comunidad. https://www.youtube.com/watch?v=993X1kiisFE
5) Al mirar los repositorios oficiales de Vue, puede ver que en realidad muchos de ellos ahora son mantenidos en gran medida por otros miembros del equipo central más que Evan

En general, Vue.js está creciendo rápidamente y el 'Factor de bus' se ha reducido significativamente. Como señala @philiparthurmoore , Evan siempre tendrá una gran participación y eso es algo bueno.

Parece que hay muchos fans de VueJS aquí. ¿Alguien ha migrado realmente una gran base de código de React a Vue? ¿Cómo es la ruta de migración?

Por lo que puedo ver, Preact parece una opción mucho más pragmática dado que es API compatible con React. Mientras que migrar a Vue requeriría una reescritura mucho más extensa.

@patrickgalbraith Esa es en realidad la razón equivocada para considerar Preact. Debe juzgarse por sus méritos y no porque sea más fácil migrar a él. Puedo ver los siguientes problemas con Preact

• Comunidad más pequeña en comparación con VueJS
• Huele a código: la transición a una biblioteca muy similar puede forzar malas prácticas (por la razón obvia de que es la ruta más rápida)
• Seguir con Preact es como seguir con React de todos modos (léalo en un hilo)

Solo he usado Preact de manera limitada, así que esto es solo lo que creo.

@ blake-newman Gracias por pasar y aclarar eso. 💯

Debe juzgarse por sus méritos y no porque sea más fácil migrar a él.

Sip. Esta es una decisión a largo plazo.

@patrickgalbraith si todo el proyecto estuviera completo, lo consideraría un argumento justo. Ya que sería una pieza de migración para evitar problemas de licencias.

Como el proyecto aún se encuentra en sus primeras etapas, como @ahmadawais , es un problema menor.

Además, Vue, React y Preact tienen paradigmas muy similares. Puede cambiar fácilmente entre los dos, habrá diferencias.

También existen, aunque probablemente no del todo prácticas en este caso, herramientas que pueden ayudar a la paz migratoria. https://github.com/SmallComfort/react-vue

Aunque esto no está comparando las mismas herramientas, este artículo plantea grandes puntos a considerar. https://medium.com/unicorn-supplies/angular-vs-react-vs-vue-a-2017-comparison-c5c52d620176

@ blake-newman, ¿es realmente solo una etapa inicial, aunque teniendo en cuenta que tiene más de 6 meses de desarrollo? También tenga en cuenta que Calypso también tiene más de dos años.

De todos modos, estoy seguro de que no será un problema, ya que, dado lo que ha dicho, es fácil cambiar entre React y Vue. Estoy deseando ver la solicitud de extracción.

La plantilla también parece prometedora.

https://github.com/ionic-team/stencil-starter

Mi opinión es que estos 2 puntos son un argumento sólido para Vue:

• Apto para principiantes y ..
• Gran cantidad de apoyo comunitario

Ambos son, en mi opinión, 2 de los pilares centrales del proyecto WordPress.

Puede que esté solo, pero he estado observando a Patreon de Evan bastante de cerca durante los últimos seis meses, y decía que si no podía conseguir financiación, tendría que trabajar más.

Es un riesgo real cuando un proyecto tiene poca financiación Y está escrito básicamente por una persona (hace menos de seis meses). De hecho, sus números de Patreon han bajado recientemente. Si el principal dice que es posible que no pueda trabajar en ello si las finanzas no se alinean, entonces las finanzas son un riesgo muy real. La elección del marco de un proyecto grande a largo plazo que depende de si un desarrollador (increíble) puede pagar el alquiler de SF es un gran problema.

Por supuesto, Vue podría ser apoyado generosamente por otras compañías, pero es difícil saberlo.

La adopción comunitaria tampoco garantiza la longevidad del marco, chicos. Si no lo ha notado, los marcos "mueren" todo el tiempo.

Dicho esto, estoy impresionado de que un miembro del equipo central de Vue se haya presentado para abordar el problema del único contribuyente / el factor bus, incluso por su nombre, y haya dado algunas razones por las que el problema del desarrollo único podría ser un problema menor. Pero fue un problema real en un pasado muy reciente.

yo voto por Vue

• api simple / puedes aprender las cosas más básicas en menos de una semana
• implementación de flujo simple a través de vuex
• resultados rápidos: P
• comunidad en crecimiento
• MIT

Otro voto para Vue, por todas las razones expuestas anteriormente. ¡Mis disculpas a cualquiera que tenga activadas las notificaciones por correo!

@ michaelbdavidson7 , Vue finalmente contará con el aporte de Evan y la campaña de Patreon fue para ayudarlo a hacer más trabajo excelente con Vue. El no obtener suficiente a través de Patreon y asumir otro trabajo, no creo que ponga en peligro a Vue. Como sugirió @ blake-newman (un colaborador principal de Vue) (y el propio Evan hace un par de meses), Vue ya no depende de una sola persona. Tanto como WordPress no depende de una sola persona. Tenemos a Matt, sí, pero WordPress puede continuar en alguna encarnación sin Matt (lo siento Matt;)). Lo mismo es cierto para Vue (lo siento Evan;)).
@ahmadawais que también creo que no es exacto con respecto a la "dependencia de la persona clave".

Si se cumple este objetivo, puedo dedicar menos tiempo a pensar en canales de monetización privados (por ejemplo, aceptar contratos de soporte / consultoría) y, en cambio, trabajar más en contenido que beneficie a toda la comunidad de Vue ...

^ Ese objetivo no se cumplió y ni siquiera está cerca. Suponiendo que quiso decir lo que dijo, es posible que todavía esté pensando en contratar, y si eso cambia, entonces debería considerarse un desarrollo muy reciente. Todavía está ahí arriba a partir de ahora. Si la persona clave se contrata para pagar el alquiler, existe el riesgo de que no siga trabajando en el marco, y si eso cambia, ha cambiado muy recientemente.

Todos ustedes que solo gritan frameworks por su nombre no han aprendido nada en los últimos años jajaja.

@ michaelbdavidson7 Se cumplió el objetivo de ayudar a Evan a trabajar en él a tiempo completo. El objetivo adicional está ahí para ayudarlo a apoyarlo más y en parte a la comunidad. De ahí el nacimiento de la campaña colectiva abierta, que tiene como único objetivo apoyar a la comunidad.

También señalaré que la campaña de Patreon no es la única fuente de ingresos a través de contribuciones, desafortunadamente Patreon no es adecuado para que todas las empresas patrocinen. Por tanto, algunas contribuciones se pagan y facturan por separado.

La razón por la que el número bajó es porque uno de los patrocinadores era de China y hay un límite en la cantidad de dinero que se puede gastar en China en un año. Esto es solo temporal y con suerte volverá a ser compatible.

Los otros canales de ingresos que Evan obtiene a través de los talleres no solo son útiles para la comunidad, sino también para él. De esta manera, puede obtener una exposición directa para apoyar el aprendizaje de cómo será y se usará la biblioteca. Así que en realidad no es tan malo como parece.

Vue es sostenible y no hablo en nombre de Evan, pero estoy seguro de que está muy contento con la situación financiera actual.

Una cosa que sí aprecié de React fue su documentación de accesibilidad . Creo que esto es algo que hay que tener en cuenta y tener en cuenta al pensar en nuevos marcos. Hay principios de accesibilidad mencionados aquí que se aplican a cualquier aplicación web escrita de forma defensiva, pero tener alguna documentación específica del marco podría ser útil.

Vue.js tiene un problema abierto para la accesibilidad . Una mirada rápida a Preact y no veo mucho; ¿Es seguro asumir que se aplica la documentación de React?

En última instancia, sería genial tener un marco que simplificara y automatizara las pruebas programáticas para que podamos eliminar la mayoría de los errores y advertencias.

Si desea una transición fácil solo por la licencia, una opción que podría considerar es InfernoJS. https://github.com/infernojs/inferno ofrece casi la misma API con una huella más pequeña y un tiempo de ejecución más rápido. Tiene licencia del MIT. Soy uno de los mantenedores del infierno y podría ayudar con la transición.

@Havunen, gracias por

Por contexto, el autor de Inferno ha sido contratado por Facebook.

Voto por markoJS http://markojs.com/

Gutenberg usa algunas características nuevas de React 16, es decir, portales y posiblemente fragmentos , que tanto Inferno como Preact no admiten, por lo que podrían tenerse en cuenta cuando se habla de bibliotecas similares a React si el uso de estas características es fundamental para gutenberg.

Sugeriría DIO 8 principalmente porque es lo más parecido a React 16 en este punto en términos de API.

Dicho esto, podría ser un buen experimento de curiosidad configurar Gutenberg con alias de las bibliotecas similares a React mencionadas y ver si funcionan sin cambios / problemas para cualquiera que lo desee.

No estoy seguro de si son exactamente iguales, pero para los portales, existe vue-portal desarrollado por @LinusBorg , uno de los miembros principales del equipo de vue :)

@youknowriad Facebook me contrató. @Havunen y el equipo detrás de Inferno están haciendo un gran trabajo sin mí. El trabajo que están haciendo en Inferno es increíble y vale la pena echarle un vistazo al proyecto si tienes la oportunidad :)

Soy uno de los autores de Marko.js y me gustaría lanzar a Marko.js al ring para su consideración. Varios de los miembros de nuestra comunidad se comunicaron con nosotros y nos señalaron este problema de GitHub. Marko.js tiene una licencia MIT compatible con el código abierto y se está utilizando para construir eBay.com y tiene una comunidad fuerte y en crecimiento. Aporta una serie de buenas ideas de React y Vue, pero nos esforzamos mucho para hacer las cosas más simples y rápidas (a través de optimizaciones en tiempo de compilación) y eliminamos el texto estándar siempre que pudimos. Solo quería resaltar algunas de las características a continuación:

Componentes de la interfaz de usuario

El modelo de componentes de Marko es muy similar conceptualmente al de React (entrada, estado, enlace de eventos, eventos del ciclo de vida, renderizado de DOM virtual, diferenciación / parcheo de DOM, etc.). Una transición en Calypso no requeriría mucha sobrecarga cognitiva. Marko también admite componentes de interfaz de usuario de un solo archivo. Así es como se ve un componente de la interfaz de usuario de Marko:

class {
  onInput(input) {
    this.state = { 
      count: input.count || 0 
    };
  }
  increment() {
    this.state.count++;
  }
}

style {
  .count {
    color:#09c;
  }
}

<div.count>${state.count}</div>
<button on-click('increment')>
  Click me!
</button>

Sintaxis

Marko no usa JSX, sino un superconjunto de HTML que admite expresiones JS. Es muy similar a HTML, pero no se limita completamente a HTML como lo es Vue. Esto proporciona una sintaxis más agradable para cosas como bucles y condicionales y deja más claro dónde se usan las expresiones en comparación con una cadena HTML estándar. Creemos que las plantillas de Marko.js son extremadamente legibles y fáciles de mantener (Marko también admite una sintaxis concisa basada en sangrías).

Representación del lado del servidor

No sé qué tan importante es para WordPress, pero Marko también admite la representación del lado del servidor de alto rendimiento en Node.js con soporte para la representación asíncrona y de transmisión.

Otras lecturas:

• Marko vs Reaccionar
• Shootout de renderizado del lado del servidor con Marko, Preact, Rax, React y Vue
• ¿Por qué Marko es rápido?
• 10 impresionantes características de Marko
• Meetup: Creación de la interfaz de usuario: una comparación de React, Vue y Marko (del creador de Marko) - Vídeo | Diapositivas

¡Voto por Marko! 🙂

Si alguien del equipo de WordPress (@ahmadawais? @M? @Swissspidy?) Quisiera tener una charla rápida para responder cualquier pregunta sobre Marko, nosotros, el equipo de Marko, estaremos encantados de hacerlo. : call_me_hand: 😸

@ Comenté esto en el blog de @m , pero quería publicarlo aquí en una forma más pública:

Recomiendo el ecosistema Ember que incluye tanto Ember como Glimmer.js.
Para componentes web más pequeños, como editores directos y otros comportamientos de contenido, Glimmer proporciona una gran experiencia y crea componentes web drop in que pueden ejecutarse fuera de un marco.

Para proyectos más grandes como Guttenberg y Calypso, donde el enrutamiento, la administración de estados complejos, el control de acceso, la administración de contenido y más entran en juego: Ember proporciona el mejor conjunto de herramientas y ecosistema.
Con un gran conjunto de contribuyentes: los patrones establecidos, los complementos y el sistema de compilación de Ember ayudan a mantener las aplicaciones en funcionamiento y mantenibles a medida que las aplicaciones escalan.
Ember Engines y los complementos en repositorio ayudan a mantener las piezas opcionales de la aplicación modulares e instalables para los usuarios finales.

Ember está siendo utilizado en gran medida por otros sistemas de gestión de contenido y ese esfuerzo se puede aprovechar, aprender y compartir.
Como se mencionó en un comentario anterior en el blog de @m , Ghost usa Ember como administrador y editor, pero Ember también se usa con Drupal headless, Cardstack y compañías de contenido como Conde Nast , Bustle y más.
Esto significa que características comunes como listas de etiquetas, editores basados ​​en componentes (específicamente el editor de Mobiledoc ) y más están disponibles como parte del ecosistema Ember Addon .

Desde una comunidad y una experiencia de desarrollador, Ember se adapta mejor al ecosistema de Wordpress (como desarrollador que trabajó en Wordpress durante más de 5 años).
Ember tiene muchas mejores prácticas integradas, bien documentadas o disponibles a través de complementos; esto reduce la pregunta de "esto funcionará con mi aplicación" y ayuda a reducir mejor los posibles errores de seguridad o rendimiento.
Ember se basa en abstracciones personalizables, lo que significa que la complejidad se puede abstraer de los desarrolladores finales y el código difícil puede tener un alcance limitado para que la personalización sea fácil y divertida.
Los complementos de Ember coinciden estrechamente con los complementos y temas de Wordpress, ya que se descubren automáticamente y tienen una configuración predeterminada lista para usar, pero se pueden personalizar aún más para satisfacer las necesidades del usuario final.
Existe una herramienta de curación existente para Ember Addons llamada Ember Observer para ayudar a encontrar los complementos más populares, mejor mantenidos y más estables.

Calypso y Guttenberg son proyectos grandes y ambiciosos con necesidades maduras. La comunidad Ember tiene soluciones maduras para la accesibilidad, la internacionalización y otros requisitos de las aplicaciones web modernas.

Soy parte del equipo de aprendizaje de Ember.js y trabajo en estrecha colaboración con los colaboradores principales, me encantaría hablar o establecer una conversación con otros miembros del equipo de Ember sobre cómo Ember y Glimmer podrían satisfacer sus necesidades.

Me di cuenta de que se mencionaron los portales de React y me gustaría agregar otros 2 ¢ que Ember tiene un complemento bien mantenido llamado Ember Wormhole para proporcionar esta funcionalidad y muchos complementos se basan en esto para proporcionar características como diálogos, cambios en el encabezado del documento. , y más.

Votaría por Marko por su soporte nativo de renderizado asíncrono y su rápido rendimiento del lado del servidor.

@ patrick-steele-idem & @mlrawlings - gracias por

Profundizaré más.

Trabajé con Ember.js tanto en una organización empresarial muy grande donde las aplicaciones se ejecutaban dentro de otras aplicaciones como en una startup muy pequeña con pequeñas aplicaciones independientes. Las sólidas opiniones y convenciones de Ember.js han ayudado a mantener una base de código productiva y fácil de mantener a medida que crecen los equipos y las aplicaciones. No solo permite la capacidad de compartir código (a través de motores o complementos) entre proyectos, sino que también permite que un desarrollador que ha aprendido las convenciones sea productivo y contribuya a prácticamente cualquier aplicación de Ember.

El mayor beneficio de Ember ha sido su estabilidad sin estancamiento. Sin tener que cambiar ninguna de nuestras plantillas, obtuvimos enormes beneficios de rendimiento cuando se lanzó la nueva versión de Ember que había refactorizado totalmente el motor de renderizado que teníamos. Los niveles de abstracción parecen perfectos para las aplicaciones web ricas y modernas que pueden crecer y necesitan escalar en un futuro lejano.

Cuando los cambios son necesarios, la migración es una preocupación central y las guías de obsolescencia ayudan en cada paso del camino (más recientemente, el uso de transformaciones AST / CST de JavaScript para actualizar automáticamente las aplicaciones).

Otras aplicaciones web populares que usan Ember no mencionadas por @rtablada incluyen Twitch.tv , el tablero de Heroku , Travis CI y Discourse .

@SaladFork gracias por la actualización, comencé nombrando principalmente empresas en el ámbito de la gestión de contenido.

Algunos ejemplos de aplicaciones Ember de código abierto a gran escala incluyen:

• Travis CI
• Hospital Run : un sistema EMR (Electronic Medical Record) construido para uso sin conexión, especialmente en zonas de baja conectividad en África
• Fantasma

No estoy seguro de cuánto puede entrar en detalles, pero estoy haciendo ping a

¡Votaría por Marko por su rendimiento, flexibilidad y sintaxis muy clara y fácilmente comprensible!

+1 para Marko también. Después de haber hecho bien el trabajo de front-end antes de que comenzara a perder cabello y a encanecerme (como hace mucho tiempo), ha sido el marco / biblioteca de front-end que he estado buscando durante todos estos años. Es una gran razón por la que me encanta trabajar en eBay con @ patrick-steele-idem y @mlrawlings también.

Marko JS tiene mi voto. Extremadamente subestimado considerando su facilidad de uso y rendimiento.

Me encanta marko-widget junto con el eficiente marko. marco simplemente excepcional y delgado. Es mucho más rápido que otros marcos. Benchmark está aquí

Voto por MarkoJS, hemos sido una tienda de manillares durante muchos años.

Cuando hicimos el movimiento estratégico para ingresar a los microservicios y habilitar la arquitectura basada en componentes para nuestra plataforma, estábamos buscando el marco adecuado para tener un equilibrio entre la representación del lado del servidor y la representación del cliente. Somos una plataforma que tiene clasificados en 6 mercados diferentes, incluidos mercados emergentes como Sudáfrica y México, donde los datos son una gran preocupación y necesitamos tener un sitio que realmente respete los requisitos de navegación del usuario en dispositivos que tienen pocos años y que también usan menos datos. Además, el usuario navegará por el sitio de un lado a otro hasta que encuentre un artículo que le guste comprar, lo que significa que debemos tener una representación del servidor realmente rápida mientras el usuario navega.

Después de una cuidadosa consideración, elegimos MarkoJS con el hecho de que admite:

1. Representación rápida del servidor con buen rendimiento del servidor
2. Presiona el primer byte lo antes posible
3. Capacidad para construir componentes menores y representarlos de forma asincrónica cuando los datos estén listos
4. Capacidad para construir una arquitectura de componentes plug and play
5. Maximice el renderizado del cliente con la misma o mejor arquitectura de React / Vue.
6. Pruebas controladas por componentes que se pueden usar no solo para probar la renderización, sino también para el estado del componente

(Una historia de éxito de eBay Classifieds)

+1 para Angular (NO AngularJS).

Angular CLI es, con mucho, el mejor de todos los marcos, y con planes de migración reservados para una migración perfecta entre versiones, encajaría muy bien.

Plus Angular está muy bien adoptado en el ámbito empresarial, donde WordPress podría usar algo de amor si WordPress continúa creciendo como una plataforma para consultores y autónomos, y deja de ser solo una carrera hacia el fondo.

Tiene una comunidad sólida de desarrolladores de todos los niveles. Siempre es increíble hablar con el equipo central, ya sea que trabajen para Google o no. WordPress es en gran parte (para la mayoría de los desarrolladores de alto nivel) una comunidad en la que están involucrados, así que diré que, en lo que respecta a la comunidad, Angular encaja perfectamente

Recientemente hice una charla sobre Vue en entornos renderizados por servidor ( diapositivas aquí ), y habiendo trabajado con Vue en un entorno .NET durante los últimos meses, estoy convencido de que no hay otra opción para trabajar en entornos. como eso. Obtiene una combinación realmente excelente de poder componenteizar lo que debe extraerse en JS para una gran interactividad mientras permite que el back-end continúe controlando principalmente el sitio.

Lo que significa que es bastante perfecto para construir sobre lo que tiene WordPress ahora. Cualquier otra biblioteca JS renderizada por servidor probablemente requerirá node. Vue no lo hace; puede registrar un componente como <gutenberg-editor> y hacer que WordPress envíe literalmente <gutenberg-editor> en el HTML. Vue puede usar el HTML enviado por WordPress para iniciar la página. Es un poco como los componentes web en ese sentido, y no requiere otra pieza de tecnología BE para obtener la representación del servidor.

Es una de las razones por las que un marco como Laravel lo eligió como predeterminado: es muy fácil de integrar en back-end que no son Node. Creo que WordPress debería adoptarlo por las mismas razones.

Voté por Vuejs .
El mismo caso con @borantula en su comentario.

Mi CTO presentó Vuejs al equipo: recién llegados al Front-end, y rápidamente se involucran, ahora están contentos con Vuejs. Mi equipo usa WordPress en muchos proyectos.
Actualmente, estamos usando Vuejs y Custom Element para hacer el front-end para un proyecto que usa WordPress en el backend. Funciona muy bien.

Como han dicho @ blake-newman y Evan, Vuejs ya no depende de una sola persona clave, por lo que se puede decir que los CONTRAS que mencionó

MARKO funciona bien en nuestra aplicación web. El renderizado progresivo funciona de maravilla.

No puedo decir nada sobre Preact o MarkoJS (muy referido en los comentarios) pero puedo hablar por Vue como lo presenté a nuestro equipo (trabajando principalmente en php + jQuery en ese entonces) hace un año y gradualmente cambió su comprensión de javascript, salir del estado mental de jQuery.

Creo que sería una buena opción no solo para Gutenberg sino también para el objetivo a largo plazo de WordPress, la transición a una plataforma más orientada a API con más javascript en interfaces. Es una curva de aprendizaje más fácil y la familiaridad animará a otros desarrolladores de WP a intervenir también.

Vi cómo VueJS prospera en la comunidad de Laravel y casi se convirtió en una opción de facto para la mayoría, creo que también será así en la comunidad de WordPress.

Backbone.js

/ s

Quería dar mi apoyo a MarkoJS.

Hace dos años trasladé la infraestructura de mi empresa de ExpressJS y Jade (ahora PUG) a Marko JS. Mi empresa quería crear componentes complicados y reutilizables en todo nuestro ecosistema. Los desarrolladores querían velocidad y reutilización. Los diseñadores querían una carga de diseño reducida. No hemos mirado atrás desde entonces.

Ahora tenemos varios sitios web orientados al cliente escritos en Marko y también un sistema CMS completo.

Finalmente, elegí MarkoJS para lo siguiente:

• Procesamiento rápido del servidor incluso con marcos como Koa o ExpressJS
• Maneja la representación asincrónica de datos de página
• Capacidad para construir componentes plug and play para un ecosistema más grande
• Mejor rendimiento que React / Vue
• Sintaxis de plantilla extremadamente fácil

También me gustaría señalar que el equipo de MarkoJS ha sido literalmente estelar. @ patrick-steele-idem y @mlrawlings siempre han estado a bordo para instituir nuevas ideas, solucionar problemas y ayudar a las personas.

👍 para MarkoJS

Preact es una biblioteca compatible con React-API, lo que significa que Preact se beneficia directamente del ecosistema de React y de la gran cantidad de paquetes / componentes OSS disponibles. El ecosistema de Vue es mucho más pequeño en comparación. La documentación de los paquetes / componentes de Vue de terceros está en chino.

Por favor, no más "Voto XYZ", no hacen nada para agregar a la conversación, aparte de enviar respuestas innecesarias a las personas suscritas a este problema

🔥 Angular

• PRO: mayor competidor para reaccionar
  Para mucha gente. la pregunta es a menudo "Angular o React?" / "¿Reaccionar o Angular?". La comunidad Angular es posiblemente la más grande entre las alternativas de React y está creciendo rápidamente.

• PRO: muchos recursos de aprendizaje
  Además de los documentos y guías oficiales de API, Angular probablemente tiene el mayor ecosistema de materiales educativos, publicaciones de blog, libros y muchos cursos de video, tanto gratuitos como comerciales en todas las plataformas de aprendizaje principales, además de Google GDE que lo enseña en talleres y conferencias.

• PRO: se integra bien con Redux
  Ya sea directamente o a través de Ngrx habilitado por RxJS (apoyado por un miembro del equipo de Angular)

• PRO: el mejor soporte de herramientas de su clase

  • CLI tiene muchas más funciones que otras

  • Muy buen soporte de editor en VS Code, especialmente con el servicio de idiomas

  • Escrito para TypeScript, proporciona la mejor experiencia de TypeScript

• PRO: rico en funciones, obstinado y organizado de forma predeterminada
  La separación lógica a través de módulos angulares (NgModule), así como las funciones estándar para formularios, llamadas HTTP, enrutamiento, etc., facilita que otros desarrolladores lean el código y contribuyan a él.

• PRO: la mejor integración con RxJS
  Útil para muchas secuencias de API y muchas secuencias de eventos en una página en general

• PRO: sistema DI (inyección de dependencia) integrado
  Útil para crear puntos de extensibilidad y tal vez incluso un sistema de complementos, especialmente cuando se combina con RxJS

• PRO: Marca muchas otras casillas que cubren otras bibliotecas

  • Bibliotecas de UI con licencias permisivas
    Hay PrimeNg, Angular Material 2, ngx-bootstrap y muchos más ...

  • Carga lenta
    Soporte incorporado para rutas de carga diferida y también admite módulos de carga diferida manualmente

  • CSS específico del componente
    Garantiza que CSS tenga un alcance solo para el componente, se cargue solo cuando el componente esté cargado y tenga ganchos para CSS global

  • Representación del lado del servidor
    Ya estoy trabajando con Node y ASP .NET Core, y ahora me enfoco mejor

  • Pruebas
    Angular proporciona ayudantes de prueba independientes del marco de pruebas unitarias que hacen que las pruebas unitarias sean muy fáciles. Generan pruebas de forma predeterminada desde la CLI utilizando Jasmine, que se puede cambiar fácilmente a Jest. También proporcionan un transportador de envoltura de selenio opcional para facilitar las pruebas de E2E (aunque realmente no lo necesitas, yo uso Selenium .NET para mis aplicaciones angulares, nada específico de Angular, pero tratan de hacerlo aún más fácil).

  • Soporte móvil / PWA
    Google es el mayor partidario de PWA, y el soporte se muestra en Angular CLI ya con Service Workers y Universal (soporte del lado del servidor), e Ionic (soporte de Cordova) y NativeScript (aplicaciones nativas)

• PRO: Céntrese en la compatibilidad con el navegador
  Con una página de polyfills dedicada en los documentos, e insertando polyfills (comentados) de forma predeterminada en CLI, Angular lo mantiene al tanto de qué polyfills exactos necesita para, por ejemplo, IE <= 11, por lo que no necesita cargar un polyfill mucho más grande establecido sin motivo. Eso es porque se preocupan por la compatibilidad con el navegador.

• PRO: Respaldo de una gran empresa
  Angular es una de las pocas bibliotecas discutidas aquí (¿la única?) Que está respaldada por una gran empresa.
  Al respaldar aquí, no solo a una empresa que lo usó en algunos proyectos y contribuyó al ecosistema, sino que siendo mantenedores oficiales que pagan a los desarrolladores y redactores técnicos para que trabajen a tiempo completo e inviertan en líderes comunitarios (GDE y DevRel en el caso de Google).
  Esto es PRO, no un CON porque viene con una licencia MIT sin cláusulas adicionales, sin notas de revocación o cualquier otra cosa que pueda ser confusa o aterradora para algunas personas.

Implementé Vuejs para algunos proyectos como complementos, API REST. Debo decir que es fácil de aprender, tiene muchas características, una gran comunidad y su ecosistema también es bueno.

Hoy en día, Vuejs está creciendo rápidamente. Será una buena elección si Vuejs está integrado en el código de WordPress.

@cyberwani @thephilip @evoratec y otros.

@ntwb ya ha respondido el siguiente comentario:

Por favor, no más "Voto XYZ", no hacen nada para agregar a la conversación, aparte de enviar respuestas innecesarias a las personas suscritas a este problema

Entonces, por favor deje de hacer comentarios inútiles. Para mostrar su apoyo, puede usar github emojis para dar me gusta a un comentario que favorezca su biblioteca.

Vue.

Por cierto, ahora está Alibaba detrás de Vue, así como el proyecto Weex Apache que habilita la api de Vue en dispositivos móviles.

Realmente pondría algo de moderación aquí, demasiados fanáticos sin argumentos claros

Esta es la advertencia final, el siguiente paso es que comenzamos a eliminar comentarios ...

Yo, yo mismo, no he usado Marko, Preact o Vue.js, no estoy familiarizado con ninguno de ellos para ser honesto, me encantaría escuchar y leer lo que la comunidad de WordPress tiene que decir sobre estos marcos. cada uno de ellos, los méritos técnicos de cada uno, el ecosistema circundante de cada uno, las herramientas de construcción y, por último, pero no menos importante, las personas y comunidades detrás de estos proyectos. 😄

No quiero leer "Mi voto es para XYZ", si desea agregar un voto, desplácese hacia arriba y agregue una reacción emoji _thumbs up_ al marco de su elección que ya se mencionó anteriormente. 👍

No pasó mucho tiempo para que aparecieran dos nuevos comentarios desde mi comentario anterior 😞

Con ese fin ... Si su comentario se agregó después de https://github.com/WordPress/gutenberg/issues/2733#issuecomment -329705942 y todo lo que ha dicho es _ "Voto por XYZ" _ o envíe un mensaje de texto a eso efectuar sus comentarios tienen una muy alta probabilidad de ser eliminado, también serán eliminados en el futuro comentarios de la misma calaña.

Si vuelve a este tema y se pregunta por qué se eliminó su comentario, esta es la razón.

@ahmadawais Tengo algunos comentarios.

¿La migración de Gutenberg de React a ...?

Respecto a:

@patrickgalbraith Esa es en realidad la razón equivocada para considerar Preact. Debe juzgarse por sus méritos y no porque sea más fácil migrar a él. Puedo ver los siguientes problemas con Preact

• Comunidad más pequeña en comparación con VueJS
• Huele a código: la transición a una biblioteca muy similar puede forzar malas prácticas (por la razón obvia de que es la ruta más rápida)
• Seguir con Preact es como seguir con React de todos modos (léalo en un hilo)

Creo que cuando tienes un proyecto con un número no trivial de líneas de código, debes tener mucho cuidado. A los ingenieros les gusta reescribir cosas, aprender nuevos lenguajes y frameworks, y piensan que harán un mejor trabajo si pueden reescribir ese código ... Joel habló sobre el peligro de reescribir con bastante elocuencia hace mucho tiempo .
El uso de Preact le ahorrará mucho tiempo. Puede subestimar el tiempo que llevará pasar a un marco completamente nuevo. No estoy seguro de por qué escribió "Esa es realmente la razón incorrecta para considerar Preact". Como ingeniero, los costos y el tiempo de comercialización ocupan un lugar destacado en la lista de criterios que utilizo para evaluar y elegir soluciones.
Si el problema es realmente la patente de Facebook, Preact lo resuelve minimizando los costes. Preact es más eficaz que React e incluso Vue: ocupa menos espacio y más rápido el renderizado en tiempo de ejecución. Consulte también el escrito de Addy Osmani .

No estoy seguro de cómo evaluó el tamaño de la comunidad de Preact. Si estamos hablando del ecosistema y los componentes disponibles, usar Preact le permite usar la mayoría de los componentes de código abierto de React. Entonces, para una cuestión práctica, tiene personas que incluso si no están trabajando explícitamente en Preact, todavía están produciendo código que puede aprovechar. Todavía puede considerar el ecosistema de React como parte del ecosistema de Preact.

¿Por qué Vue sigue siendo tu opción favorita?

Creo que el tercer punto aquí "Seguir con Preact es como seguir con React de todos modos" es probablemente la razón principal por la que duda en elegir Preact. ¿Me equivoco? ¿Qué tiene de malo React además de su patente?

Mirando el panorama general

Leí que lo que elijas para Gutenberg también se usará para Calypso.
Gutenberg solo usa React en la interfaz. Cuando observa la representación del lado del servidor, la situación se vuelve más compleja, pero Preact aún parece una opción de migración más fácil.

Creo que debes tener en cuenta tus criterios. Si está considerando seriamente una reescritura y mantener la representación isomórfica es importante, MarkoJS parece estar en lo alto de la lista de candidatos.

Si comencé desde cero y estaba dispuesto a ignorar el ecosistema React, MarkoJS es una obviedad.

Estoy mirando las actuaciones y MarkoJS parece no tener rivales . 40x más rápido que Reaccionar, 10 veces más rápido que el Vue y 6x más rápido que Preact es una locura. En mi libro, las mejoras del 30% son irrelevantes, pero cuando tienes una mejora de más de 10 veces, debes prestar mucha atención.
Cuando tiene una presencia modesta y exitosa y puede usar 10 servidores en lugar de 100, o 2 en lugar de 20, hace una gran diferencia.

Revelación completa No tengo ningún vínculo emocional ni con Preact ni con MarkoJS. Simplemente creo que tienen más sentido que las alternativas de una ingeniería prospectiva.

Buena suerte con tu decisión 😃

@ChrisCinelli esos son números

Soy del mundo Drupal (estamos viendo este número: D), así que no tengo nada que ver con esto. Pero leyendo los comentarios, es obvio que hay alrededor de 5 frameworks "top" aquí y a todo el mundo le gusta el que han elegido, así que lo apoyarán.

El aspecto de la velocidad es irrelevante en estos días, de verdad. Los únicos dos factores que deben tenerse en cuenta son a) ¿Realmente quieres reescribir todo yb) cómo será la transición para los desarrolladores de React y cómo será el aprendizaje del fw ganador para los nuevos desarrolladores?

Hay capas preact-compat, inferno-compat ... para facilitar la transición, pero el rendimiento se verá afectado. Por otro lado, hará que la transición sea más elegante con el tiempo, no es necesario reescribir todo a la vez. Desde el punto de vista empresarial, esto es una obviedad. Desde el punto de vista de la comunidad y el futuro, no hay diferencia.

Ahora el DX es donde está todo. Cualquier persona con experiencia en fws reactivos no debería tener problemas para realizar la transición a un nuevo fw simplemente porque los conceptos son los mismos, solo que la sintaxis difiere. Pero el novato, ese es el que importa. Qué tan difícil / fácil es ser productivo en un nuevo fw. Qué tan difícil / fácil es leer y comprender el código existente. Y esto se basa únicamente en a) buena documentación yb) comunidad (foros, SO, salas de chat, blogs ...).

No diré qué FW preferiría ya que, como he dicho, no soy un tipo WP. Pero quería dar mi 2c para mantener la cabeza fría cuando se trata de una decisión tan importante que influirá en miles de desarrolladores de todo el mundo.

@ntwb: yo no tenía mi comentario eliminado, pero creo que los comentarios eliminación, incluso aquellos de los muchachos del ventilador, como una especie de censura.

Por qué:

Si su comentario se agregó después del número 2733 (comentario) y todo lo que ha dicho es "Voto por XYZ" o un mensaje de texto en ese sentido, sus comentarios tienen muchas posibilidades de ser eliminados, también se eliminarán los comentarios del mismo tipo en el

Veo muchos comentarios de fans por encima de eso. ¿Por qué se quedan?
Parece un doble rasero.

Angular, es una elección clara. Creo que Roy y Meligy hacen puntos fantásticos y los apoyan al 100%. WordPress se está moviendo hacia el ámbito empresarial no solo en uso, sino también en términos de la metodología de su desarrollo.

Voy a vincular una fuente divertida: https://vuejs.org/v2/guide/comparison.html y en particular: "... la complejidad de Angular se debe en gran parte a su objetivo de diseño de apuntar solo a grandes y complejos aplicaciones ... ". Esa simple declaración da en el clavo. WordPress es, y su dirección futura seguirá siendo, una aplicación compleja y robusta.

@ChrisCinelli Simplemente porque fue entonces cuando le pedimos a la gente que se abstuviera de decir "Voto por xyz", entiendo de dónde vienes, pero creo que eliminar esos comentarios sería una mala forma, no me agrada el hecho de tener que hacerlo. eliminar cualquiera de ellos

No traje esto antes porque no quería atacar marcos que no recomendé (habiendo recomendado Angular arriba), pero solo para completar, hay algo que debe borrarse con Preact y otras bibliotecas similares a React . Lo pondré aquí, y depende de WordPress decidir si es una preocupación.

La siguiente es una cita de una publicación escrita por un abogado de patentes / propiedad intelectual en la licencia de React (el resaltado en negrita se copia de la fuente):

He recibido un montón de "bueno, entonces usemos [marco alternativo aquí]". Espera un segundo. Si las patentes de Facebook cubren React (diffing, componentización, etc.), esas patentes probablemente cubran Preact / Vue / et al.

¡Pero React te otorga una patente! Con un marco alternativo, eres un infractor desde el primer día. Todo esto se reduce a si Facebook tiene patentes y su deseo de hacerlas cumplir, pero si quieres hacer un juego de guerra en este grado, las alternativas de React son más riesgosas .

Ahora, si mi entendimiento es correcto, WordPress no dejará React porque esté preocupado por la licencia en sí, sino solo por tener que llevar esta licencia a sus usuarios y, por lo tanto, traer la confusión y la necesidad de defenderse a sí mismo.

Al optar por una alternativa de React, es posible que haya menos que defender si la licencia alternativa es permisiva, pero también puede haber cierta confusión en WordPress.

Depende de WordPress decidir si esto es algo de qué preocuparse o no.

@ChrisCinelli gracias por su crítica constructiva. Le doy la bienvenida con las manos abiertas.

Como ingeniero, sé que el costo y el tiempo ocupan un lugar destacado en la lista. Pero esta es la cuestión. Este no es un proyecto de una empresa corporativa en particular. Los objetivos aquí son diferentes.

El objetivo es encontrar un JS FW que sea bueno para la comunidad. Gutenberg aún no se ha lanzado. Si funciona, entonces Preact habría sido el claro ganador.

Ahora mismo debemos ocuparnos de esto:

• JS FW es fácil de adoptar para la comunidad más amplia
• JS FW que elijamos debe tener su propia comunidad y ecosistema
• Un historial probado con un software FOSS de producción basado en PHP es una ventaja. Vue + Laravel
• Elegir JS FW en función de sus méritos y no solo porque es más fácil migrar a

En los 11 años que he pasado con WordPress, y como colaborador principal habitual, creo que elegir Preact crearía un gran lío. La curva de aprendizaje ya es enorme para los desarrolladores intermedios / nuevos.

Hacerlos pasar por el lío de la compatibilidad Preact-React justo al comienzo de esta nueva fase de mejora de WordPress puede hacer que abandonen la comunidad de WordPress y aprendan algo más con la curva de aprendizaje similar. (_ SUGERENCIA_: Laravel + Vue en lugar de WordPress + Preact + React) Y por cierto, ¿estás olvidando que eso es lo que sucede con Drupal 8?

No elimines los comentarios civiles. Evidentemente, existe una necesidad o un deseo abrumador de expresar una opinión sobre este tema. Lo veo como algo bueno ya que las personas dicen que se preocupan por WordPress y quieren ser escuchadas. Recuerde que la comunidad de WordPress, no solo sus desarrolladores, fueron dirigidos a Github para dar sus comentarios. Si realmente no podemos tolerar los comentarios +1, agregue un recuento en la parte superior que conserve los nombres de usuario.

Si solo busca una discusión razonada, muchos de los comentarios de "Yo voto por X, Y o Z" pueden parecer un ruido, pero hay un patrón claro emergente de personas que apoyan Vue.js. Mi opinión al respecto es que tenemos un centenar, o unos pocos cientos, de personas que contribuirán con el código a Gutenberg, pero decenas de miles que escribirán complementos y temas que interactúan con él. El éxito de Gutenberg no será solo la experiencia del usuario final, sino también la experiencia del desarrollador. No es lo único, pero una cosa importante que hace que WordPress sea exitoso es que es fácilmente extensible.

Si bien no tengo un marco específico en mente, diría que una cosa que debemos tener en cuenta es que el soporte del navegador está comenzando a encajar con los componentes web, un marco que utiliza componentes web o al menos sus propios componentes construidos como ellos serían a prueba de futuro. También existen polyfills para llevar componentes web a navegadores que no lo admiten.

Me mencionaron anteriormente y solo vine aquí para desactivar las notificaciones, pero lo consideraré un poco.

Si está creando una aplicación de una sola página desde cero, el tiempo es esencial y desea un marco bien respaldado, documentado y comprobable, tengo muchas experiencias concretas que demuestran que es mucho menos costoso en tiempo y tesoro para ve con Ember.

Si está creando más de una PWA o colocando componentes en una página renderizada por el servidor, Ember es una mala elección, y puedo ver por qué algo como Vue sería atractivo.

Agregaré eso desde un lado impulsado por la convención, he creado algunas PWA con> 90 puntajes de faro usando Ember.

En nuestro último proyecto en el que necesitábamos hacer esto, el proceso tomó menos de 1 hora para obtener esa puntuación de faro e implementar la aplicación con la representación del lado del servidor habilitada.

El SSR y el caché de trabajador de servicio necesarios para puntajes de faro altos pueden ser un proceso muy complicado.
Con Ember, este proceso es muy fácil y solo requiere la instalación de algunos complementos bien documentados y mantenidos (para la mayoría de las aplicaciones).
Desde mi experiencia, Preact viene con estas dos características listas para usar en Preact CLI, sin embargo, existen convenciones populares (P) React que pueden romper los resultados de SSR.
Con Vue, los documentos oficiales recomiendan usar Nuxt.js o seguir la guía completa de SSR ; ambos introducen más patrones que deben seguirse más allá de la documentación básica de Vue.

No regañar a nadie, pero dejemos de eliminar comentarios sobre problemas a menos que sean blasfemias o abusivos. Tengo gente que quiere ayudar y enfocar la conversación, pero no deberíamos entrar en la espiral de eliminar comentarios.

No estoy seguro de qué está "bien documentado" sobre Ember en comparación con VueJS @rtablada .

Personalmente, tendría un problema al comenzar a Ember en comparación con Vue o incluso React.

@ahmadawais Todo el mundo olvida que esta decisión tendrá un gran impacto y querrá cambiar el marco de todos modos dentro de unos años. Por lo tanto, le gustaría usar la bondad del marco moderno pero no estar atado a él para vivir o morir. ¿Suena imposible? ¡No es!

Hace algún tiempo tuve un problema similar y, después de investigar e intentar, se me ocurrió una solución que intenta conectar el agua con el fuego. En pocas palabras: elementos personalizados de Web Component, tecnología de envoltura que le gusta (por ejemplo, Vue, React, Angular) y exponer la API DOM estándar.

En dicha solución tendrá múltiples componentes y cada uno de ellos tiene:

• marco que te gusta (pero, por supuesto, preferiblemente solo uno)
• API DOM estándar que otros componentes pueden consumir fácilmente. Incluso puede manipularlo a través de JavaScipt simple

Mientras trabajaba con Vue en ese momento, escribí el adaptador de Custom Element para Vue - https://github.com/karol-f/vue-custom-element - para que tenga una compatibilidad superior (por ejemplo, el evento DOM estándar $ emit send de Vue que puede capturarse a través de JS simple o, por ejemplo, React / Angular) y compatibilidad con IE9 +.

Recomiendo mirar una solución como tú:

• será a prueba de futuro
• no estará vinculado con ningún marco que elija hoy
• sus usuarios verán elementos HTML estándar y pueden interactuar con ellos con el marco que les gusta o incluso con JS simple
• No habrá inicialización manual de Vue, ya que el navegador le dirá y el componente de inicio automático si está en la página (incluso puede cargar el componente de forma diferida de esa manera)

y muchos más.

Dicha solución no está vinculada con Vue; puede usar cualquier otro marco que desee. Además, los elementos personalizados de Web Component son una función estándar del navegador y no se irán a ninguna parte.

¡Saludos!

Mi opinión al respecto es que tenemos un centenar, o unos pocos cientos, de personas que contribuirán con el código a Gutenberg, pero decenas de miles que escribirán complementos y temas que interactúan con él. El éxito de Gutenberg no será solo la experiencia del usuario final, sino también la experiencia del desarrollador. No es lo único, pero una cosa importante que hace que WordPress sea exitoso es que es fácilmente extensible.

Citando el comentario anterior de @dmccan porque es un punto muy importante en apoyo de Vue.

WordPress ha democratizado más que la publicación. Me pregunto cuántas carreras y negocios tecnológicos exitosos se han lanzado debido a la accesibilidad de WordPress. Mía, seguro.

Voy a tirar mi sombrero a favor de VueJS. La reunión local de JavaScript aquí es codirigida por uno de los miembros del equipo central de VueJS y parecía ser la que las personas que asistieron podrían integrarse mucho más rápido que otras. Mi experiencia anterior fue con AngularJS y descubrí que VueJS era increíblemente más fácil de aprender y simplemente comenzar a codificar a pesar de que estaba comenzando desde cero.

Veo que algunas personas están hablando de empresas y, por lo tanto, de Angular, pero si bien WordPress puede necesitar algo de amor en esa área, creo que la decisión debe basarse en la funcionalidad y, aparte de eso, en la facilidad para incorporar desarrolladores. Con las discusiones que hemos visto sobre las metacajas y todo eso, conseguir que los autores de complementos "Gutenberg-ify" su trabajo en lugar de simplemente abandonar si / cuando el editor clásico desaparece.

Algunos puntos más que vale la pena mencionar sobre

• PRO No requiere necesariamente un transpilador o fuerza cómo se usa y puede ejecutarse directamente en la web como jquery puede

Esto ayudaría sorprendentemente a los desarrolladores de complementos a integrarse con la interfaz de usuario de Wordpress. Pueden adjuntar una nueva instancia de vue a cualquier parte de la página como un widget. También un gran proyecto de Wordpress puede adoptar progresivamente con Vue.js sin la necesidad de grandes cambios en la base del código, ya que vue no asume cómo se usará. Creo que esta es la clave del éxito por la que Laravel / Vue es tan popular y funciona bien juntos :)

• ¡PRO JSX y css-in-js también son compatibles!

Puede ayudar a la migración de proyectos actuales de WordPress con código React / JSX más rápido a vue.js con menos requisitos de cambio. (incluso hay un complemento de babel: babel-plugin-transform-react-to-vue )

• FACT Vue al igual que Preact y, a diferencia de Angular / React, no es un proyecto de código abierto propiedad de una gran empresa como Google o Facebook.

Esto sería algo fundamental para que un proyecto ENORME como Wordpress escape a un posible bloqueo de un proveedor. Si un proyecto de código abierto que no es propiedad de una empresa, alguien debería iniciarlo (por lo tanto, la "dependencia de la persona clave" no tiene sentido mencionarla como una CON ).

Voto por VueJS.
No porque sepa algo al respecto, sino porque no tengo ni idea de cómo se pronuncia en inglés. Sin embargo, utilicé Joomla durante años y lo pronuncié mal todo el tiempo.

Broma aparte.
No muchos aquí discuten qué marco es mejor para admitir metaboxes antiguos y campos personalizados. React fue muy malo en eso, como sabemos ahora.

Ahora, solo para cancelar la suscripción a este número.

Para enfocar la discusión, he creado un problema de tarea aquí: https://github.com/WordPress/gutenberg/issues/2741

Sugeriría Vue, solo porque Laravel. Mucha gente de WordPress que no está contenta con el curso que tomó o que aún toma, ha cambiado al uso de Laravel como su marco principal de CMS, mientras mantiene WP como la segunda opción. Preact es solo un clon y una capa de compatibilidad masiva, algo así como Novell DOS era para MS DOS, PC DOS y viceversa.

cu, w0lf.

¡Vue.js hasta el final!

Ciertamente deberías mirar Hyperapp .
Pros

1. Es muy similar a la arquitectura Elm (modelo, vista, actualización).
2. Tiene incorporado Redux como Reductores llamados "acciones" (llamados para actualizar el modelo y, a su vez, Vista).
3. Utiliza JSX
4. Fomenta los diseños de "programación funcional"
5. Tiene 1 kb, por lo que es fácil de cargar y de entender.

Contras

1. Todavía es nuevo y también lo es el ecosistema. Pero puedes influir en él y contribuir a él.
2. Puede haber problemas que aún no se han descubierto.

Los principios de los bloques de Gutenberg encajan perfectamente con los de los componentes web . Es de bajo nivel, agnóstico al marco y un estándar emergente (con polyfills maduros y probados): el ajuste perfecto para WordPress.

Ver también: Polímero - Componentes Web con algo de azúcar.

Vue es una opción fantástica, y aquí están las razones por las que creo que sí:

Comencé a ver Vue a principios de 2016. Me encantó y quería determinar si alguna vez tendría "demanda" o si su crecimiento era algo digno de mención. En ese momento tiene 16.000 estrellas en Github. Fue genial y todo, pero la gente realmente no se había adaptado a él en medio de toda la basura de Angular vs React.

Terminé perdiendo _todos_ mis datos y comencé de nuevo el 17 de septiembre de 2016. Hace exactamente un año, hoy. ( Aquí está mi conjunto de datos actual )

Durante el último año, he visto crecer la popularidad de Vue (en términos de menciones en Internet y seguimiento de estrellas de Github) a un ritmo _record_break_. Vue ha acumulado 40.000 estrellas en 365 días. Eso es un promedio de 109 por día. En comparación, el amado _React_ creció de 49.000 a 75.000 en este mismo período de tiempo. (71 por día) Vue superará a React en los próximos meses, en términos de calificaciones de usuarios.

Si bien todo el mundo hablaba de que el crecimiento de React era el más increíble de todos los tiempos, no sabían que Vue era el verdadero campeón. No sabían que Vue estaba creciendo debido a que a la gente realmente le encantaba como herramienta, en lugar de a un respaldo famoso (Facebook).

Vue ha estado en la lista de repositorios de tendencias de Github todos los días durante más de un año. El 99% de los días está por encima de React. El 10% de los días, React no hace el corte.

Todo esto grita "¡usa Vue porque ha tenido más crecimiento en popularidad!" Pero lo que quiero transmitir es que Vue ha crecido porque a la gente realmente le encanta porque es una herramienta excelente, intuitiva y poderosa (a menudo presentada incorrectamente como "excelente para aplicaciones pequeñas") para aplicaciones de todos los tamaños. Pero no solo una herramienta. Vue es un ecosistema. También viene con una comunidad de apoyo masiva.

¿Puedo agregar ... los archivos .vue son geniales. Se están construyendo tantas herramientas para manejar el estilo en React porque aparentemente hay algo mal con los módulos CSS y con sus estilos en un archivo externo. (Idk ...) Pero Vue no tiene este problema. Vue tiene declaraciones de control integradas en la sintaxis, y (dado que he visto comentarios de elementos personalizados arriba) no solo funciona bien con elementos personalizados ... Es _ una biblioteca / marco para elementos lógicos personalizados.

Preact es genial. Honestamente, hoy comencé otro proyecto con él. Pero cuando miro Preact, veo un React fuera de marca. No fue construido para ser innovador o para progresar en la forma en que creamos software basado en la web. Fue creado para verse y actuar como una herramienta preexistente, pero para ofrecer un mejor rendimiento.

Esos son mis dos centavos. Ahora estoy arruinado.

Espero que su decisión final lo haga feliz y proporcione una gran base para el futuro de sus productos.

@ahmadawais :

• El tiempo de comercialización es importante para proyectos empresariales y de código abierto. Puede encontrar ejemplos de proyectos que nunca se enviaron porque terminaron tardando demasiado y siendo obsoletos antes de ser enviados. Algunos proyectos terminaron siendo abandonados durante el trabajo hacia un lanzamiento importante.
• Oponerse a Preact significa "cometimos un error con React por razones más allá de la licencia". Creo que con "La curva de aprendizaje ya es enorme para los desarrolladores intermedios / nuevos", querías decir que los desarrolladores de wordpress ya estaban perdidos con React. Eso no me sorprende. Pero parece difícil creer que Vue, aunque sea menos detallado, resolverá los problemas de la curva de aprendizaje. El antiguo motor PHP WP y cualquier marco javascript de aplicaciones de
  No estoy seguro de por qué ve competencia entre Wordpress y Laravel. Puede que sea ingenuo aquí. Sé muy poco sobre la historia de Drupal 8.
  Desde mi punto de vista, Wordpress es un CMS y atrae a los desarrolladores debido a su gran base de usuarios de usuarios no técnicos y las características ya incorporadas. Hay muchas plantillas y los desarrolladores pueden crear rápidamente un nuevo sitio que sea personalizable por alguien que no sea desarrollador.
  Laravel es un framework PHP que, hasta donde yo sé, no te brinda muchas de las características de un CMS. Un desarrollador lo elegirá porque necesita más libertad.
• No estoy seguro de cómo tener algunos éxitos con Vue + Laravel también significa "Vue es bueno para Wordpress". Creo que hay muy poca sinergia intrínseca entre PHP y cualquier framework JS. Estoy completamente de acuerdo en que es importante encontrar un marco que sea bueno para la comunidad. Si la mayoría de la comunidad de desarrolladores actual de la que depende WordPress está familiarizada con Vue y les encanta, esto tiene un gran peso en su decisión final.

Desde una perspectiva de ingeniería, creo que tanto Marko JS como Vue son marcos más nuevos. Aprendieron mucho de React y pudieron eliminar parte de la verbosidad en él. En ese sentido, Marko parece eliminar incluso más código repetitivo que Vue. En particular, Marko mantiene un código cohesivo que es bueno mantener en el mismo lugar y dejar en HTML para qué sirve HTML y en Javascript para qué sirve Javascript. Y también es 10 veces más rápido. Entonces, aparte del hecho de que últimamente Vue tiene muchos fanáticos, no veo muchas razones para preferir Vue a Marko.

Lo siento, pero la sintaxis y la configuración de Marko son horribles en comparación con VueJS. En cuanto al rendimiento, no he visto ninguna fuente en la que MarkoJS sea más rápido de manera significativa sin agregar tiempo para comprender cómo funciona.

La sintaxis de la versión que introdujo la sintaxis actual de Marko fue muy bien recibida por nuestros usuarios.

Pensamos mucho en la sintaxis de Marko para asegurarnos de que sea familiar para los desarrolladores que entienden HTML y JS y queríamos que fuera lo más simple y poderoso posible con un mínimo de repetición. Creo que encontrará que con cualquier comparación lado a lado, la plantilla de Marko requerirá menos código (lo cual es excelente para la legibilidad y el mantenimiento).

Aquí hay un documento que preparé rápidamente para que pueda ver una descripción general de las diferencias entre la sintaxis de Marko y la sintaxis de Vue:

Sintaxis: Marko vs Vue

Lo vinculé antes, pero para una comparación más profunda entre Marko y Vue (y React), consulte:

Meetup: Creación de la interfaz de usuario: una comparación de React, Vue y Marko (del creador de Marko) - Vídeo | Diapositivas

En cuanto al rendimiento, tenemos algunos puntos de referencia que puede consultar: https://github.com/marko-js/isomorphic-ui-benchmarks

Aquí hay una ejecución rápida de los puntos de referencia con Marko y Vue habilitados:

Rendimiento de representación del lado del servidor

_Node.js ( v8.4.0 ) _

Running "search-results"...

Running benchmark "marko"...
marko x 5,180 ops/sec ±2.09% (87 runs sampled)

Running benchmark "vue"...
vue x 135 ops/sec ±3.81% (68 runs sampled)

Fastest is marko

Running "color-picker"...

Running benchmark "marko"...
marko x 10,206 ops/sec ±0.72% (87 runs sampled)

Running benchmark "vue"...
vue x 1,664 ops/sec ±5.20% (66 runs sampled)

Fastest is marko

Rendimiento del lado del cliente

_Chrome versión 63.0.3218.0 (compilación oficial) canary (64 bits) _

Running "search-results"...
Running benchmark "marko"...
marko x 351 ops/sec ±1.18% (58 runs sampled)
Running benchmark "vue"...
vue x 206 ops/sec ±1.61% (57 runs sampled)
Fastest is marko

Running "color-picker"...
Running benchmark "marko"...
marko x 7,516 ops/sec ±2.90% (41 runs sampled)
Running benchmark "vue"...
vue x 4,593 ops/sec ±3.03% (54 runs sampled)
Fastest is marko

Esos son los puntos de referencia que creamos para Marko.js, así que obviamente tomamos esos resultados con un grano de sal, pero hicimos todo lo posible para ser justos.

Además, solo quería agregar algunos comentarios más sobre Marko.js y la facilidad de uso:

Marko siempre ha tenido como objetivo tener la integración más simple con Node.js. Después de instalar el paquete marko a través de npm, aquí está todo el código necesario para representar una plantilla en un flujo de respuesta HTTP:

require('marko/node-require'); // require .marko files!

const http = require('http');
const template = require('./template');

http.createServer().on('request', (req, res) => {
  template.render({
    name: 'Frank',
    count: 30,
    colors: ['red', 'green', 'blue']
  }, res);
}).listen(8080);

Creo que eso es lo más simple que puedas conseguir.

Marko también trabaja con paquetes de módulos de JavaScript populares: http://markojs.com/docs/bundler-integrations-overview/

Para representar un componente de interfaz de usuario de Marko de nivel superior en el DOM, aquí es todo lo que se requiere:

require('./fancy-button')                  // Import the Marko UI component
  .renderSync({ label: 'Click me' })   // Render the button with the provided input
  .appendTo(document.body);         // Mount the UI component to the DOM

@ patrick-steele-idem Según http://www.stefankrause.net/wp/?p=431 benchmarks, markoJs
es tan eficaz como Vue et al.

Por lo tanto, podemos concluir que, en general, las secuencias de comandos del lado del cliente, Markojs y Vue tienen el mismo rendimiento.

Por supuesto, el punto de referencia, vinculé, no incluye ssr. Así que no comentaré sobre eso.

Voto por Vue. jQuery ya es un requisito cercano para usar WordPress. Las personas familiarizadas con jQuery deben familiarizarse con la sintaxis de Vue. Su ideología sobre el DOM no es tan extrema como algo como Angular. Se basa en el principio de WordPress sobre la facilidad para el usuario.

Como sugerí hace unos dos años para Calypso , Mithril.js usando la API de HyperScript sería una buena opción para reemplazar React. Tiene una licencia estándar del MIT.

Una pequeña inversión en nuevas herramientas para hacer al menos parte del trabajo pesado automáticamente para convertir de React a otra biblioteca de vdom puede dar buenos resultados en las horas de desarrollador ahorradas, como se menciona en ese número como una sugerencia que Automattic debe hacer antes de la cobertura. su apuesta por React.

Incluso sin considerar las bibliotecas que no son de vdom, hay más de 25 bibliotecas de vdom (por ejemplo, inferno.js, maquette, etc.) que podrían considerarse, como en esta lista que reuní

Aquí hay algunas razones técnicas por las que Mithril.js u otros vdom que enfatizan (o al menos admiten) la API de HyperScript son las mejores opciones.

Personalmente, creo que los enfoques de creación de plantillas para crear interfaces de usuario basadas en JavaScript como el enfoque de plantillas de React's JSX o Angular o los sistemas de plantillas en muchos otros sistemas de interfaz de usuario, incluido Vue, son obsoletos. ¿Por qué? Las preferencias y las "mejores prácticas" para escribir aplicaciones web basadas en plantillas HTML generadas en el lado del servidor utilizando hojas de estilo CSS complejas (como para los complementos anteriores de WordPress) se están convirtiendo en las "peores prácticas" para escribir aplicaciones web de una sola página. Las necesidades técnicas para escribir aplicaciones modernas complejas del lado del cliente de una sola página son diferentes a las del código principalmente basado en servidor debido a la creciente complejidad del código del lado del cliente. En resumen, las viejas "mejores prácticas" de usar plantillas y hojas de estilo complejas en cascada simplemente no se escalan, lo que conduce a un código difícil de mantener.

¿Cuál es la alternativa emergente? Las aplicaciones web modernas pueden usar Mithril + Tachyons + JavaScript / TypeScript para escribir componentes en archivos individuales donde todo el código es solo JavaScript / TypeScript. Estas aplicaciones no necesitan estar escritas parcialmente en CSS o en alguna variante no estándar de HTML que reimplementa parte de un lenguaje de programación (mal). (Bueno, puede que se necesite un poco de CSS personalizado además de Tachyons o bibliotecas similares, pero muy poco).

Aquí hay un ejemplo de un campo de juego de codificación que escribí de esa manera con varios ejemplos que usan ese enfoque.

Entonces, al escribir UI usando HyperScript (más una biblioteca vdom), potencialmente (con algo de trabajo) puede reemplazar un backend como Mithril con casi cualquier otro vdom o incluso una solución que no sea vdom. Entonces, cuando tengo la opción, elegir usar la API de HyperScript es una forma en que mitigo el riesgo de que las bibliotecas subyacentes tengan errores o problemas de licencia.

Al usar Tachyons o bibliotecas similares, mitigo el riesgo de archivos CSS que no se pueden mantener a medida que la aplicación crece.

Por supuesto, sé que muchos desarrolladores web crecieron modificando HTML y aman las plantillas de aspecto HTML. Por lo tanto, aman JSX o lo que sea y están felices de ignorar lo difícil que es refactorizar esas cosas que no son de código en medio de sus aplicaciones o validarlas. Por supuesto, algunos IDE están mejorando en la refactorización de plantillas JSX. Pero llegué al desarrollo web desde el escritorio y el desarrollo integrado trabajando con sistemas en los que (generalmente) generaba IU directamente desde el código (por ejemplo, usando Swing, Tk, wxWidgets, etc.). Me gusta la idea de que las herramientas estándar pueden ayudarme a refactorizar todo el código en el que trabajo y detectar muchas inconsistencias.

Suponiendo que todos los marcos que se ejecutan aquí no tienen diferencias visibles para el usuario debido a su velocidad en el navegador de su elección, podemos dejar de usar el rendimiento de la interfaz como una métrica para evaluar qué marco es la mejor opción.

Pero si utilizamos el renderizado del lado del servidor, deberíamos observar detenidamente el rendimiento de SSR. Calypso parece que apunta a tener SSR. Y si tiene éxito, algún día Calypso ejecutará la mayoría de los sitios en wordpress.com.

Una empresa paga por la CPU en los servidores, no la CPU en los navegadores. Entonces, desde una perspectiva de costos, el tiempo de renderizado 10 veces más rápido de Marko probablemente significa que el mismo tráfico que alcanza un máximo de 10 servidores con MarkoJS, en realidad tomará al menos 100 servidores que ejecutan Vue.

Si Wordpress puede ignorar eso, con mucho gusto vendré a trabajar para la empresa y obtendré un salario de mercado 10 veces mayor y usaré Vue que, por cierto, creo que es una buena alternativa de React =)

Cuanto más ligero sea el marco, es decir, menos funcionalidad ofrece de fábrica, más rápido funcionará. Es patéticamente obvio. Una cosa es comparar el rendimiento de varios algoritmos, pero cuando el factor más importante es la cantidad de otras "cosas" que se realizan, no es necesario escribir pruebas.

https://hueniverse.com/performance-at-rest-75bb8fff143

@ahmadawais Equipo central de Angular aquí: estamos en progreso en una gran cantidad de trabajo interesante relacionado con el desarrollo de estilo CMS / Widget, incluida la inversión en el soporte de Elementos personalizados (que, por mi dinero, es la apuesta futura inteligente para la construcción de plataformas)

En lugar de saturar aún más el hilo, estaremos encantados de chatear con todos ustedes sin conexión, si tienen algún interés. Envíeme un mensaje a robwormald en google punto com. Mucha suerte en esto, no envidio que tengas que hacer esta llamada ;-)

He creado una simple encuesta aquí que se puede utilizar para obtener información sobre lo que la gente quiere ...

actualmente trabajando en la página de resultados y autenticación en ella. (nuevo en firebase)

PD. tomó alrededor de 1 hora hacer esto usando Vue 🖖

@vinayakkulkarni ¿Qué tal si agregas Mithril.js a tu encuesta?

@pdfernhout : 👍

Hecho. Agregué MithrilJS a la lista.

• [x] VueJS
• [x] Angular
• [x] Preact
• [x] Ascuas
• [x] Marko
• [x] Infierno
• [x] Aurelia
• [x] Mitrhil

Veamos qué decide la gente ...
PD. También hubo una encuesta en Twitter por @ahmadawais .

Hola. Soy un mantenedor del núcleo de Drupal. Como @ivanjaros mencionó en un comentario anterior, también estamos evaluando Preact, Vue o algo más, para algunas partes futuras de la interfaz de usuario de administración de Drupal. Podríamos conformarnos con algo diferente a lo que usted elija, pero lo que elija sin duda será al menos un factor que debemos considerar en nuestra elección.

Abrí estos dos números de Drupal hasta ahora, y vendrán más. Simplemente haga referencias cruzadas aquí en caso de que esos temas / discusiones sean útiles para usted.

• componentes que devuelven múltiples nodos raíz
• tragamonedas frente a accesorios de vnode

Tenga en cuenta que todavía me gusta mucho Vue, a pesar de esos dos problemas. Esas pueden ser cosas con las que estamos de acuerdo para vivir, para obtener todos los demás beneficios de Vue.

Como autor de Vue, evitaré hacer comentarios sobre qué marco elegir aquí, ya que obviamente estoy sesgado; pero como vi la declaración de que "Marko es 10 veces más rápido que Vue" lanzada unas cuantas veces, creo que merece una aclaración. Tampoco quiero descarrilar la discusión en un debate técnico, por lo que he anotado algunos pensamientos en esta esencia para aquellos que estén interesados.

@ michaelbdavidson7 con respecto a las preocupaciones financieras: he estado trabajando en Vue a tiempo completo durante más de 1,5 años y el soporte de Patreon ha sido realmente estable. En lugar de especular sobre las fluctuaciones de los compromisos de Patreon, puede verificar la actividad de compromiso de Vue para juzgar por sí mismo. Además: tener un canal de contribución financiera abierto significa que WP / Automattic puede garantizar fácilmente la sostenibilidad de Vue al convertirse en un patrocinador importante (¡el mismo Matt ya es un patrocinador personal!), Lo que en realidad se alinea con los intereses de ambos proyectos.

Yo voto Vuejs

@ tungbt94 ¿

Definitivamente VueJS

La pregunta más importante, ¿por qué se eligió la reacción antes de esta cuestión de patente? Si no fuera una patente, ¿seguiría usando react? Muchos puntos sobre NO elegir preact son los mismos que no elegir reaccionar.

Mi voto es con Preact

Como no tengo mucha experiencia con nada más que React, no voy a opinar sobre qué marco elegir.
Sin embargo, creo que el argumento de la "gran comunidad" es uno que puede ser de menor importancia. ¿Por qué? porque cuando Automattic se decide por un marco, ese trabajo agrícola obtendrá miles de nuevos usuarios. Y si sé que la comunidad de WP es correcta, muchos de ellos también comenzarán a contribuir a ese marco y la popularidad aumentará.

Teniendo en cuenta dónde están Gutenberg y Calypso en este momento, sigo pensando que Preact es la mejor opción de ingeniería.

Sin embargo, si todavía te sientes fuerte por quemar puentes con algún parecido con React o si tuviste que empezar desde cero, sigo creyendo que MarkoJs es la mejor opción. Creo que el apoyo de la comunidad puede seguir siendo una preocupación.

Suponiendo que las estrellas de Github estén correlacionadas de alguna manera con la comunidad, Vue sigue siendo 10 veces mayor en comparación con MarkoJs, pero mirando los gráficos cambiará rápidamente.

Vue está creciendo linealmente:

Pero MarkoJs parece estar en el punto de inflexión de un crecimiento exponencial:

@ patrick-steele-idem, el autor principal de MarkoJs , siempre ha sido muy receptivo en https://gitter.im/marko-js/marko

Cuando la gente finalmente elige MarkoJs , pero realmente cualquier tipo de comunidad, me apetece parafrasear la cita de JFK: "No preguntes qué puede hacer la comunidad por ti, pregunta qué puedes hacer tú por la comunidad".

Personalmente, me gustaría felicitar a @ahmadawais por crear un solo problema que ha generado un compromiso significativo de muchos desarrolladores de JS que usan y respaldan las opciones relevantes de JS Library.

Sospecho que este problema ha ayudado a informar a más desarrolladores de JS sobre los movimientos de WordPress hacia un desarrollo más basado en JavaScript a través de Gutenberg que cualquier otra comunicación de Gutenberg hasta ahora.

Uso AngularJS pero lo que no me gusta es la actualización principal cada vez, así que iré con VueJS.

+1 para Marko. Gran biblioteca que nuestro equipo usa y con la que ha estado muy contento. Renderizado asincrónico, superrápido (renderizado en cadenas en el servidor y vdom en el navegador), componentes de uno o varios archivos y, en mi opinión, la mejor sintaxis de plantillas que existe.

Tenga en cuenta el hiperHTML de @WebReflection .

Me gusta Angular

Yo voto angular

Yo elijo angular

solo angular

Yo elijo angular

angular

Yo voto angular

Yo voto angular

Si desea votar por un marco, sería bueno saber la razón exacta y cómo ayuda a Gutenberg.

A los píos que vienen aquí para decir "Yo voto X", por favor, dennos algunas razones por las que deberíamos votar X también. "Yo voto X" no nos dice nada aparte de que te gusta X.

Elijo angular. Angular tiene un gran cambio desde la versión 2. Ahora, es un marco completamente, bueno, fuerte y ampliamente utilizado, ya que, al igual que el iónico, no se estudia rápidamente, sino con fuerza.

Con tanto spam "Votoframework ”, github está chillando por mí.

Insto a los desarrolladores a que voten amablemente su elección de marco en https://vinayakkulkarni.github.io/poll/ https://vinayakkulkarni.github.io/poll/ en lugar de simplemente publicar 'Yo voto ...';

Además, otra sugerencia es bloquear esta conversación; la mayoría de los desarrolladores importantes ya han expresado su opinión al respecto.

El 18 de septiembre de 2017, a las 8:01 p.m., Mingyue [email protected] escribió:

Elijo angular. Angular tiene un gran cambio desde la versión 2. Ahora, es un marco completamente, bueno, fuerte y ampliamente utilizado, ya que, al igual que el iónico, no se estudia rápidamente, sino con fuerza.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/WordPress/gutenberg/issues/2733#issuecomment-330241898 , o silencie el hilo https://github.com/notifications/unsubscribe-auth/AS3FbT23DvVwTLGL61tmK7KtuwZeg- ucks5sjn7SgaJpZM4PYie9 .

gracias @kidwm por mencionar _hyperHTML_, pero creo que es mejor seguir su dirección:

No solo comparta qué marco JS le gusta, sino también por qué

así que déjame intentar hacer eso ...

: zap: hyperHTML :

• PRO : amigable para principiantes y familiar para los usuarios de P / React (en lugar de JSX, escribe literales de plantilla)
• PRO : increíblemente rápido y sin VDOM; menor consumo de memoria (compatible con teléfonos de mercados emergentes)
• PRO : no requiere herramientas (requiere literales de plantilla transpilados solo para IE <11)
• PRO : Totalmente basado en los estándares JS / DOM / HTML pero también compatible con TypeScript
• PRO : cabe en menos de 5K (con cremallera mínima) sin necesidad de rellenos de polietileno o parches de navegador adicionales
• PRO : cobertura de código del 100% hasta las peculiaridades de IE9
• PRO : comparte la misma API con su contraparte NodeJS ; 100% compatible con renderizado del lado del servidor
• PRO : puede adoptar DOM existente sin destruir los diseños / nodos SSR
• PRO : funciona con elementos personalizados mejor que P / React, también se puede utilizar para definir elementos personalizados
• PRO : puede hacer lo que React , Vue.js , Polymer , Angular o Marko hacen, y gana en términos de tamaño / ancho de banda / rendimiento cada uno de ellos

Ahora, de acuerdo con las métricas utilizadas hasta ahora en este hilo, los CONTRAS

• CONTRAS : incluso si ha sido probado en batalla, completamente cubierto por pruebas y con una API congelada, es un proyecto relativamente joven (marzo de 2017), por lo que no puede competir en términos de popularidad, adopción o cantidad de contribuyentes
• CONTRAS : la comunidad está ayudando mucho y el proyecto está creciendo, pero el mayor contribuyente técnico hasta ahora soy yo. Sin embargo, estoy 100% comprometido con este proyecto y estoy dispuesto a impulsarlo tanto como pueda, además estoy discutiendo con algunos "_bigs_" sobre el uso de _hyperHTML_ en algunos de los próximos grandes proyectos de ellos (no especularé más aunque siéntete libre de ignorar esta última parte)

: dart: Realmente creo que el futuro de la Web es usar la plataforma tanto como sea posible, que es definitivamente mucho mejor que hace 10 años, y gracias a las especificaciones modernas de ECMAScript, es mucho más fácil de escribir, leer y mantener. _hyperHTML_ representa el "estado actual del arte web" en términos de potencial, mientras que todos los demás contendientes de esta lista nacieron en la era anterior a la ES6 completa.

Entiendo que el tamaño de la comunidad, los contribuyentes y las estrellas de GitHub son importantes, pero creo que las pruebas, la cobertura de código entre navegadores y la cantidad de errores también deben considerarse, y estoy haciendo todo lo posible para mantener la cuenta de _hyperHTML_ y amigos cerca de cero (en realidad es cero en este momento, además de una discusión que no es un error).

Por último, pero no menos importante, si nadie le da una oportunidad a las nuevas soluciones y juzga solo por las estrellas y las exageraciones, las nuevas soluciones tardarán más de lo que deberían en hacerse más populares.

Por supuesto, he hablado sobre mi última solución, mis consideraciones pueden considerarse subjetivas, pero especialmente mi última oración sobre dar una oportunidad a nuevas soluciones, fue muy general, no solo sobre mis bibliotecas: smiley:

Atentamente

Me gusta angular

debe ser angular y google.

me encanta angular

¡Angular es solo un marco real!

Elijo Angular, no AngularJs.

¡Solo angular es un marco real!

Empiezo a sospechar, estos comentarios los hacen los bots.

@OP :

Voto por Angular (NO AngularJS).

Angular es una plataforma, el equipo de Google hace un gran trabajo para facilitar el progreso del desarrollo, incluido el componente, el módulo, el enrutador, con la inyección de dependencia, puede ahorrar mucho trabajo para organizar toda la dependencia, con angular-cli, puede ahorrar mucho trabajo para comenzar un nuevo proyecto, simplemente abre la caja y su aplicación está bien compilada con aot, tree shaking y muchas otras optimizaciones.

TypeScript es otra gran herramienta con angular, es proporcionada por MicroSoft, también conocido como toda la plataforma angular está construida con ts. ¡Tú también creas tu aplicación con ts! Es una gran herramienta para hacer la vida más fácil cuando la cantidad de código se hace cada vez más grande, puede hacer una refactorización en el IDE (como vscode) con un solo clic. La verificación de tipos estáticos le permite encontrar los errores lo antes posible. TS también proporciona una buena implementación de OOP, puede organizar y reutilizar su código de una manera mucho mejor.

También hay muchos componentes construidos en base a angular, como el diseño de materiales2, primeng, y quiero recomendarte Jigsaw , que es creado por nuestro equipo. Es adoptado por el producto Big Data de ZTE China. Es compatible con todas las aplicaciones de ZTE ahora.

¡Anglar es una gran elección!

Para todos los bots: 🖕

Probablemente alguien publicó en una comunidad AngularJs. Creo que las personas pueden silenciar el hilo si no quieren recibir más mensajes.

Creo que eventualmente una conversación similar sobre este tema tendrá que ocurrir en un lugar donde solo haya colaboradores de WordPress.

Me gustaría compartir algunos de mis pensamientos sobre este tema que ya he expresado en su mayoría en el grupo de la comunidad Slack de EmberJS, si tiene 10 minutos para leer la discusión allí, lo recomendaría: https://embercommunity.slackarchive.io / wb-marketing / page-2 / ts-1505456102000189 Hay bastante ahí, pero recomiendo encarecidamente que lo revise para obtener una comprensión matizada de la discusión.

Mis puntos principales en esa discusión son los siguientes:

• Al comparar un pico de 2-4 semanas de implementación de algo en el marco de Ember con cualquier otra biblioteca, las otras bibliotecas tienden a ganar a corto plazo, pero Ember gana para cualquier proyecto a más largo plazo.
• Al considerar qué biblioteca o marco usar, es importante no solo considerar la implementación técnica sino también los aspectos de "habilidades blandas" (tamaño de la comunidad, compromiso de apoyar LTS, participación de la comunidad en las decisiones centrales del proyecto)
• Ember tiene un historial de proporcionar mejoras importantes a las aplicaciones creadas con ember-cli "bajo el capó", es decir, sin necesidad de actualizar ninguno de los códigos de la aplicación. También ha habido casos de actualizaciones menores en el código de la aplicación (con mod de código incluido que usa cosas como ember-watson ), obtiene un aumento significativo en el rendimiento y la productividad.

No quiero entrar en demasiados detalles en este comentario porque felizmente podría escribir un ensayo de 10,000 palabras sobre los puntos anteriores. Sin embargo, me gustaría ofrecer mi tiempo a cualquiera que quisiera discutir este tema con alguien que tenga una "mentalidad de Ember".

Si alguno de los responsables de la toma de decisiones quisiera tener una llamada de una hora conmigo para hacer preguntas más específicas sobre el ecosistema más amplio de Ember, con mucho gusto lo haría. Puede comunicarse conmigo en mi Twitter (DM abiertos). Puede que no sea un miembro del equipo principal, pero he estado creando aplicaciones de Ember desde antes de 1.0 y he pasado por todos los procesos de actualización con varias aplicaciones 👍

Trabajo para "Mi eBay" en eBay. Acabamos de lanzar nuestra primera aplicación de una sola página . Disfrutamos de cada fase de desarrollo utilizando MarkoJS. Como yo, si te encanta el paradigma de programación de transmisión de node, entonces MarkoJS admite transmisión y renderizado asincrónico. Otros datos que me gustaron de MarkoJS:

• su enlace eficiente del comportamiento de los componentes de la interfaz de usuario representados en el servidor y en el navegador.

• Delegación de eventos muy eficiente

• Serialización rápida del estado del servidor al navegador

@vinayakkulkarni Creo que tu idea es buena, pero el problema es que puedo dejar más de 1 voto cambiando de navegador (no lo he probado con el mismo navegador).

Probablemente debería usar una encuesta de Twitter (pero ya hay una) o implementar un sistema de inicio de sesión para que los votos sean únicos.

La representación del servidor no es relevante para la conversación aquí. Node no se convertirá en parte de la pila de WordPress requerida, por lo que la rapidez con la que se procesan estos marcos en Node no es relevante para una decisión.

Vue.js! mira este proyecto https://github.com/bstavroulakis/vue-wordpress-pwa

Elegí Angular (no AngularJS), tiene la comunidad más grande, un ecosistema estable y completo.

Angular es muy lento y con v4 basado en mecanografiado, es inútil para el desarrollo de wordpress.

Elijo Angular por la madurez de la plataforma.

Votaría por Vue porque es más fácil de aprender y porque mi marco favorito Ember Js es demasiado grande para el trabajo y Glimmer Js es todavía demasiado nuevo. :-)

La representación del servidor no es relevante para la conversación aquí.

en mi caso, acabo de mencionar una característica que otros pensaron que era relevante

Node no se convertirá en parte de la pila de WordPress requerida

_hyperHTML_ puede recoger cualquier contenido renderizado del lado del servidor, incluido PHP. Soy un ingeniero certificado por Zend y ya he trabajado con periodistas / editores que utilizan WordPress, mi pista no fue inesperada.

por lo tanto, la rapidez con la que se procesan estos marcos en Node no es relevante para una decisión.

el hecho de que un marco también funcione en el backend, puede recoger el contenido renderizado del lado del servidor, y sería incluso compatible con NativeScript, tal vez sea una ventaja que es irrelevante hoy en día, pero una característica agradable compatible en el futuro, como podría considerar un proyecto de mente abierta.

@webreflection No molestarte en particular. Es más en respuesta al comentario de arriba que destaca el "paradigma de transmisión" de Marko, pero tenía la intención de cubrir todos los comentarios sobre el rendimiento de renderizado de BE.

Ver

@mAAdhaTTah de https://ma.tt/2017/09/on-react-and-wordpress/ :

Esa publicación no se publicará, y en su lugar estoy aquí para decir que el equipo de Gutenberg va a dar un paso atrás y reescribir Gutenberg usando una biblioteca diferente. Es probable que retrase a Gutenberg al menos unas semanas, y puede llevar el lanzamiento al próximo año.

Y mas importante:

Automattic también usará lo que elijamos para que Gutenberg reescriba Calypso

Calypso ya está utilizando la representación del lado del servidor. Ver: https://github.com/Automattic/wp-calypso/blob/master/server/render/index.js#L58

Entonces, según tengo entendido, los resultados de SSR son relevantes.

Me encanta angular también！
Marco real de AngularJS js！

Yo voto por Angular

@chriscinelli Eso es Automattic, no WordPress. WordPress en sí mismo no hace renderizado de servidor con nodo, por lo que el rendimiento en esas condiciones no es relevante para el proyecto.

Obviamente, Angular es la mejor opción

Yo voto por Angular

Yo voto por Angular

Voto por Vue.js.
Ahorra la mayor parte del tiempo, especialmente cuando se trata de la capa de vistas.

Debo votar por Vue !!!

Lanza una ola de angulares

@trotyl Ese comentario es inaceptable. He editado tu comentario para eliminarlo.

oh, por favor no AngularJS
ahora es Angular.

@mAAdhaTTah De wikipedia:

WordPress fue lanzado el 27 de mayo de 2003 por sus fundadores, Matt Mullenweg y Mike Little como una bifurcación de b2 / cafelog

Aunque desarrollado en gran parte por la comunidad que lo rodea, WordPress está estrechamente asociado con Automattic , la empresa fundada por Matt Mullenweg.

Este es Calypso: https://developer.wordpress.com/calypso/ y Calypso usa SSR.

Como escribí en mi comentario anterior , está bastante claro en la publicación del blog que elimina el soporte de ReactJS por parte de Matt que quieren mantener a Gutenberg y Calypso alineados con la misma tecnología. Automattic servirá las páginas de Calypso desde sus servidores con SSR.

Creo que esto es suficiente para que el desempeño de SSR sea relevante en esta decisión.

Sin embargo, en un futuro lejano, una vez que los desarrolladores de Wordpress se acostumbren a Preact (o Vue o Marko u otro marco), puede surgir un nuevo proyecto loco y ellos deciden servir aún más partes de Wordpress a través de node. Eso hará que SSR sea aún más importante. Por tanto, el rendimiento de SSR puede ser incluso más importante.

Como la conversación ha pasado a discutir SSR, creo que es prudente mencionar que esto es una prioridad muy alta para Ember y que se ha pensado bastante con la llegada de Ember-Fastboot.

Si bien uso Fastboot (con gran efecto) con algunas aplicaciones cliente, ya que esta es una discusión de tecnología de alto nivel, recomendaría contactar a @tomdale ya que él fue el campeón del esfuerzo Fastboot 👍

@chriscinelli WordPress el proyecto comunitario y Automattic la empresa siguen siendo entidades separadas. Si Automattic quiere argumentar a favor de uno u otro debido a SSR, pueden, pero aún así no cambia la forma en que nosotros, la comunidad de WordPress, deberíamos considerar el marco de elección para el núcleo de WordPress, que no lo hace, y realmente no puede, requiere que el nodo se ejecute.

De todos modos, me he dado de baja de este hilo. Si desea continuar esta discusión sin conexión, mi correo electrónico está en mi perfil.

no requiere, y realmente no puede, que el nodo se ejecute.

Por favor, no hagamos de la capacidad SSR un punto de discriminación. Los marcos capaces de SSR de nodo pueden vivir sin ningún SSR de nodo: es solo una característica adicional, no un requisito ni una dependencia.

Votaría por Vue.js

Soy un arco senior que fue al MIT y se supone que soy razonablemente inteligente. He estado haciendo esto durante muchos años y entrevisté a algunos desarrolladores aquí y allá. Sé que la web está llena de gente inteligente, pero cualquiera que piense que la simplicidad de Vue está a la par con la complejidad de Angular ha perdido la perspectiva de lo que constituye "complejo". El Javascript basado en componentes, como lo ha concebido Google, no es nada trivial. Es ridículamente complejo. Vue no lo es. Vue es tan fácil como PHP. Digo lo obvio, porque "Vue es más fácil de aprender" ni siquiera se acerca a describir cuánto más fácil es Vue que Angular. Y aquí está el truco: creo que también es mucho más fácil que React.

React estaba caminando en la línea entre easy-peasy y google-level, para la gente promedio. Para tiendas pequeñas, diría que React es lo suficientemente complejo como para desafiar a equipos pequeños. React es más complejo que, por ejemplo, PHP / Wordpress. Al elegir React, Wordpress / Automattic elevó los requisitos para que los desarrolladores ingresen al mundo de los desarrolladores de Wordpress. Estoy seguro de que cientos de personas gritarán: "Reaccionar es fácil" y "La web se está volviendo más inteligente", pero lo más complejo es aún más complejo, al final del día.

Creo humildemente que volver a Vue estaría más cerca de las raíces de WP y menos una carga técnica para la comunidad de WP en su conjunto. Dejando de lado los paradigmas web, a veces, lo simple es bueno.

Angular y Vue son 2 cosas diferentes

Vue, React, MarkoJS, Inferno, Preact, etc.son bibliotecas que cubren solo la capa de vista. Todos ellos, incluido Angular, tienen una forma de crear el HTML y mutar el DOM de forma declarativa. Angular quiere proporcionar un marco completo para el desarrollo de frontend y tiene muchas más cosas más allá de la capa de vista.

La sintaxis de React es la más antigua de esta muestra. Facebook hizo un buen trabajo al vincular una biblioteca muy compleja que hace muchas cosas (quizás demasiadas) en una superficie de protocolo muy limitada. No necesitas conocer nada de esta complejidad dentro de React para saber cómo usarlo y ser productivo con él. De hecho, puede aprender lo básico y comenzar a usar en medio día.

Todas las demás bibliotecas de esta lista aprendieron de React. Intentaron simplificar la sintaxis, mejorar el rendimiento de React, reducir el tamaño del código Javascript necesario para hacer las mismas cosas y agregar algunas características encima.
Preact hizo un gran trabajo para mantener una interfaz muy similar a React en solo 3Kb.
Inferno y Marko optimizaron enormemente las prestaciones de renderizado.
Marko y Vue simplificaron mucho la sintaxis para reducir el código repetitivo.
Marko también agregó una sintaxis similar a Jade / Pug opcional para mantener el código más SECO y la capacidad de crear plantillas asincrónicas manteniendo todo simple e intuitivo para el usuario.

Sin embargo, todas estas bibliotecas además de Angular requieren que los ingenieros desarrollen una estrategia y mecanismos para obtener datos, enrutamiento, etc. Redux y sus middlewares son una forma popular que Gutemberg usó para administrar la capa de datos.

En la migración de React, Gutenberg no necesita "simplemente otra cosa para cambiar". Incluso si Angular se esforzó por mantenerse agnóstico para el usuario, usarlo con Redux y Javascript (frente a Typescript) no es una opción natural a pesar de que bibliotecas como https://github.com/angular-redux/ng-redux se desarrollaron y admiten para Javascript está disponible. Además, mirando los votos hasta ahora, parece que la comunidad de Gutenberg se opone firmemente al marco de Google. Así que lo más probable es que Angular no sea una opción.

PHP y cualquiera de estos frameworks de Javascript son bestias completamente diferentes

Puede tener un backend PHP y un frontend de aplicación de una sola página, pero no hay sinergia y hay pequeñas similitudes.

Cualquier aplicación de Javascript tiene al menos un orden de complejidad por encima de lo que puede tener escribiendo código PHP simple salpicado de jQuery. Todas las aplicaciones modernas de Javascript tienen que lidiar con los dos grandes monstruos de complejidad: estado y flujos asincrónicos . Solo se ven mitigados por la inmutabilidad y async / await en estos últimos años. El flujo del desarrollador se ralentiza a medida que crece la aplicación. Cuando cambia algún código, debe volver a compilar, reiniciar y la aplicación debe volver a iniciarse. Se ha construido una gran cantidad de herramientas para implementar recargas en caliente e incluso si son increíbles, todavía están lejos de ser perfectas.
No importa qué biblioteca elija para la capa de vista, tendrá que lidiar con la complejidad adicional.

En PHP, cambia el código, guarda un archivo y puede recargar inmediatamente la página sin compilar ni recargar. Todo funciona. Y PHP más importante es completamente sin estado . Cada vez que recargas la página tienes una pizarra en blanco. Incluso las variables globales tienen un estado limpio con cada solicitud (pero no es una buena excusa para usarlas = P). No he escrito código PHP en algunos años, pero todavía extraño su simplicidad y su experiencia como desarrollador. Si utiliza un framework moderno como CakePHP, Symphony o Laravel, no se perderá mucho en comparación con otros lenguajes y frameworks que son más bien recibidos por ingenieros sofisticados. La excepción es la velocidad. PHP paga su simplicidad con rendimientos en tiempo de ejecución. Cada vez que recargas una página, es necesario volver a ejecutar todo el código. Los rendimientos aumentaron mucho con HHVM y PHP7, pero en general aún están lejos de lo que puede lograr con node.js.

Conclusión

No importa qué biblioteca haya utilizado recientemente para la interfaz. Incluso si te encanta, no significa que sea la mejor opción para Gutenberg.
Sin embargo, el hecho de que a la mayoría de los colaboradores principales de Gutenberg les guste una biblioteca específica es importante.

En el final:

Un hombre convencido contra su voluntad sigue teniendo la misma opinión.

Creo que hay una cantidad bastante sustancial de información en este hilo sobre los pros y los contras de diferentes bibliotecas viables.

Los contribuyentes de Gutenberg y Wordpress deben dejarse solos, pueden reunirse en "puertas cerradas", lejos de los fanboys frontend.
Puede ser el momento de aclarar sus valores, objetivos y limitaciones que tiene y elegir el marco basado en lo que maximiza su resultado.

Y buena suerte de nuevo con tu decisión 😃

Emití mi voto por Vue. Apto para principiantes y robusto. Cuando comencé a usar Vue, tuve la sensación que tenía cuando comencé a desarrollar con WordPress. + 💯

@ tonos de colores sólo para principiantes no es lo suficientemente bueno! Cada proyecto tiene un ciclo de vida, la mayor parte del trabajo está en el progreso de mantenimiento.

@ChrisCinelli Algunas aclaraciones y opiniones:

Angular quiere proporcionar un marco completo para el desarrollo de frontend y tiene muchas más cosas más allá de la capa de vista.

Vue tiene bibliotecas oficiales para enrutamiento, administración estatal, pruebas, linting y más, además de una herramienta cli oficial. Todos ellos están bajo la organización de vuejs, mantenidos por miembros principales y sincronizados con Vue mismo, pero la mejor parte es que no es necesario aprenderlos o usarlos (de ahí la filosofía del 'Marco Progresivo'). A diferencia de React, esto efectivamente lo convierte en un marco en su forma oficial. Pequeño juego de palabras: todo esto sin dejar de ser más fácil de aprender, más rápido y más ligero que Angular. :sonreír:

Marko también agregó una sintaxis similar a Jade / Pug opcional

.vue archivos

Requerir que los ingenieros elaboren una estrategia y mecanismos para obtener datos.

Este es solo un ejemplo, pero la obtención de datos no necesita ser diseñada en exceso:

async created () {
  const result = await fetch('/api/items')
  this.items = await result.json()
}

Desde allí, puede crear un complemento de Vue muy simple para hacer que el código sea aún más conciso.

Vue en sí no debería ser la biblioteca adecuada para este trabajo, ya que siempre habrá mejores bibliotecas dedicadas (esta es también la razón por la que no ofrecemos filtros de fecha de forma predeterminada, por ejemplo, ya que terminaría usando moment u otra gran biblioteca de todos modos) . También estamos en el proceso de escribir un libro de cocina con rutas y prácticas recomendadas para varios negocios y casos de uso.

Cuando cambia algún código, debe volver a compilar, reiniciar y la aplicación debe volver a iniciarse.

La única diferencia real es el paso de compilación, que es fácil de configurar hoy en día utilizando herramientas como el vue-cli oficial o poi . Cuando guarda un archivo, la aplicación está casi instantáneamente lista para actualizarse (los tiempos de compilación también son muy buenos para proyectos grandes, y por experiencia, desarrollar una aplicación PHP grande usando un marco como Symfony es más doloroso). Además, la función Hot Module Remplacement es una gran ventaja que no existe en el mundo PHP (que yo sepa) y permite que el nuevo código esté disponible para probar en el navegador en un tiempo casi instantáneo incluso en proyectos grandes (a menos que tenga operaciones costosas como compilar Sass, pero tendría el mismo problema al usar PHP). Por cierto, Vue soporta muy bien el paquete web HMR.

Tendrá que lidiar con la complejidad adicional.

En mi humilde opinión, algunos frameworks PHP muy populares parecen ser más complejos y más difíciles de aprender que algunas bibliotecas / frameworks frontend como Vue. (Lo contrario también es muy cierto).

Según mis más de 2 años de experiencia en la construcción de un editor basado en bloques similar a Gutenberg, creo que hay varias preocupaciones iniciales que abordar al elegir el marco adecuado, por ejemplo

• ¿Cómo se integraría VueJS / Marko / Angular con arrastrar y soltar? ¿Cómo funcionaría arrastrar y soltar en Gutenberg? Al arrastrar, ¿está clonando un elemento fantasma o utilizando el elemento existente? Al soltar, ¿dónde se pueden insertar marcadores de posición para colocar un bloque?

• ¿Cómo funcionaría VueJS / Marko / Angular (y su DOM virtual) con Content Editables y DOM Range & Selection API? Las inconsistencias entre navegadores con este rango y selección pueden ser muy difíciles de resolver aquí.

• ¿Hasta qué punto funcionará copiar / cortar / pegar en el editor de Gutenberg? ¿Puedo hacer una selección de texto entre varios bloques y realizar un cortar / copiar / pegar? ¿El contenido editable vive en cada bloque individual o todo está contenido en un contenido maestro?

• Si hay bloques de Gutenberg que contienen elementos incrustables de iframe, por ejemplo, incrustando un reproductor de YouTube o un feed de Twitter en una publicación de blog, mover este bloque de una posición DOM a otra posición haría que el iframe se recargue. Otras advertencias incluyen la imposibilidad de que los eventos se propaguen desde el iframe al editor (imagínese si está arrastrando un elemento de bloque a través del editor y su cursor ahora se cierne sobre el iframe entre sitios y todo deja de funcionar).

Todos los marcos son excelentes para trabajar con Virtual DOM, pero gran parte del uso de WYSIWYG vive fuera del Virtual DOM. Creo que las áreas en las que centrarse al evaluar el marco adecuado para Gutenberg es qué tan bien puede el marco manejar el manejo de eventos DOM, y para los requisitos de vanguardia que no se pueden construir con el marco, qué tan manejable es construirlo fuera del marco y vuelva a conectarlo.

ver

Wordpress es bastante fácil de aprender para los nuevos desarrolladores y también tiene mucho poder si miras un poco más profundo, lo mismo puede decirse de Vue.
¡Me alegrará si WP usa este marco!

¡Mi voto es VUE!

En términos de creación de componentes web personalizados, que creo que es bastante importante en el futuro, este sitio proporciona una puntuación para cada marco enumerado con parámetros de prueba y puntuaciones. Es instructivo, por lo que animaría a todos a que lo revisen una vez más:

https://custom-elements-everywhere.com/

Mi voto por VueJS. Marco impresionante, creo que Laravel lo demostró.

WP + Sage 9 (roots.io) + VueJS => pila perfecta

También puede haber un problema con Preact.

https://blog.cloudboost.io/3-points-to-consider-before-migrating-away-from-react-because-of-facebooks-bsd-patent-license-b4a32562d268

Usar Preact puede empeorar su situación que usar react. A Facebook se le permitirá bloquear el uso de react o preact incluso si no inició la demanda. Este abogado parece pensar que Preact no podría mantener sus derechos de autor en la corte y se consideraría una infracción al reaccionar.

Dime si me equivoco. No sé mucho de derecho, pero quería ser útil.

Leí esto y es similar al asesoramiento legal que recibimos después de decidir
abandonar React en nuestros proyectos. No es que el riesgo sea enorme. Más bien nosotros
quería minimizar el riesgo para los clientes intermedios. Este abogado solo agrega un
opinión concurrente. Estamos usando Polymer y Vue en su lugar, ambos funcionan muy bien
para casos de uso específicos.

El 20 de septiembre de 2017 a las 11:04 p.m., "Coding Friend" [email protected] escribió:

También puede haber un problema con Preact.

https://blog.cloudboost.io/3-points-to-consider-before-
migrando-lejos-de-react-debido-a-facebooks-bsd-
patente-licencia-b4a32562d268

Usar Preact puede empeorar su situación que usar react. Facebook sería
permitido bloquearle el uso de reaccionar o preact incluso si no inició
la demanda. Este abogado parece pensar que Preact no podría aguantar
es copyright en la corte y se consideraría una infracción al reaccionar.

Dime si me equivoco. No sé mucho de derecho, pero quería ser útil.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/WordPress/gutenberg/issues/2733#issuecomment-331045326 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AH2_iHc8Rg54IDHqe8GIyVTdSbcJbZ9Iks5skeBngaJpZM4PYie9
.

Me juré a mí mismo que nunca volvería a tocar WP después de ver el código horrible, pero si usa VueJS, podría reconsiderarlo con un poco de Valium.

Descargo de responsabilidad: no soy abogado. Lo siguiente es estrictamente mi opinión.

@ codingfriend1 ese artículo tiene poco mérito práctico.

Se hacen tres suposiciones:

1. Facebook tiene patentes que son lo suficientemente amplias como para cubrir preact.
2. Si una empresa que usa preact, digamos ABC, demanda a FB por infracción de patente, entonces FB usará las patentes de react para demandar a ABC.
3. La patente de Facebook tiene mérito.

Echemos un vistazo más de cerca a todos los supuestos:

1. Facebook tiene patentes que son lo suficientemente amplias como para cubrir preact.

No hay pruebas de esto hasta la fecha. Tenga en cuenta que todas las patentes son públicas. El código fuente de Preact es de conocimiento público.
Además, Jason Miller (autor de preact) ha afirmado que "ninguno de Preact es patentable, es demasiado obvio".

Así que diría que es poco probable que esta suposición sea cierta. Es posible, pero improbable.

1. Si una empresa que utiliza preact, digamos ABC, demanda a FB por infracción de patente, FB utilizará las patentes de react para demandar a ABC.

Esto destruirá la reputación de Facebook. Aunque espero que FB luche con uñas y dientes, pero usar la patente de React de esa manera etiquetará a FB como "troll de patentes".

Mientras tanto, FB tiene suficientes recursos para luchar con medios legales. Así que creo que esta suposición también es poco probable.

1. La patente de Facebook tiene mérito.

Sí, esto es una suposición, no un hecho.

Da la casualidad de que "tener una patente" y "tener una patente válida" son dos cosas diferentes.
Leí este artículo fantástico donde la corte ha dictaminado que las patentes no son válidas.

Siempre existe la posibilidad de que las patentes de FB sean demasiado amplias para tener un mérito.
Ahora uno pensaría que, si facebook tiene una patente, tendrá _algo_ mérito. Sin embargo, hablando lógicamente, si cubre el preacto, entonces es demasiado amplio y, por lo tanto, sin mérito. Entonces, esta suposición está en conflicto directo con la suposición 1.

Teniendo en cuenta que Facebook está utilizando la patente para defenderse, es más probable que la patente de Facebook sea amplia y sin mérito, en lugar de ser ejecutable.

Conclusión:

Tenga en cuenta que las tres suposiciones no se han probado. Si todas resultan ser ciertas, y esto es técnicamente posible, entonces, "sí, usar preact es peligroso".

Sin embargo, prácticamente, las posibilidades de que los tres supuestos sean ciertos son demasiado bajas, especialmente los supuestos 1 y 3 juntos.

Entonces, hasta y a menos que la corte decida lo contrario, yo diría que usar preact (y otras bibliotecas de vdom) es bastante seguro.

Respecto al punto 1, Facebook tiene una patente llamada Delegación eficiente de eventos en scripts de navegador . Esa es básicamente la función live() jQuery (que luego formará parte de on() en la API de jQuery).

Sin embargo, independientemente de la validez de las suposiciones, la razón por la que WordPress se está alejando de React no es que WordPress tenga preocupaciones sobre Facebook. Y estoy citando de la publicación de anuncio vinculada en el problema anterior ( resalte el mío):

Creo que la cláusula de Facebook es más clara que muchos otros enfoques que podrían adoptar las empresas, y Facebook ha sido uno de los mejores contribuyentes de código abierto que existen. Pero tenemos muchos problemas que abordar, y convencer al mundo de que la cláusula de patente de Facebook está bien no es nuestro.

En base a esto, es la percepción, la confusión y las preguntas que trae la patente lo que alejó a WordPress. Creo que las mismas preocupaciones se aplican también a Preact, como se explicó en mi comentario anterior .

Respecto al punto 1, Facebook tiene una patente llamada Delegación eficiente de eventos en scripts de navegador. Esa es básicamente la función live () de jQuery (que luego formará parte de on () en la API de jQuery).

¡¿Eso significa que inventaron la idea de la delegación de eventos ?! Veo algunas citas que se remontan al año 1995, ¿qué significa eso?

@ChrisCinelli con respecto a lo que se refirió como lo que "parece ser el punto de inflexión de un crecimiento exponencial" en el caso de Marko.

Creo que esto es simplemente una cuestión de escala. Cuando un proyecto tiene 5k o incluso 10k estrellas Github, un evento único como, por ejemplo, un enlace en la página superior de Hackernews puede traer 1k estrellas en un día, que en el caso de Marko es el 20% del número reciente.

A la escala de 65k estrellas que tiene Vue, no es tan visible. Incluso puede ver que debido a cómo funciona el guión de la historia de las estrellas, en algún momento deja de mostrar las fluctuaciones y es solo una línea recta hasta el final.

Esta situación no es exclusiva de Marko, le sucedió a Inferno o últimamente a MoonJS, que es un microframework inspirado en Vue. Incluso se podría decir que Preact parece estar en un punto similar debido a la cantidad de estrellas que obtuvo últimamente debido a todo el drama de las patentes de React.

Puedes observar de lo que estoy hablando en el siguiente gráfico de la misma fuente que la tuya:

El tiempo dirá si estas personas realmente probarán el marco en desarrollo, lo usarán en producción y continuarán usándolo más tarde. Le deseo lo mejor a Marko, como a cualquier otra biblioteca de código abierto.

En cuanto a Vue, sí, es un crecimiento estable sin grandes fluctuaciones. Con la velocidad actual debería superar React antes de Navidad. Al menos en Github. :)

¿Y @aurelia?
Sitio web: aurelia.io
@EisenbergEffect creó esto.

¡Para mí es un gran marco!

1. Convenciones simples (se pueden personalizar)
2. HTML simple
3. Vanilla JS
4. ¡Sin intervención marco!

¡Incluso puede agregar la biblioteca que elija (jQuery, Vue.js, Preact, Ember, HyperHTML, etc.) que desee usar y enseñarle a Aurelia cómo usarla!

Es tan simple y está basado en estándares que ni siquiera necesitará el apoyo de la comunidad, y si realmente cree que el apoyo de la comunidad es importante, ellos también lo ayudarán (con más de 10k estrellas).

Recursos para @aurelia :

1. Presentando a Aurelia
2. Blog de Aurelia
3. Aurelia Docs

Parece que React se está volviendo a obtener la licencia del MIT: https://code.facebook.com/posts/300798627056246

La decisión debería revertirse ahora, supongo.

¡Madre mía! React está de vuelta en el negocio. ¿WordPress hizo eso? ¡No estoy seguro! ¡Son las 3 de la mañana y estoy muy emocionado por esto! ¡Que pasa contigo!

Relicenciar React, Jest, Flow e Immutable.js

La semana que viene, vamos a volver a licenciar nuestros proyectos de código abierto React, Jest, Flow e Immutable.js bajo la licencia MIT. Estamos volviendo a otorgar licencias para estos proyectos porque React es la base de un amplio ecosistema de software de código abierto para la web y no queremos retrasar el progreso por razones no técnicas.

Esta decisión se produce después de varias semanas de decepción e incertidumbre para nuestra comunidad. Aunque todavía creemos que nuestra licencia BSD + Patents brinda algunos beneficios a los usuarios de nuestros proyectos, reconocemos que no logramos convencer de manera decisiva a esta comunidad.

A raíz de la incertidumbre sobre nuestra licencia, sabemos que muchos equipos pasaron por el proceso de seleccionar una biblioteca alternativa a React. Lamentamos la deserción. No esperamos recuperar a estos equipos haciendo este cambio, pero queremos dejar la puerta abierta. La cooperación y la competencia amistosas en este espacio nos empujan a todos hacia adelante y queremos participar plenamente.

Este cambio, naturalmente, plantea preguntas sobre el resto de los proyectos de código abierto de Facebook. Muchos de nuestros proyectos populares mantendrán la licencia de patentes BSD + por ahora. También estamos evaluando las licencias de esos proyectos, pero cada proyecto es diferente y las opciones de licencias alternativas dependerán de una variedad de factores.

Incluiremos las actualizaciones de licencia con el lanzamiento de React 16 la próxima semana. Hemos estado trabajando en React 16 durante más de un año, y hemos reescrito por completo sus componentes internos para desbloquear funciones poderosas que beneficiarán a todos los que creen interfaces de usuario a escala. Pronto compartiremos más sobre cómo reescribimos React, y esperamos que nuestro trabajo inspire a los desarrolladores en todas partes, ya sea que usen React o no. Esperamos dejar atrás esta discusión sobre la licencia y volver a lo que más nos importa: el envío de excelentes productos.

En mi opinión, con MIT License y con la comunidad JS de código abierto más activa y más grande detrás de ella, React es la opción definitiva a la que hay que apegarse.

Mi voto está de vuelta con React ahora . - Restauración de la fe en la humanidad.

Vote con 👍 en lugar de comentarios similares.

Quiero expresar mi ENORME AGRADECIMIENTO por Wordpress por participar en lo que llevó a este cambio en React lincencing.

Sigo pensando que Vue sería la mejor solución. Muchas de las fortalezas de Vue todavía se aplican, pero quiero señalar que la amabilidad de los principiantes y no tener que usar un paso de compilación son, en mi opinión, características excelentes en el entorno de WordPress.

para misa
sin lugar a duda
para vueJS

También elegí Angular2.0 + (no AngularJS), que tiene la comunidad más grande, un equipo de desarrolladores sólido, un ecosistema estable y completo.

@CrazyBBer ¿Dónde puedo encontrar algunos datos sobre la comunidad más grande que es Angular 2/4? Me ayudaría con una publicación de blog.

De todos modos, chicos, se acabó, React llegó para quedarse con WordPress e incluso como un entusiasta de Vue, creo que la situación podría cambiar de la mejor manera posible, dada la cantidad de código ya escrito con React.

@ahmadawais @gustojs La gente en Reddit ha expresado su preocupación de que el MIT solo cubre los derechos de autor, por lo que los desarrolladores NO tendrán una concesión de patente cuando usen React, lo que supongo que sigue siendo un problema.

Además, esta declaración realmente me molesta:

reconocemos que no logramos convencer de manera decisiva a esta comunidad.

Decir con eficacia: "No nos equivocamos, los desarrolladores simplemente no nos entendieron".

@ahmadawais : Sigo pensando que ir con Vue sería una mejor opción, ya que has visto un ejemplo perfecto de lo voluble que pueden ser las licencias de React, primero tenían BSD + Patents license ahora, cambiándose al MIT. Quién sabe, en un futuro cercano podrían volver a cambiar a alguna licencia / patente propiedad de FB y luego todos estarán colgados para secarse. Vue ha sido MIT desde el principio y está más impulsada por la comunidad que impulsada por una gran corporación.

Además de lo que dijo @ atanas-angelov-dev.

No tiene sentido cambiar ahora entonces.
Creo que Vue ofrece una mejor perspectiva, pero significaría volver a escribir todo.

¡Ahh! Vamos gente, ¡denle una oportunidad a Aurelia!
Fue creado por uno de los desarrolladores principales del equipo de Angularjs.
Puede pasar de una pequeña adopción a un marco completo como Vue.js

¡Incluso el equipo del portal @azure dijo que si hubieran comenzado ahora, habrían elegido a Aurelia en lugar del nocaut!
¡¿Y quien sabe?! ahora podrían estar migrando a Aurelia poco a poco.

Empiece poco a poco, ¡sé que le gustará!

Nirmal4G,
Tu tesis suena tan vendedora que es ridícula.
De hecho, creo que todo el marco tiene los mismos defectos que esta página 404 a la que enlazas directamente en tu publicación.
http://aurelia.io/get-started.html

@ bovas85 No de ventas, ni siquiera soy parte de ese equipo. Ni siquiera saben que estoy usando su marco.

@ cr101 / cc

No juzgues el libro por su portada

He usado muchos frameworks populares incluso antes de conocer a Aurelia. Si tuviera que apilarlos equilibrando todos los criterios que existen, para mi aplicación (créanme, es una aplicación grande), entonces Aurelia encabeza la lista y le sigue Vue.

Creo que todo el marco tiene los mismos defectos que esta página 404 a la que enlazas directamente en tu publicación.

Cada enlace que publiqué nunca va a una página 404. Es culpa de github por redirigir un sitio http a https. Está arreglado ahora. Ves, un error. Dime cualquier marco que no tenga errores, te reto.

Es solo que con otros marcos tienes muchas abstracciones redundantes (pero útiles). La comunidad del W3C nunca adopta un diseño de marco público en su API, así que ahí lo tienes, muchas abstracciones.

Todos los marcos están tan centrados en la compatibilidad con versiones anteriores que pierden la compatibilidad con versiones anteriores, pero Aurelia no lo hace, siempre que se ciña a las especificaciones de HTML W3C y ECMAScript, JS, su código funciona bien.

_Si no hay Aurelia, no me importaría quedarme con Vue. Es la siguiente mejor opción.

_Es solo cuestión de aceptar un estándar que de crear una nueva forma de reinventarlo_

@ Nirmal4G , proporcione pruebas de sus afirmaciones o evite los nombres. Apenas creo, especialmente cuando se trata de LOC, Vue era menos que hyperHTML. Todo lo que he escrito en hyperHTML en diseño y la lógica . Por mucho que ni siquiera crea en LOC como métrica relevante para nada, leer FUD no probado no me parece justo.

@WebReflection Mantenga sus caballos, no dije que fuera peor que Vue. Lo siento si te he ofendido.

Mi aplicación usa todo lo que puedes arrojarle. Probé un prototipo con muchos frameworks, uno de los criterios que tenía era el LOC pero desde el punto de vista visual, no es por la razón que crees, se puede mejorar el rendimiento de cualquier framework, pero son las opciones de diseño, lo que viene con el nombre.

Evalué HyperHTML, el rendimiento fue impresionante, ningún polyfills es excelente, pero lamentablemente para mis requisitos no logró el corte.

Cada marco tiene algo mejor. Mi deseo es que si alguien puede unir el mejor de todos los marcos con un mejor diseño, eso sería divino, pero eso no sucederá. Entonces, tengo que encontrar ese equilibrio donde un marco pueda mejorarse a sí mismo en el futuro y donde no.

Es realmente bueno escuchar que React ahora será MIT.
Me entusiasma mucho este proyecto y espero comenzar a usar WordPress nuevamente después de mucho tiempo, una vez que React y WP API sean totalmente compatibles. :)

Esperemos y veamos cuál será la licencia de React real. MIT, o MIT + Patentes ...? ;)

Personalmente, me gusta React, pero Vue me resulta más productivo. Estaría feliz con cualquiera, pero ...

... teniendo en cuenta el fuerte apoyo a Vue por parte de la comunidad, sugeriría tomar eso en consideración, además de la licencia.

Vue parece ser una opción más apropiada para WordPress.

Facebook ha eliminado 4 elementos de su conjunto de trampas de litigio. Ahora todos tienen licencia del MIT:

• Reaccionar
• Broma
• Fluir
• Immutable.js

Mientras tanto, la licencia de Categoría X de Facebook todavía se aplica a:

• Reaccionar nativo
• GraphQL
• Hilo
• Relé
• Atom IDE
• y probablemente cualquier otra cosa hecha por ellos y de código "abierto"

Sigo diciendo que vayas con Vue. Vale la pena a largo plazo. React nunca tuvo ningún sentido para mí para Wordpress de todos modos. Está tan fuertemente integrado en la comunidad PHP que Vue siempre pareció la opción más sensata (además, no es doloroso usarlo como React).

Mientras tanto, la licencia de Categoría X de Facebook todavía se aplica a:

Reaccionar nativo
GraphQL
Hilo
Relé
Atom IDE
y probablemente cualquier otra cosa hecha por ellos y de código "abierto"

@TheJaredWilcurt lo siento, pero tal vez quieras eliminar el hilo de esa lista ... el hilo no tiene esa licencia de "Categoría X de Facebook" -> https://github.com/yarnpkg/yarn

@ atanas-angelov-dev

La gente en Reddit ha expresado su preocupación de que el MIT solo cubra los derechos de autor, por lo que los desarrolladores NO tendrán una concesión de patente al usar React, lo que supongo que sigue siendo un problema.

MIT es una gran licencia. jQuery también tiene licencia del MIT. Espero que lo sepas.

@vinayakkulkarni Sigo pensando que ir con Vue sería una mejor opción, ya que has visto un ejemplo perfecto de lo voluble que pueden ser las licencias de React, primero tenían licencia BSD + Patents ahora, cambiando a MIT. Quién sabe, en un futuro cercano podrían volver a cambiar a alguna licencia / patente propiedad de FB y luego todos estarán colgados para secarse. Vue ha sido MIT desde el principio y está más impulsada por la comunidad que impulsada por una gran corporación.

Así no es cómo funciona. Leí el comentario de Samuel en Facebook sobre una pregunta similar. Una vez que lo licencia MIT, puede bifurcarlo para cambiar la licencia o simplemente no puede. Aunque no soy abogado.

Además, personalmente creo que Facebook lo ha hecho como un gesto de buena fe y no para engañar a la gente. Eso significa algo para mí.

Además, personalmente creo que Facebook lo ha hecho como un gesto de buena fe y no para engañar a la gente. Eso significa algo para mí.

Esa no es una declaración muy lógica. Estás recompensando a un grupo porque dejó de hacer algo negativo, en lugar de recompensar al grupo que nunca hizo nada negativo. Además, como se mencionó anteriormente, todavía están usando licencias de Categoría X en otros proyectos similares, lo que no es una señal de buena fe para mí.

Vue tiene una curva de aprendizaje y adopción MUCHO más suave.
Y esa ha sido la principal idea subyacente de WordPress desde el principio.

@ahmadawais Lo sé, el MIT es tan bueno como las licencias, pero, y este es un gran "pero", aparentemente Facebook tiene patentes sobre React y, aunque el MIT te permite usar el código para cualquier propósito, es posible que aún termines infringiendo el patentes (tome todo esto con una piedra de sal - IANAL)

Y para mantenerme en el tema, tengo que decir que veo mucho de lo que hizo que WordPress fuera genial también en Vue; en mi humilde opinión, ninguna otra biblioteca adecuada es tan fácil de aprender y usar como Vue.

Facebook aparentemente tiene patentes sobre React

¿Qué parte de React crees que está patentada? (nada en React está patentado, intente hacer una investigación primero) mostrar enlaces, no solo "aparentemente" ..., este es el tipo de comentarios que no ayudan en absoluto. si quieres recomendar tu biblioteca favorita, hazlo de la manera correcta, mostrando sus méritos, no solo difundiendo FUD.

¿Por qué el cambio original a BSD + Patents si ninguno de React tiene patentes detrás? Facebook no ha dicho qué son o qué no son.

¿Por qué perder el tiempo con las licencias durante 2 años y solo hacer un cambio en una parte de su cartera, habiendo dicho constantemente que no lo cambiarían, y dicho "solo ocúpese de ello, no nos importa si lo usa o no".

¿Por qué excluir React Native, GraphQL, etc. de la "nueva" licencia? ¿A qué va a cambiar una versión futura de React? No hay garantías cuando tienes una licencia de dos niveles de Facebook, dependiendo de quién se queje ...

¿Qué pasa si parte del código de React Native se incluye en React? ¿Dónde se encuentra si una implementación GraphQL se abre camino en una base de código ...?

Esta acción de Facebook plantea más preguntas de las que responde, y aún significa que cada uso de React es un riesgo potencial para los verdaderos proyectos de código abierto.

Simplemente adopte la biblioteca sin equipaje que ya está establecida en el mundo PHP: Vue.

@bjrmatos https://www.google.com/patents/US20170221242 ¡Supongo!

Otro +1 a Vue. Facebook todavía usa dos licencias en todos sus proyectos. Eso no es bueno.

@PericlesSouza , claramente ignoras el gran esfuerzo que está haciendo una empresa como Facebook para mejorar las cosas y hacer avanzar la web, todas tus preguntas pueden ser respondidas si lees la publicación sobre el cambio al MIT. Realmente no sé por qué sigue planteando esta preocupación irracional con la licencia del MIT, con el cambio, React está en la misma posición que cualquier otro proyecto "True Open Source" (no sé cómo se llama un proyecto True Open Source por cierto).

@Raymonf bueno, básicamente cualquier marco moderno ya está violando esa patente (incluido Vue), por lo que cualquiera está en la misma posición, sin importar si usa React, Vue u otro marco que implemente el concepto descrito en el enlace (por cierto, básicamente cualquier sitio web proyecto ya está violando dos o tres patentes propiedad de otras empresas, te sorprenderá saber qué tipo de cosas están patentadas por las empresas en el momento actual). Si está realmente preocupado por eso, significa que no puede usar ningún marco que actualice la interfaz de usuario de esa manera ... así que en este contexto legal no hay mejor o peor alternativa.

No quiero volver a involucrarme en este tipo de conversaciones porque será imposible llegar a un acuerdo, así que dejaré de comentar. La comunidad de React está contenta con el cambio al MIT (incluso los mayores detractores de la licencia original)

Buena suerte al equipo de wordpress en la decisión, el problema principal sobre la licencia React BSD + Patents está resuelto, ahora es su trabajo decidir.

Entonces, Facebook cambió recientemente su licencia para React. ¿Eso significa que WordPress continuará usando React o aún cambiará el marco de interfaz predeterminado?

@bjrmatos esto no es cierto en absoluto

Básicamente, cualquier marco moderno está violando esa patente ya

por ejemplo, hyperHTML no usa DOM virtual, usa directamente la API DOM (no patentable) a través de llamadas de devolución de llamada regulares (no patentable) y el único algoritmo diferente para morph c hildNodes: before to c hildNodes: after en listas de nodos se basa en la distancia de Levenshtein (no patentable) y la menor cantidad de operaciones de empalme (no patentable, escribí eso y es ISC ).

Y aunque en este punto creo que este hilo es obsoleto y sin sentido, no entiendo la necesidad de seguir difundiendo FUD. Si tomó una decisión y le gusta, no hay razón para decirle a los demás que están haciendo algo mal o que están en los mismos problemas que usted. Ojalá pudiéramos estar de acuerdo en esto.

@noncototient esa es una pregunta de un millón de dólares, ¿no? 💯

Acabo de cancelar la suscripción aquí porque la discusión se está volviendo un poco inútil.
Creo que se avanzaron muchos puntos positivos y fue una experiencia de aprendizaje para todos los que leyeron atentamente este número.

Estoy de acuerdo, esto ahora no tiene sentido. Sugiero que este hilo esté bloqueado (o quizás solo Colaboradores). Ha habido suficiente retroalimentación sobre este tema, y ​​ahora está llegando al punto en que solo conducirá a una discusión no constructiva.

¿Se cerrará este problema?
Parece que @WordPress no está interesado en migrar al nuevo marco de JavaScript ahora. 🤔

Para mí, personalmente me gusta @vuejs. Pero parece que ahora no importa. 😅

Personalmente prefiero Vue independientemente.

Para mí, y creo que para muchas otras personas, nunca se trató de la concesión de licencias. Esto fue solo una excusa para alejarse de React.

Marko es increíblemente poderoso y fácil. Actualmente estamos completando una reescritura completa de una tienda web dinámica con 50,000 productos y es increíble y con muchas características. Sigue esta ruta y no mires atrás.

Marko es bueno, pero Prarko es 100 bytes más pequeño (comprimido en GZip), y es 0.01% más rápido en una prueba auto-optimizada, así que tenemos que usar eso en su lugar, incluso si nadie más lo hace. Aunque mañana se lanzará Plarko , con Fiber agregada, lo que hace que _todo_ sea redundante.

Lo siento, pero esa es la forma en que se dirige el resto de este hilo.

Esperemos y veamos cuál es la licencia real cuando se publique, cuáles son las implicaciones de la licencia de dos niveles de Facebook, y veamos qué decisión toma el equipo de WordPress una vez que han investigado el problema a fondo.

Quiero decir, originalmente pidió información sobre los motores que le gustan a la comunidad. Y eso parece ser lo que la gente está publicando, sin embargo, algunas personas simplemente critican a las personas por enviar comentarios que están en línea con lo que se les preguntó. Un poco extraño.

Todas las bibliotecas / marcos mencionados aquí son excelentes; algunos se adaptan más a unos escenarios que a otros. Cada uno tendrá sus defensores, cada uno superará a los demás en términos de rendimiento / características, dependiendo de sus ciclos de desarrollo.

Quizás comience con una pregunta simple, como hago en la mayoría de los proyectos:

1. ¿ Necesitamos un marco de SPA?

Si la respuesta es sí, detalle por qué. Eso le brinda un conjunto de criterios para evaluar a los posibles candidatos; quizás para la representación del lado del servidor, quizás el enrutamiento, etc.

Si no es así, haga la siguiente pregunta:

1. ¿Lo que realmente necesitamos es un motor de plantillas?

VanillaJS tiene la comunidad más grande del planeta y no tiene problemas de licencias. También es compatible con los estándares;), y con los módulos ES6, podría ofrecer una base adecuada para el desarrollo del núcleo, con la capacidad de soporte de complementos para usar motores _template_ como React, Vue, Preact, Aurelia, etc., etc., lo que sea que se publique en los próximos años, según lo requieran los desarrolladores.

Matt Mullenweg publicó su respuesta ...

Estoy sorprendido y emocionado de ver la noticia de que Facebook va a eliminar la cláusula de patente sobre la que escribí la semana pasada. Han anunciado que con React 16 la licencia será simplemente MIT regular sin adición de patente. Aplaudo a Facebook por hacer este movimiento y espero que el uso de cláusulas de patente se vuelva a examinar en todos sus proyectos de código abierto.

Nuestra decisión de alejarnos de React, basada en su postura anterior, ha provocado muchas discusiones interesantes en el mundo de WordPress. Particularmente con Gutenberg puede haber un enfoque que permita a los desarrolladores escribir bloques de Gutenberg (Gutenblocks) en la biblioteca de su elección, incluidos Preact, Polymer o Vue, y ahora React también podría ser una opción con soporte oficial.

Quiero agradecerles a todos los que participaron en la discusión hasta ahora, se los agradezco mucho. El vigoroso debate y discusión en los comentarios aquí y en Hacker News y Reddit fue excelente por la pasión que trajo la gente y la oportunidad de aprender sobre tantos puntos de vista diferentes; era incluso mejor que Facebook estuviera escuchando.

→ https://ma.tt/2017/09/facebook-dropping-patent-clause/

@ahmadawais @m

Nuestra decisión de alejarnos de React, basada en su postura anterior, ha provocado muchas discusiones interesantes en el mundo de WordPress. Particularmente con Gutenberg puede haber un enfoque que permita a los desarrolladores escribir bloques de Gutenberg (Gutenblocks) en la biblioteca de su elección, incluidos Preact, Polymer o Vue, y ahora React también podría ser una opción con soporte oficial.

Esa situación parecería una victoria para todos. Esperemos y veamos cómo se resuelve esto.

Simplemente cierre este tema ahora ... solo va a ver cuán voluble es el mundo ... es triste ver que la gente no cumple su palabra.

[Editar: eliminado debido a una declaración ofensiva]

Buena suerte a todos los que tengan que usar Gutenberg y la pesada curva de aprendizaje de aprender React with it.

Paz.

👋 Creo que todos hemos tenido muchas discusiones aquí. Me gustaría agradecer a todos los que se preocuparon lo suficiente como para hablar y comentar sobre este tema. En mi humilde opinión, parece que todas las opciones que tenemos ahora son buenas opciones.

Si terminamos con una mejor API agnóstica del marco, uno podría usar cualquier marco JS que desee en sus aplicaciones. Con la licencia MIT, React tiene una posición tan sólida para ser utilizada en el núcleo como cualquier otra biblioteca con una buena licencia de código abierto (compatible con lectura).

🎯 Si está buscando un marco JavaScript en particular, o ha construido uno (equipos centrales), le sugiero que cree ejemplos reales para los desarrolladores de WordPress para que la gente pueda comenzar a jugar con la idea de usar su marco JavaScript preferido en las aplicaciones basadas en WordPress construir.

Estoy cerrando este boleto por ahora. Y con la esperanza de contribuir más al éxito de WordPress como plataforma y como comunidad. Esperando lo mismo de todos aquí. Realmente creo que esta será una aventura en montaña rusa para cualquiera que trabaje con el software de WordPress.

En algún momento a partir de ahora, podríamos terminar mejorando el software para ayudar a que sea más fácil para sus usuarios (~ 30% de los sitios de Internet) como lo fue hace un par de años. Estoy apoyando WordPress aquí, ¡como todos ustedes!

¡Salud!

No está realmente claro a partir del comentario de Matts si la decisión de alejarse de React ha sido rescindida.

En primer lugar, la licencia real que utilizará Facebook aún no se ha publicado , por lo que fingir que todo ha terminado no es realmente un movimiento sensato.

En segundo lugar, no aborda las licencias de dos niveles que sigue Facebook: React podría ser MIT, pero React Native será + Patentes (no reveladas) .

Entonces ... ¿qué pasa con los componentes que comparten ambos?

¿Qué pasa con el código React Native que se usa dentro de React? ¿Fiber se compartirá entre dos licencias diferentes? ¿O el código GraphQL llega a React?

¿Qué le sucede a WordPress si sigue la ruta de React, con todos estos proyectos de Facebook relacionados publicados bajo una licencia diferente, y luego Facebook decide que algunos aspectos de React están realmente sujetos a, por ejemplo, una concesión de patente nativa de React o una fibra? Concesión de patente?

En serio, piense con mucho cuidado en esto. Por qué arriesgarse cuando hay alternativas que la mayoría prefiere usar, que no tienen este problema - Vue.

No confiaría en un acuerdo de licencia que cambia con el viento, en lugar de estar bien pensado. Los abogados de Facebook podrían cambiar esto por capricho.

Quédese con el código abierto genuino.

@PericlesSouza La licencia será exactamente lo que la gente aquí imagina de la descripción de la publicación del blog: una licencia estándar del MIT, nada más. React no depende de React Native. Las piezas que comparten ambos viven en el proyecto React, no en React Native. React y sus dependencias propiedad de FB estarán disponibles en MIT tan pronto como nuestro equipo tenga tiempo para realizar los cambios. No estamos planeando ningún negocio divertido.

@sophiebits

Trabajas para Facebook. Si no es un abogado autorizado para hablar en nombre de Facebook, no importa lo que afirme. Ni siquiera importa qué código escribas. Lo siento.

"Imaginar" licencias no se sostiene en los tribunales.

Por ejemplo, ¿puede decir categóricamente por qué Facebook adoptó la concesión de patentes, qué eran (o no eran) las patentes, o por qué dicen que lo están cambiando ahora, sin decir 'IANAL' (No soy abogado)?

Las piezas que comparten ambos viven en el proyecto React, no en React Native

¿Pero puedes decir eso con una garantía legal? ¿No?

React y sus dependencias propiedad de FB estarán disponibles en MIT tan pronto como nuestro equipo tenga tiempo para confirmar los cambios.

¿Qué partes se eliminarán para permitir que React se publique en el MIT? ¿Qué _dependencias que no son propiedad de FB_ que presumiblemente no eran compatibles con MIT ya estaba usando ...? ¿Garantizarán los abogados de Facebook que todo realmente cumple con el MIT? ¿Cuánto tiempo llevará a Apache Software Foundation certificar esto?
.

Parece que tenía razón al destacar que el código se comparte entre dos proyectos que aparentemente tendrán licencias de dos niveles.

Estás torciendo mis palabras. El código compartido entre React y React Native tendrá licencia del MIT. Todo lo que usted considere fibra tendrá licencia del MIT. React no incluirá ni dependerá de ningún código con licencia BSD + Patents o cualquier otra concesión de patente que usted desprecie. No eliminaremos partes de React. La única dependencia de React que no es propiedad de FB que conozco es la asignación de objetos, que también está bajo MIT.

No estoy sugiriendo que tome mis palabras como una garantía legal. Ambos somos conscientes de que mis comentarios aquí no cambian la licencia de React. Puedes elegir ser escéptico y no tienes que creerme ahora, pero en uno o dos días verás que lo que estoy diciendo aquí es cierto.

@sophiebits

No estoy tergiversando sus palabras, y respeto tanto el trabajo que hace como su disposición para participar aquí.

Simplemente estoy diciendo que, a menos que obtengamos compromisos legales de Facebook, por parte de funcionarios autorizados de la empresa, verificados por organismos externos de código abierto, seguiremos en la misma posición en la que comenzamos: nadie puede estar seguro de cuál es la situación legal real. es, como usted está de acuerdo al indicar:

No estoy sugiriendo que tome mis palabras como una garantía legal. Ambos somos conscientes de que mis comentarios aquí no cambian la licencia de React.

Y:

Todo lo que usted considere fibra tendrá licencia del MIT.

No importa lo que yo considere Fiber, depende totalmente de lo que los abogados de Facebook y las patentes presentadas definan como Fiber.

¿Por qué React Native actualmente tiene la intención de tener una licencia diferente a React, cuando comparte código con React? ¿Eso no invalida (perdón por el juego de palabras) la licencia del MIT?

También observo que no mencionó GraphQL. ¿Algo más que me perdí?

El punto principal de la debacle de las licencias de React es la falta de seguridad jurídica.

@sophiebits

Observo su edición en respuesta a mis puntos:

React no incluirá ni dependerá de ningún código con licencia BSD + Patents o cualquier otra concesión de patente que usted desprecie. No eliminaremos partes de React. La única dependencia de React que no es propiedad de FB que conozco es la asignación de objetos, que también está bajo MIT.

Pero dijiste que ibas a eliminar partes de React y que revisarías el código "en los próximos días".

React y sus dependencias propiedad de FB estarán disponibles en MIT tan pronto como nuestro equipo tenga tiempo para confirmar los cambios.

Y te olvidaste del IANAL ... :-)

Oh, en realidad lo dijiste en forma larga:

No estoy sugiriendo que tome mis palabras como una garantía legal. Ambos somos conscientes de que mis comentarios aquí no cambian la licencia de React.

Una vez más:

El punto principal de la debacle de las licencias de React es la falta de seguridad jurídica.

Estoy de acuerdo con el punto de que todavía no hay seguridad jurídica. Pero personalmente creo que este hilo ha seguido su curso; Es mejor marcarlo solo como contribuidores y esperar hasta que se publique la licencia real y el equipo pueda hacer su evaluación.

Darse de baja ahora.

Por favor, no descargue React, Facebook hizo su decisión https://thenextweb.com/dd/2017/09/25/facebook-re-licenses-react-mit-license-developer-backlash/

@vinayakkulkarni Si bien

@sophiebits solo una pequeña nota para agradecerle por entrar en este hilo, se agradece.

Este podría ser un tema para un nuevo hilo, pero desafortunadamente la licencia del MIT (incluso la estándar) no elimina el problema de la "incertidumbre" con las patentes, que llevó a la decisión de WordPress antes.

¿La licencia del MIT le otorga el derecho a utilizar la propiedad intelectual patentada? Lea lo que un abogado tiene que decir al respecto: La licencia del MIT, línea por línea

- Frans Bouma (@FransBouma) 23 de septiembre de 2017

El MIT aparentemente no le otorga una licencia de patente. Facebook tiene patentes en React, que dice que te otorga en su licencia actual. Con la licencia actual, al menos sabe que se le otorgan las licencias que existan, y sabe qué condiciones las revocan. Con un MIT, ni siquiera obtienes una concesión de licencia.

Sin embargo, la concesión de patentes significa que hay patentes involucradas (¿o qué concede?). Excepto que nadie sabe siquiera qué son las patentes. Facebook no dijo, ni siquiera cuando les otorgó, ni cuando anunció la eliminación de la subvención.

Independientemente de lo que yo personalmente o el equipo de WordPress pueda pensar que esto significa, lo que parece estar presente todavía es la confusión en torno a la situación legal de las patentes de Facebook (aún no incluidas) que tiene sobre React, que cualquiera que lo use [[puede - o- puede que]] no tenga que preocuparse por violar, al demandar a Facebook hoy, o simplemente usando React después de la nueva licencia.

Una vez más, puede o no, el problema es la incertidumbre, y eso es lo que sugiero que no se resuelva.

Como recordatorio, la mayoría de los que ofrecieron su opinión sobre este hilo quieren una solución basada en Vue.

Hay varias razones para esto, que no se limitan al hecho de que Vue no tiene confusión de licencias (que aún se mantiene con la política de licencias de dos niveles de Facebook):

1. Vue está diseñado desde cero para agregarse gradualmente, con islas de funcionalidad, lo que permite la mejora gradual de una base de código.

2. Además, y de forma opcional, proporciona soluciones de enrutamiento y administración de estado con soporte oficial.

3. Admite múltiples procesadores para HTML, lo que brinda a los desarrolladores una opción de lenguaje de plantilla: HTML, JSX, Pug, etc., o funciones de renderizado.

4. Componentes de un solo archivo y CSS con ámbito (Stylus, SASS, SCSS, PostCSS, componentes CSS) de la manera más fácil posible. Literalmente, simplemente agregue el atributo de ámbito a las declaraciones de estilo de sus componentes, y listo.

5. Soporte para propiedades calculadas (con memorización) incorporadas (es decir, sin dependencias como MobX).

   6+. Rendimiento superior para React, curva de aprendizaje mucho más baja, mayor adopción en la comunidad PHP, consulte Laravel Mix, por ejemplo, puede usar eso sin usar Laravel en sí. O simplemente incluya Vue a través de https://unpkg.com/vue y comience a codificar.

Vue es simplemente más adecuado para WordPress.

Reaccionar :

76,364 estrellas de Github
571 Problemas abiertos (!)
4325 Ediciones cerradas
178 Solicitudes de extracción abiertas (!)
5.644 solicitudes de extracción cerradas

Vue :

68, 246 estrellas de Github (la trayectoria es superar a React en Navidad)
62 Problemas abiertos (mucho más sensibles a la corrección de errores, agregando funciones solicitadas)
5629 números cerrados
17 solicitudes de extracción abierta
863 Solicitudes de extracción cerradas

@Meligy

El MIT aparentemente no le otorga una licencia de patente. Facebook tiene patentes en React, que dice que te otorga en su licencia actual. Con la licencia actual, al menos sabe que se le otorgan las licencias que existan, y sabe qué condiciones las revocan. Con un MIT, ni siquiera obtienes una concesión de licencia.

Sin embargo, la concesión de patentes significa que hay patentes involucradas (¿o qué concede?). Facebook no dijo, ni siquiera cuando les otorgó, ni cuando anunció la eliminación de la subvención.

Ahí radica el problema con el código no del todo abierto de una gran empresa. En última instancia, sus abogados anularán las buenas intenciones de los equipos de desarrollo, ya sea ahora o en el futuro.

Facebook enmarcó su licencia + Patents como una defensa agresiva de 'algo o cualquier cosa', y ahora se nos pide que creamos que el mismo 'algo o cualquier cosa' no existe realmente para React, pero, _todavía existe_ para React Native y GraphQL, etc.

¿Puede Automattic prometer que se hará cargo de sí mismo y llevará React, bifurcarlo, desarrollarlo por sí solo, cuando Facebook vuelva a cambiar su licencia y opinión sobre React?

Para mí, parece que Facebook está tendiendo una trampa para WordPress. El 25% de todos los sitios web del mundo es un gran problema.

marque este hilo como _solo contribuyentes_ lo antes posible, sería genial leer el resultado de cualquier colaborador, en lugar de solo FUD y especulaciones, sin necesidad de cancelar la suscripción por completo. Gracias.

Las partes interesadas de @WebReflection Wordpress no son solo sus desarrolladores principales, sino también la comunidad extendida.

@PericlesSouza citar estrellas de Github no equivale a nada. Y que este problema esté siendo criticado por personas que hacen afirmaciones ridículas no significa que debamos ignorar los hechos: https://npmcharts.com/compare/react , angular, @ angular / core , ember-cli, vue

Vue no es mucho más que un parpadeo en el radar. La asombrosa mayoría usa React y ciertamente tampoco estaría de acuerdo con sus viñetas.

@PericlesSouza citar estrellas de Github no equivale a nada. Y que este problema esté siendo criticado por personas que hacen afirmaciones ridículas no significa que debamos ignorar los hechos: https://npmcharts.com/compare/react , angular, @ angular / core , ember-cli, vue

Vue no es mucho más que un parpadeo en el radar. La asombrosa mayoría usa React y ciertamente tampoco estaría de acuerdo con sus viñetas.

Estadísticas de NPM? ¿Te refieres a las mismas estadísticas que admiten que cuentan cada una de las solicitudes para comprobar si estás usando la última versión, o mediante cada dependencia, como una solicitud de descarga? (Lo admitieron en su blog cuando la gente se rió de sus afirmaciones de "miles de millones de paquetes al mes").

Si desea seguir esa ruta, entonces todos están usando jQuery.

Quizás intente cifras para paquetes que no tienen ese campo de distorsión de dependencia:

https://npmcharts.com/compare/vue-cli , create-react-app

Imagen completamente diferente a la que eligió presentar.

O qué tal el uso del sitio web:

https://w3techs.com/technologies/comparison/js-react , js-vuejs

Que está respaldado por las estadísticas de BuiltWith:

Ah, y dejaré esta imagen aquí, de cuando el equipo le preguntó a la comunidad. Deberías escucharlos en lugar de tratarlos con desprecio.

@PericlesSouza No tiene sentido comparar vue-cli con create-react-app ya que existen otras herramientas de compilación muy populares para React como Next.js y GatsbyJS .
Muchos desarrolladores de React ni siquiera usan una CLI y en su lugar usan sus propios scripts de compilación de Webpack personalizados, como lo hacen Gutenberg y Calypso.

La realidad es que el ecosistema React es mucho más grande que el de Vue. Tomemos, por ejemplo, Material UI para Vue.js que tiene 4,339 estrellas, mientras que Material UI para React tiene 29,078 estrellas.

Un componente de cuadro de selección nativo que proporciona una funcionalidad similar a Select2 sin la sobrecarga de jQuery: Vue select tiene 1348 estrellas, mientras que React select tiene 8,493 estrellas.

@PericlesSouza , @drcmda , todos estos datos se pueden impugnar de muchas maneras, incluso las estadísticas npm con los cli's, si agrega AngularCLI y EmberCLI verá datos totalmente diferentes, lo que no significa nada:

Fuente: https://npmcharts.com/compare/vue-cli , create-react-app, @ angular / cli , ember-cli

Fuente: https://w3techs.com/technologies/comparison/js-angularjs , js-react, js-vuejs

Fuente: https://insights.stackoverflow.com/survey/2017#technology -frameworks-libraries-and-other-technologies

Pero esta conversación no debería ser sobre qué marco se usa más, sino cuál será mejor para el entorno de Wordpress en su conjunto.

@PericlesSouza @willgm Las reglas se aplican a ambos. Ambos se cuentan exactamente de la misma manera, bastante falso para afirmar que no es justo. Aferrarse a CLI opcionales o sitios web sugerentes que cuentan "me gusta" y "estrellas" es inútil. Incluso stackoverflow es muy subjetivo y ni siquiera he oído hablar del sitio "builtwith ..." hasta hoy, y las estadísticas de la CLI reflejan cuántos utilizan una CLI (la mayoría no).

Los datos de la fuente más obvia e importante, que reflejan entornos de producción reales bajo las mismas circunstancias exactas, es la única estadística que no te gusta, no cambia la forma en que es.

Pero esta conversación no debería ser sobre qué marco se usa más, sino cuál será mejor para el entorno de Wordpress en su conjunto.

Y supongo que sabes cuál es el más adecuado. Crees que las 400.000 personas al día que obtienen React off npm están equivocadas. Vue podría competir por sí solo, realmente no necesita una mafia que se apresure a los rastreadores de problemas.

@PericlesSouza @willgm Las reglas se aplican a ambos. Ambos se cuentan exactamente de la misma manera, bastante falso para afirmar que no es justo. Aferrarse a CLI opcionales o sitios web sugerentes que cuentan "me gusta" y "estrellas" es inútil.

No React tiene 16.800 paquetes dependientes que sesgan las cifras. NPM admite que todo lo que cuentan como descarga es un código de resultado 200 al llamar a una URL, como resultado de una verificación de dependencia, un bot, un espejo o cualquier cosa. Por cierto, también dicen que la mayoría de las descargas en China, donde Vue es muy popular, provienen de espejos y no se cuentan.

A juzgar por su uso del lenguaje: 'adherente', 'sitios web sugerentes', 'inútil', no tiene ningún argumento real sobre este tema, mientras que, según lo solicitado por el equipo, he publicado los aspectos positivos de usar Vue arriba ).

Contando estrellas: ¿otros hacen eso cuando señalan el éxito de React, pero tú rechazas su valor cuando se usa para indicar la popularidad de Vue? Tampoco menciona el número mucho mayor de problemas pendientes ( 571 ) y el número bastante notable de solicitudes de extracción pendientes ( 178 ) aún pendientes para React, que en comparación con la mayor capacidad de respuesta de la comunidad Vue en la corrección de errores y agregar funciones es un motivo válido de preocupación al proponer el uso de React.

Lo que me lleva a:

Contar los Me gusta - bueno, ese fue el objetivo de este hilo, tal como lo inició el equipo y se lo pidió a la Comunidad - supongo que simplemente no te gusta el resultado. Aquí está de nuevo, y es muy concluyente:

No React tiene 16.800 paquetes dependientes que sesgan las cifras.

@PericlesSouza ¿Cómo se llega a esa conclusión? Significa lo que se supone que significa: 16.800 paquetes han declarado a React como su dependencia en package.json. No bots, no China, ... paquetes. Vue tiene alrededor de 2580, eso significa que tiene un ecosistema y una base de usuarios mucho más pequeños. ¿Por qué incluso estamos discutiendo esto? Se refleja directamente en las estadísticas de uso. Actualizaciones, personas reales o bots, aplica a ambos paquetes. A menos que asuma que los bots se saltan deliberadamente Vue por alguna razón.

Seleccionar un paquete en un rastreador que trata a cada paquete de la misma manera no tiene sentido. Por otro lado, contar Me gusta significa nada más que la comunidad XY sabía dónde votar.

@dcrmda

Creo que lo que quiere decir es que cada vez que instalas un paquete que tiene una dependencia en React, y llega a NPM para verificar versiones y dependencias, ese NPM cuenta eso como un download del paquete, incluso si no lo es. descargado.

Si eso es lo que quiere decir, entonces tiene toda la razón; NPM declara explícitamente que lo hacen; describen su 'metodología' como 'intencionalmente ingenua' (también mencionan que los robots y los espejos pueden sesgar las cifras, ya que no tienen ningún mecanismo para determinar para qué es una solicitud, simplemente la cuentan). Y React tiene paquetes más dependientes, por lo que este efecto es más pronunciado.

En cuanto a muchos paquetes dependientes, sí, React es un marco más antiguo, tiene más y los necesita. Desarrollo tanto con React como con Vue, y con Vue tiendes a necesitar menos paquetes adicionales, ya que el núcleo es bastante completo, y el enrutador oficial y Vuex también siguen la filosofía de bajas dependencias. Vue en sí no depende de ningún paquete, React depende de unos pocos. Tienen diferentes enfoques a este respecto.

Otro ejemplo es que la gente tiende a usar un paquete de integración entre, por ejemplo, Bootstrap y React, o usan bibliotecas como componentes con estilo, nombres de clases, etc. Con Vue generalmente no es necesario, aunque tales proyectos también existen. Me resulta mucho más fácil trabajar con Vue, ya que puedo tener CSS con ámbito de componente listo para usar sin bibliotecas o configuraciones adicionales, y puedo escribir mis propias integraciones simples con marcos CSS según sea necesario, en lugar de importar una biblioteca de integración completa y luego probar el árbol -sacando el 75% que no necesito.

@PericlesSouza te perdiste un par de elementos bastante relevantes de tu publicación 'Pros of Vue':

Ranuras con nombre para permitir componentes de plantilla reutilizables, como formularios estándar, entradas, diseños, etc., que es más flexible que el uso de Reacts para niños.

Componentes condicionales con la capacidad opcional de mantener vivo el estado local sin destruir el componente no activo.

El elemento HTML 'Es' una sintaxis de componente de Vue para plantillas de cadenas, que evita la elevación de elementos HTML renderizados que dan como resultado HTML no válido.

Flujo de datos unidireccional con accesorios, pero con la adición de un flujo de 'emisión' y 'bus de eventos' mucho más simplificado para notificar o actualizar al hermano o al padre. Esto puede resultar útil para la intercomunicación entre:

Varias instancias de Vue en una página, controlando regiones específicas. Esta técnica es útil para paneles dinámicos o widgets conectables y administración de memoria.

Registro de directivas personalizadas y componentes globales y locales.

Filtros encadenables además de propiedades calculadas.

Todo lo anterior es parte de la biblioteca principal de Vue.

React es un gran marco y disfruto usándolo, pero personalmente creo que Vue es más adecuado para este caso de uso propuesto.

@mcquiggd

Sí, me apuraron y no tuve tiempo de hacer una lista completa de las ventajas de Vue.

Es interesante que mencionaste que React tiene dependencias, ya que noto que depende de fbjs . Agregué algo de énfasis a las partes que deberían hacer sonar las alarmas si las personas están considerando React, con la estrategia de licencias de dos niveles de Facebook mientras se comparte código entre proyectos con licencias diferentes. Insinuar que todo al respecto es preocupante sobre todo cuando ves la lista de proyectos que dependen de él, pero que tienen diferentes licencias.

https://www.npmjs.com/package/fbjs

https://www.npmjs.com/browse/depended/fbjs

Propósito

Facilitar que Facebook comparta y consuma nuestro propio JavaScript.

Nota: _Si estás consumiendo el código aquí y no eres también un proyecto de Facebook, prepárate para un mal momento_. _Esta biblioteca se publica teniendo en cuenta nuestros casos de uso y no está destinada necesariamente a ser consumida por el público en general. Probablemente no aceptaremos sus solicitudes de funciones a menos que se alineen con nuestras necesidades.

571 Problemas abiertos (!)

Ahora son 338. (Pasé unos días limpiándolos).

Durante los últimos meses, el equipo de React estuvo ocupado preparando una nueva versión de React 16 , en gran parte compatible con versiones anteriores. Fue nuestro lanzamiento más grande hasta la fecha, por lo que no respondimos al seguimiento de problemas, así que lo siento. Resulta que React 16 también resolvió muchos de esos problemas. :-)

Quiero señalar que la mayoría de esos 338 problemas que quedan son solicitudes de funciones y debates. Una búsqueda de la etiqueta del error me da alrededor de 60 problemas. Y dado que el ecosistema React es más grande que Vue en este momento, no es de extrañar que las personas se encuentren con más casos extremos e inconsistencias y comiencen más discusiones. También esperan que React rellene más inconsistencias del navegador, por lo que muchos de los errores están relacionados con la falta de cobertura de ellos. Además, mantenemos la documentación en el mismo repositorio, por lo que muchos de esos problemas son sobre documentos.

Espero que esto le dé una idea de por qué tendemos a tener un mayor número de problemas que Vue.

Es interesante que mencionaste que React tiene dependencias, ya que noté que depende de fbjs. Agregué algo de énfasis a las partes que deberían hacer sonar las alarmas si las personas están considerando React, con la estrategia de licencias de dos niveles de Facebook mientras se comparte código entre proyectos con licencias diferentes. Insinuar que todo al respecto es preocupante sobre todo cuando ves la lista de proyectos que dependen de él, pero que tienen diferentes licencias.

Desafortunadamente, esto es FUD sin fundamento, punto. No estoy seguro de cuál es su motivación para difundirlo, pero React ha vuelto a obtener la licencia como MIT, y eso incluye cualquier código del que React dependa (como fbjs). No hay ningún plan engañoso aquí.

Puede ver por sí mismo que la licencia fbjs también se ha cambiado a MIT en https://github.com/facebook/fbjs/commit/c69904a511b900266935168223063dd8772dfc40 cinco días antes de su comentario. La versión de React 16 que salió hace unos días no contiene un solo byte que no sea MIT.

El hecho de que otros proyectos dependan de fbjs pero tengan una licencia diferente es completamente irrelevante, al igual que es irrelevante que el código de su aplicación probablemente no sea MIT sino que dependa de Vue.

PD: Creo que Vue es genial y no quiero presionar a React sobre nadie. Pero quiero asegurarme de que basamos esta discusión en hechos. :-) Siempre estamos abiertos a las críticas, y estoy seguro de que tanto Vue como React tienen cosas que aprender el uno del otro.

Todo esto es una charla apasionante.

Tengo que preguntar: ¿por qué un marco / biblioteca? Como se mencionó anteriormente, el estándar de componentes web parece proporcionar lo que ReactJS, Vue y otros fueron construidos para proporcionar (ya que el estándar no existía).

Puede usar bibliotecas estatales como Redux sin problemas con componentes web. Similar a las bibliotecas de enrutamiento. SSR no está tan desarrollado con los componentes web, sin embargo, también hay personas que trabajan allí. En parte, el mayor valor de React son las diversas bibliotecas de soporte que lo rodean, que no necesariamente se pierden al usar la plataforma.

¿Qué te ofrece el marco XXX sobre la plataforma de componentes web?

De hecho, una charla emocionante ...

La cuarta licencia para React, hasta ahora.

1. Originalmente Apache 2.0. Debería haber estado bien, ¿verdad? ¿Cual fue el problema?
2. Luego BSD + Patentes. Sin revelar qué patentes existen o no existen.
3. Luego, leves modificaciones, supuestamente para complacer a Google. Sin detalles de por qué.
4. Ahora MIT, con refactorización no especificada de React, pero no para proyectos directamente relacionados, como React Native, GraphQL, etc ... y la dependencia compartida con la descripción pública "Para facilitar que Facebook comparta y consuma nuestro propio JavaScript. Principalmente, esto nos permitirá enviar código sin preocuparnos demasiado por dónde vive ".

Aparentemente, todo eso no es nada de qué preocuparse.

[edición eliminada por Tammie Lister: llamadas personales como esta son inaceptables]

@PericlesSouza Puede argumentar que no se debe confiar en nosotros porque las licencias eran confusas antes. Eso es válido si es tu argumento. Pero las licencias no deberían ser confusas ahora.

React es MIT.
Su dependencia fbjs es MIT.
El código que comparten React y React Native (que ha estado y sigue estando en el repositorio de React) es MIT.
React, incluidas todas sus dependencias, es MIT.
La aplicación Create React no es necesaria para usar React, pero también es MIT.
Relay y graphql-js no son necesarios para usar React, pero también son MIT.

Lanzamos React 16.0 con la nueva licencia. Es fácil verificar esto.
También lanzamos una nueva versión de React 15.x con la licencia MIT como 15.6.2.
También estamos planeando lanzar todas las versiones futuras de React bajo la licencia MIT.

Agregue a eso, otro empleado de Facebook en este hilo admitió que React (MIT para 16? ¿Para <16? 17+? Mejor mire ese package.json con cuidado) y React Native comparte código, que requirió refactorización (luego edita su comentario para eliminar esa declaración, después de que la cité).

Yo soy ese ingeniero. (Su.)

Comentaste https://github.com/WordPress/gutenberg/issues/2733#issuecomment -331737418, luego respondí https://github.com/WordPress/gutenberg/issues/2733#issuecomment -331738521.

Aquí está el contenido original de nuestros dos comentarios, según lo registrado en mi cliente de correo electrónico:

Aquí está el contenido justo en este momento:

Después de que hice mi comentario, editó su comentario para que fuera mucho más largo, incluida la pregunta adicional:

¿Qué partes se eliminarán para permitir que React se publique en el MIT?

que no estaba en tu comentario original. Entonces, en respuesta a su edición, edité mi comentario para agregar:

No eliminaremos partes de React. La única dependencia de React que no es propiedad de FB que conozco es la asignación de objetos, que también está bajo MIT.

Por lo que luego consideró apropiado llamarme en el siguiente comentario. ¿Cómo me atrevo a editar mi comentario para abordar una pregunta que agregaste en tu edición? No eliminé ni edité ningún reclamo sobre el código para compartir React y React Native.

-

Por favor, deja de encenderme con gas. Es agotador.

@youknowriad ¿Sería tan amable de bloquear este hilo? No puedo imaginarme una discusión más productiva ocurriendo aquí.

Si alguien más aquí está legítimamente preocupado por la licencia, no dude en enviarme un mensaje de texto y haré todo lo posible para aclararlo.

Por lo que luego consideró apropiado llamarme en el siguiente comentario. ¿Cómo me atrevo a editar mi comentario para abordar una pregunta que agregaste en tu edición? No eliminé ni edité ningún reclamo sobre el código para compartir React y React Native.

Obviamente respondí a tu edición, ¿ese es tu problema?

No se necesita iluminación de gas, simplemente apertura y consistencia de Facebook, el equipo de desarrollo de React y las licencias, y como lo indicarían los cuatro modelos de licencia en Reacts, el tiempo de vida relativamente corto y su publicación (actual), lamentablemente, falta.

Dejando brevemente a un lado las licencias: una vez más, ¿qué ofrece React hoy que se gana más allá de los componentes web? Suponiendo que seguirá utilizando una selección de bibliotecas de soporte en ambos (es decir, Redux).

Con Web Components, WordPress puede crear muchos elementos que se pueden usar en varios marcos / bibliotecas de front-end. Esto permitiría a los usuarios finales con React, Vue, Angular o cualquier interfaz que estén usando "colocar" componentes de WordPress.

@sophiebits No estoy seguro de a qué versión de tu publicación responder ahora, así que esperaré y veré en qué se convierte finalmente. Realmente es una situación bastante similar a la de React.

@ Brian-McBride

Tiene un buen punto, y creo que se planteó anteriormente en el hilo: "¿por qué no usar javascript vanilla?", Basado en estándares, totalmente compatible.

Hmm.

Remove references to PATENTS that crept in #11091
Merged  sophiebits  merged 1 commit into facebook:master from sophiebits:nopatentsagain a day ago

https://github.com/facebook/react/pull/11091

Como dije, gente, tenga mucho cuidado con su control de versiones si está usando React.

Sí, cometimos accidentalmente tres archivos con el encabezado incorrecto, de solicitudes de extracción que estaban abiertas antes del cambio de licencia. Ninguno estaba en una versión lanzada (ni podría serlo; una eran pruebas unitarias, dos eran parte del sitio web).

Los errores ocurren. Lo arreglamos cuando nos enteramos y agregué un script a nuestro CI para verificar en el futuro que no se agregan más referencias accidentales. Puedes verlo en ese compromiso.

Una cosa adicional que creo que los proyectos de software libre deberían tener en cuenta: Facebook se beneficia del uso de React.

Pero los valores de Facebook generalmente no se alinean con los del movimiento del software libre: todo, desde la manipulación poco ética de los usuarios hasta los ataques a la neutralidad de la red ("Conceptos básicos gratuitos"), la imposibilidad de eliminar datos, la imposibilidad de bloquear la recopilación de datos, la censura, el jardín amurallado. , cámaras de eco y más.

[Facebook] es como cuando mi hermano solía hacerme golpearme a mí mismo y preguntarme, "¿por qué te golpeas a ti mismo?" Luego le diría a mi madre que no fue su culpa.

Como he visto Facebook durante muchos años, me he acercado cada vez más a la conclusión de que ya no quiero apoyar a esa empresa de ninguna manera, por lo que personalmente no uso el software FB siempre que existen alternativas.

Leí un libro sobre React y se ve muy bien desde la perspectiva de la programación, pero las alternativas también son excelentes y no vienen con el bagaje de apoyar a Facebook.

Creo que los proyectos de software libre siempre deberían preferir bibliotecas de software libre independientes siempre que estén disponibles. Hay muchas alternativas excelentes para WordPress, incluidos Vue, componentes web, Ember y Mithril. Vue tiene un gran apoyo en la comunidad PHP y no tiene ningún problema ético asociado, por lo que parece que encajaría bien. Si es solo para el tablero, podría valer la pena echarle un vistazo a algo aún más interesante que JavaScript: Elm .

No debería tratarse de lo que está de moda o de moda en este momento, sino de lo que proporciona la mayor libertad tecnológica a las próximas generaciones, directa o indirectamente.

Solo otro pensamiento a considerar ...

Gracias a todos los que expresaron sus opiniones mientras intentaban tener una conversación respetuosa. También me gustaría agregar un agradecimiento especial a @sophiebits , @gaearon , @ blake-newman y todos los demás representantes de proyectos que amablemente dedicaron su tiempo a responder preguntas. Su conocimiento es muy apreciado y siempre bienvenido.

Desde entonces, la conversación pasó a las reuniones de JavaScript en el canal # core-js de Slack, aquí hay un buen resumen . Si está interesado en participar en estas discusiones, lo invitamos a unirse a nosotros. Alternativamente, tenemos dos enfoques de interoperabilidad que podrían utilizar contribuciones, pruebas y comentarios: # 2463 y # 2791.

Y con eso, este hilo ha seguido su curso. Estamos bloqueando el problema, pero lo alentamos a continuar la conversación en los lugares mencionados anteriormente.

Este hilo ha generado una buena discusión, pero parte de él ha mostrado un comportamiento inaceptable y ha sido editado. Es importante recordar que https://wordpress.org/about/etiquette/ se aplica a cualquier proyecto de WordPress y no toleraremos violaciones o aquellas que las cometan. Gracias a todos los que han contribuido a la conversación de forma considerada y respetuosa.