Gutenberg: Escolhendo o framework JavaScript para Gutenberg (~ WordPress)

Meu voto é com VueJS

Eu escolho VueJS

Vue tem uma grande comunidade e deve ser a escolha certa.

Angular JS

Vou votar no VueJS. Como explicado acima, é amigável para iniciantes e usado com sucesso com o Laravel. Isso o torna a escolha perfeita.

Eu também vou votar no Vue JS

Observe que apenas gritar "Eu prefiro Vue" ou "Eu quero XY" realmente não ajuda na tomada de decisão aqui. Se você quiser votar, sugiro usar reações de emojis ou algo parecido, em vez de desordenar um tópico que pode atuar como um local para documentar descobertas ao avaliar diferentes estruturas.

Eu vou com Vue. É mais fácil aprender e se adaptar. Além disso, é menos controverso do que Preact.

Para a questão da "dependência de pessoa-chave" surgindo de tempos em tempos, não é isso que todos os plugins de recursos do WordPress ou tecnologias desconhecidas são? Koop construiu o antigo gerenciamento de mídia, Weston fez uma tonelada de trabalho no Customizer, Matías e alguns outros estão trabalhando no Gutenberg, quase todas as grandes mudanças no WordPress que aconteceram nos últimos anos tiveram um pequeno grupo de pessoas trabalhando nisso ou entendê-lo.

Eu poderia estar olhando para isso da maneira errada, mas "dependência de pessoa-chave" para qualquer escolha parece uma pista falsa. Com a adoção, a dependência da pessoa-chave é totalmente eliminada. O WordPress já foi um projeto de dependência de pessoa (s) chave (Mike e Matt) também. Acho que é um argumento fraco para evitar a adoção.

Mais uma vez, posso estar pensando sobre isso de maneira totalmente errada, mas é um fio de pensamento comum que vejo surgindo de vez em quando e não entendo sua importância aparentemente alta.

Para complementar o comentário de @swissspidy , mostrar em vez de contar é algo que também pode ajudar. Se as pessoas tiverem uma opinião forte sobre uma substituição, demonstre a mudança e como o código ficará em um branch (assim como # 2734 está fazendo no Preact). Não importa qual seja a decisão final, Gutenberg ficará melhor com a exploração, em vez de bagunçar um tópico de discussão.

Eu votaria no VueJS! É de longe o mais fácil de se adaptar pela comunidade.

Eu acho que os componentes da web (sem Polymer, mas com lit-html ou similar se um DOM virtual for necessário) devem ser considerados seriamente. Usar a plataforma e os padrões é muito melhor do que qualquer biblioteca ou estrutura! Proporciona uma estrutura de componentes robusta e segura para o futuro, que é naturalmente interoperável com todos os frameworks. (Vue, Angular, React - em um grau diferente atualmente: 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

Estou feliz em ajudar este projeto testando o Vue ou componente da web, se necessário.

Verifique também PR # 2463 para Gutenberg _ "Framework-agnostic block interoperability (Vanilla, Vue)" _

Sugiro inclinar-se para o Vue.js por alguns motivos.

1. Histórico comprovado no framework PHP Laravel.
2. Parece ser fácil de entender e adotar, então mais pessoas podem contribuir.
3. Se estamos nos afastando do React, vamos fazer uma mudança clara e definitiva para longe dele (usar o Preact parece que estamos nos agarrando a ele (React) em certo sentido).

Apenas minha opinião, mas parece ser a melhor escolha e muitas outras pessoas parecem favorecer Vue também, pois é pelo menos algo a considerar de qualquer maneira.

O Vue parece ter mais ímpeto e melhor suporte da comunidade do que o Preact. Ele resolve mais problemas (porque vem com gerenciamento de estado) e tem uma curva de aprendizado mais suave. A documentação é _excelente_.

Minha preocupação com o Preact é que é muito parecido com o React para parecer legalmente seguro (as patentes do React podem cobrir o Preact), e muito diferente do React para ser uma porta simples (há diferenças _suficientes_ para quebrar bibliotecas auxiliares, plug-ins etc.).

Vue todo o caminho baby !!

• [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/)

Github Stars -> Aqui
Ficaria absolutamente emocionado com o desenvolvimento de WordPress se Vue.js 🖖

Vue desenvolveu uma grande comunidade ao longo do tempo, além de atualizações / upgrades regulares para a estrutura.

PS. junte-se a https://chat.vuejs.org para uma experiência incrível na comunidade .. alguns desenvolvedores realmente idiotas lá :)

@jbreckmckye Não quero atrapalhar a conversa, mas você entende do que se trata a cláusula de patente? Trata-se de proteger o Facebook de processos de patentes de outras empresas. Por exemplo, digamos que minha empresa fabrica geladeiras inteligentes e usamos o Rea na IU. Digamos que temos uma patente sobre isso, e então o FB começa a infringir essa patente ... se processarmos, não podemos mais usar o react.

Não tem nada a ver com patentes em reação (que eu nem tenho certeza se o Facebook tem ... caso contrário, preact, vue e qualquer outra pessoa com uma estrutura semelhante teria sido processada até agora)

Como membro principal do Vue.js, gostaria de abordar a questão do fator de barramento. Sabemos que este é um ponto muito levantado, agora estamos implementando medidas para resolver algumas das preocupações.

1) Conta organizacional Vue.js para npm, para que possamos publicar como uma equipe mais facilmente
2) Gerenciamento interno de detalhes para manter as coisas funcionando (sites, etc)
3) Inicializando um coletivo aberto, para atrair colaboradores e apoiar a comunidade em crescimento. https://medium.com/the-vue-point/vue-is-now-on-opencollective-1ef89ca1334b
4) O ecossistema Vue cresceu rapidamente e cada vez mais as contribuições do repositório central vêm da própria comunidade. https://www.youtube.com/watch?v=993X1kiisFE
5) Ao olhar para os repositórios oficiais do Vue, você pode ver que, na verdade, muitos deles agora são mantidos fortemente por outros membros da equipe principal, mais do que Evan

Em geral, o Vue.js está crescendo rapidamente e o 'Fator de barramento' foi reduzido significativamente. Como @philiparthurmoore observou, Evan sempre terá um grande envolvimento e isso é uma coisa boa.

Parece que há muitos fãs de VueJS aqui. Alguém realmente migrou uma grande base de código do React para o Vue? Como é o caminho de migração?

Pelo que posso ver, o Preact parece uma escolha muito mais pragmática, visto que é compatível com o React. Considerando que a migração para o Vue exigiria uma reescrita muito mais extensa.

@patrickgalbraith Essa é realmente a razão errada para considerar o Preact. Deve ser julgado por seus méritos e não porque seja mais fácil migrar para ele. Posso ver os seguintes problemas com o Preact

• Comunidade menor em comparação com VueJS
• Cheiro de código - A transição para uma biblioteca muito semelhante pode forçar práticas inadequadas (pela razão óbvia de ser o caminho mais rápido)
• Ficar com Preact é como ficar com React de qualquer maneira (leia em um tópico)

Só usei o Preact de uma forma limitada, então, isso é exatamente o que eu penso.

@blake-newman Obrigado por passar por aqui e esclarecer isso. 💯

Deve ser julgado por seus méritos e não porque seja mais fácil migrar para ele.

Sim. Esta é uma decisão de longo prazo.

@patrickgalbraith se todo o projeto estivesse completo, eu consideraria isso um argumento justo. Pois seria uma peça de migração para evitar problemas de licenciamento.

Como o projeto ainda está em seus estágios iniciais, como @ahmadawais , não é um problema.

Além disso, Vue, React e Preact têm paradigmas muito semelhantes. Você pode alternar facilmente entre os dois, haverá diferenças.

Existem também, embora provavelmente não totalmente práticos neste caso, ferramentas que podem ajudar na paz da migração. https://github.com/SmallComfort/react-vue

Embora não seja uma comparação das mesmas ferramentas, este artigo levanta grandes pontos a serem considerados. https://medium.com/unicorn-supplies/angular-vs-react-vs-vue-a-2017-comparison-c5c52d620176

@blake-newman são realmente apenas os estágios iniciais, embora considerando que já tenham mais de 6 meses de desenvolvimento? Também tenha em mente que Calypso também tem mais de dois anos.

De qualquer forma, tenho certeza de que não será um problema, pois, dado o que você disse, é fácil alternar entre React e Vue. Estou ansioso para ver o pull-request para isso.

O estêncil também parece promissor.

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

Minha opinião é que esses 2 pontos são um caso forte para Vue:

• Amigável para iniciantes e ..
• Grande quantidade de apoio da comunidade

Ambos são, na minha opinião, 2 dos pilares centrais do projeto WordPress.

Posso estar sozinho, mas tenho observado o Patreon de Evan bem de perto nos últimos seis meses ou mais, e dizia que, se ele não conseguisse financiamento por meio dele, precisaria trabalhar mais.

É um risco real quando um projeto tem baixo financiamento E é escrito basicamente por uma pessoa (há menos de seis meses). Seus números do Patreon diminuíram recentemente. Se o cara principal disser que talvez não consiga trabalhar nisso se as finanças não estiverem alinhadas, então as finanças são um risco muito real. A escolha da estrutura de um projeto grande e de longo prazo, dependendo se um (incrível) desenvolvedor pode pagar o aluguel do SF é um grande negócio.

Claro que a Vue poderia ser generosamente apoiada por outras empresas, mas é difícil saber disso.

A adoção da comunidade também não garante a longevidade do framework, pessoal. Se você não percebeu, os frameworks 'morrem' o tempo todo.

Dito isso, estou impressionado que um membro da equipe principal do Vue apareceu para realmente resolver o problema do único contribuidor / fator de ônibus, até mesmo pelo nome, e deu alguns motivos para que o problema do desenvolvedor único possa ser menos problemático. Mas foi um problema real no passado muito recente.

eu voto para Vue

• API simples / você pode aprender as coisas mais básicas em uma semana
• implementação de fluxo simples via vuex
• resultados rápidos: P
• comunidade em crescimento
• MIT

Mais uma votação para Vue, por todas as razões expostas acima. Minhas desculpas a qualquer pessoa com notificações de e-mail ativadas!

@ michaelbdavidson7 , Vue acabará por contar com a contribuição de Evan e a campanha do Patreon foi para apoiá-lo a fazer um trabalho melhor do Vue. Ele não recebendo o suficiente por meio do Patreon e assumindo outro trabalho, não acho que prejudique a Vue. Como @blake-newman (um contribuidor principal do Vue) sugeriu (e o próprio Evan alguns meses atrás), Vue não depende mais de apenas uma pessoa. Tanto quanto o WordPress não depende de uma pessoa. Temos Matt, sim, mas o WordPress pode continuar em alguma encarnação sem Matt (desculpe Matt;)). O mesmo é verdade para Vue (desculpe Evan;)).
@ahmadawais, que também acho que não é preciso no que diz respeito à "dependência de pessoa chave".

Se esse objetivo for alcançado, posso passar menos tempo pensando em canais privados de monetização (por exemplo, assumindo contratos de suporte / consultoria) e, em vez disso, trabalhar mais em conteúdo que beneficie toda a comunidade Vue ...

^ Esse objetivo não foi alcançado e nem chega perto. Supondo que ele quis dizer o que disse, ele ainda pode estar pensando em contratar e, se isso mudou, deve ser considerado um desenvolvimento muito recente. Ainda está lá no momento. Se a pessoa-chave está contratando para pagar o aluguel, há o risco de ela não continuar trabalhando na estrutura e, se isso mudou, então mudou muito recentemente.

Todos vocês que estão gritando frameworks pelo nome não aprenderam nada nos últimos anos lol.

@ michaelbdavidson7 O objetivo foi cumprido para ajudar Evan a trabalhar nisso em tempo integral. O objetivo adicional existe para ajudar a apoiá-lo ainda mais e em parte à comunidade. Daí o nascimento da campanha coletiva aberta, que tem como único objetivo apoiar a comunidade.

Também destacarei que a campanha do Patreon não é a única fonte de receita por meio de contribuições; infelizmente, o Patreon não é adequado para todas as empresas patrocinadoras. Assim, algumas contribuições são pagas e faturadas separadamente.

O motivo pelo qual o número caiu é porque um dos patrocinadores era da China e há um limite para a quantia de dinheiro que pode ser debitada da China em um ano. Isso é apenas temporário e espero que volte ao suporte.

Os outros canais de renda que Evan obtém por meio de oficinas não são apenas úteis para a comunidade, mas também para ele. Dessa forma, ele pode obter exposição direta para auxiliar no aprendizado de como a biblioteca será e como será utilizada. Portanto, não é tão ruim quanto parece.

O Vue é sustentável e não falo em nome do Evan, mas tenho certeza de que ele está muito feliz com a atual situação das finanças.

Uma coisa que apreciei no React foi a documentação de acessibilidade . Eu acho que isso é algo para estar ciente e considerar ao pensar sobre novos frameworks. Existem princípios de acessibilidade mencionados aqui que se aplicam a qualquer aplicativo da web escrito de forma defensiva, mas ter alguma documentação específica da estrutura pode ser útil.

Vue.js tem um problema aberto para acessibilidade . Uma rápida olhada em Preact e não vejo muito; é seguro presumir que a documentação do React se aplica?

Em última análise, seria ótimo ter uma estrutura que tornasse os testes programáticos para todos simples e automáticos, para que pudéssemos eliminar a maioria dos erros e avisos todos.

Se você deseja uma transição fácil apenas por causa da licença, uma opção que você pode considerar é o InfernoJS. https://github.com/infernojs/inferno oferece quase a mesma API com pegada menor e tempo de execução mais rápido. É licenciado pelo MIT. Sou um dos mantenedores do inferno e pude ajudar na transição.

@Havunen, obrigado por passar por aqui. Eu estava pesquisando o Inferno outro dia, não tentei ainda. Parece promissor de qualquer maneira!

Para fins de contexto, o autor do Inferno foi contratado pelo Facebook

Eu voto em markoJS http://markojs.com/

Gutenberg usa alguns recursos novos do React 16, ou seja, Portais e possivelmente Fragmentos , que tanto o Inferno quanto o Preact não suportam, então isso pode ser levado em consideração ao falar sobre bibliotecas semelhantes ao React se o uso desses recursos for crítico para o gutenberg.

Eu sugeriria DIO 8 principalmente porque é a coisa mais próxima do React 16 neste ponto em termos de API.

Dito isso, pode ser uma boa experiência de curiosidade configurar o Gutenberg com o alias das bibliotecas semelhantes ao React mencionadas e ver se elas funcionam sem quaisquer alterações / problemas para quem quiser.

Não tenho certeza se eles são exatamente iguais, mas para os portais, existe o vue-portal desenvolvido por @LinusBorg , um dos principais membros da equipe vue :)

@youknowriad fui contratado pelo Facebook. @Havunen e a equipe por trás do Inferno estão fazendo um ótimo trabalho sem mim. O trabalho que eles estão fazendo no Inferno é incrível e o projeto vale a pena conferir o Inferno se você tiver uma chance :)

Sou um dos autores do Marko.js e gostaria de colocar o Marko.js no ringue para consideração. Vários membros da nossa comunidade entraram em contato conosco e nos indicaram este problema do GitHub. Marko.js tem uma licença MIT de código aberto e está sendo usado para construir o eBay.com e tem uma comunidade forte e crescente. Ele traz várias boas ideias do React e do Vue, mas nos esforçamos muito para tornar as coisas mais simples e rápidas (por meio de otimizações em tempo de compilação) e removemos o clichê sempre que possível. Eu só queria destacar alguns dos recursos abaixo:

Componentes da IU

O modelo de componente de Marko é conceitualmente muito semelhante ao do React (entrada, estado, associação de evento, eventos de ciclo de vida, renderização virtual de DOM, diffing / patching de DOM, etc.). Uma transição no Calypso não exigiria muita sobrecarga cognitiva. Marko também oferece suporte a componentes de IU de arquivo único. Esta é a aparência de um componente de IU do 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>

Sintaxe

Marko não usa JSX, mas um superconjunto de HTML que oferece suporte a expressões JS. É muito semelhante ao HTML, mas não totalmente limitado a HTML como o Vue. Isso fornece uma sintaxe mais agradável para coisas como loops e condicionais e torna mais claro onde as expressões estão sendo usadas em comparação com uma string HTML padrão. Achamos que os modelos do Marko.js são extremamente legíveis e fáceis de manter (o Marko também oferece suporte a uma sintaxe concisa e baseada em indentação).

Renderização do lado do servidor

Não sei o quão importante é para o WordPress, mas Marko também oferece suporte a renderização do lado do servidor de alto desempenho em Node.js com suporte para renderização assíncrona e streaming.

Leitura adicional:

• Marko vs React
• Tiroteio de renderização do lado do servidor com Marko, Preact, Rax, React e Vue
• Por que Marko é rápido?
• 10 recursos incríveis do Marko
• Meetup: Construindo a IU - uma comparação de React, Vue e Marko (do criador do Marko) - Vídeo | Slides

Eu voto no Marko !! 🙂

Se alguém da equipe do WordPress (@ahmadawais? @M? @Swissspidy?) Quiser ter um bate-papo rápido para responder a quaisquer perguntas sobre o Marko, nós, a equipe do Marko, ficaremos felizes em fazer isso. : call_me_hand: 😸

@I comentou isso no blog da @m, mas queria publicá-la aqui de uma forma mais pública:

Eu recomendo o ecossistema Ember incluindo Ember e Glimmer.js.
Para componentes da web menores, como queda em editores e outros comportamentos de conteúdo, Glimmer oferece uma ótima experiência e cria queda em componentes da web que podem ser executados fora de uma estrutura.

Para projetos maiores, como Guttenberg e Calypso, onde roteamento, gerenciamento de estado complexo, controle de acesso, gerenciamento de conteúdo e muito mais entram em cena: Ember fornece o melhor conjunto de ferramentas e ecossistema
Com um grande conjunto de contribuidores: os padrões definidos, complementos e sistema de construção do Ember ajudam a manter o desempenho dos aplicativos e a sua manutenção à medida que eles aumentam.
Ember Engines e addons in-repo ajudam a manter peças opcionais do aplicativo modulares e instaláveis ​​para os usuários finais.

O Ember está sendo usado intensamente por outros sistemas de gerenciamento de conteúdo e esse esforço pode ser desenvolvido, aprendido e compartilhado.
Conforme mencionado em um comentário anterior no blog de @m , o Ghost usa o Ember como administrador e editor, mas o Ember também é usado com Drupal headless, Cardstack e empresas de conteúdo como Conde Nast , Bustle e muito mais.
Isso significa que recursos comuns como listas de tags, editores baseados em componentes (especificamente o editor do ecossistema Ember Addon .

A partir de uma experiência de comunidade e desenvolvedor, o Ember combina melhor com o ecossistema Wordpress (como um desenvolvedor que trabalhou no Wordpress por mais de 5 anos).
O Ember tem muitas práticas recomendadas incorporadas, bem documentadas ou disponíveis por meio de complementos; isso reduz a questão de "isso funcionará com meu aplicativo" e ajuda a reduzir melhor possíveis bugs de segurança ou desempenho.
O Ember é construído em abstrações personalizáveis, o que significa que a complexidade pode ser abstraída dos desenvolvedores finais e códigos difíceis podem ser limitados em escopo para tornar a personalização fácil e divertida.
Os complementos do Ember são muito parecidos com os plug-ins e temas do Wordpress, pois são descobertos automaticamente e têm configuração padrão pronta para uso, mas podem ser personalizados para atender às necessidades do usuário final.
Existe uma ferramenta de curadoria existente para os complementos do Ember chamada Ember Observer para ajudar a encontrar os complementos mais populares, mais bem mantidos e mais estáveis.

Calypso e Guttenberg são projetos grandes e ambiciosos com necessidades maduras. A comunidade Ember tem soluções maduras para acessibilidade, internacionalização e outros requisitos de aplicativos da web modernos.

Faço parte da Equipe de Aprendizagem do Ember.js e trabalho junto com os principais colaboradores. Adoraria conversar ou iniciar uma conversa com outros membros da Equipe do Ember sobre como o Ember e o Glimmer podem atender às suas necessidades.

Percebi que houve menção aos portais React e gostaria de acrescentar mais 2 centavos de que o Ember tem um addon bem mantido chamado Ember Wormhole para fornecer essa funcionalidade e muitos addons construídos em cima disso para fornecer recursos como diálogos, mudanças no cabeçalho do documento , e mais.

Eu votaria no Marko por seu suporte nativo de renderização assíncrona e desempenho rápido do lado do servidor. !!!

@ patrick-steele-idem & @mlrawlings - obrigado por passar por aqui. Eu sei que MarkoJS é muito poderoso. Embora eu não tenha tido a chance de usá-lo em um projeto, eu liderei um projeto em que os desenvolvedores estavam usando o MarkoJS para seu mecanismo de renderização de animação rápida, ou mais. Isso foi muito diferente e impressionante.

Vou cavar mais.

Trabalhei com o Ember.js em uma organização empresarial muito grande, onde os aplicativos eram executados em outros aplicativos, e em uma inicialização muito pequena com pequenos aplicativos independentes. As fortes opiniões e convenções do Ember.js ajudaram a manter uma base de código produtiva e sustentável à medida que as equipes e os aplicativos crescem. Ele não apenas permite a capacidade de compartilhar código (por meio de mecanismos ou complementos) entre projetos, mas também permite que um desenvolvedor que aprendeu as convenções seja produtivo e contribua com praticamente qualquer aplicativo Ember.

O maior benefício do Ember foi sua estabilidade sem estagnação. Sem ter que mudar nenhum de nossos modelos, tivemos enormes benefícios de desempenho quando a nova versão do Ember foi lançada, que refatorou totalmente o mecanismo de renderização sob nós. Os níveis de abstração parecem certos para aplicativos da web modernos e ricos que podem crescer e precisam ser escalonados em um futuro distante.

Quando as mudanças são necessárias, a migração é uma preocupação central e os guias de descontinuação ajudam em cada etapa do caminho (mais recentemente, usando transformações AST / CST JavaScript para atualizar aplicativos automaticamente).

Outros aplicativos da web populares que usam o Ember não mencionados por @rtablada incluem Twitch.tv , o painel do Heroku , Travis CI e Discourse .

@SaladFork obrigado pela atualização, comecei nomeando principalmente empresas na área de gerenciamento de conteúdo.

Alguns exemplos de aplicativos Ember de código aberto em grande escala incluem:

• Travis CI
• Hospital Run - Um sistema EMR (Electronic Medical Record) construído para uso offline, especialmente em baixa conectividade na África
• Fantasma

Não tenho certeza de quanto ele pode entrar em detalhes, mas estou enviando um ping para

Eu votaria no Marko por seu desempenho, flexibilidade e sintaxe muito clara e de fácil compreensão!

1 para Marko, também. Tendo feito bem o trabalho de front-end antes de começar a perder cabelo e ficar grisalho (tipo, há muito tempo), tem sido a biblioteca / framework de front-end que venho procurando por todos esses anos. É um grande motivo pelo qual adoro trabalhar no eBay com @ patrick-steele-idem e @mlrawlings também.

Marko JS tem meu voto. Extremamente subestimado considerando sua facilidade de uso e desempenho.

Eu amo o marko-widget junto com o marko eficiente. estrutura simplesmente excelente e enxuta. É muito mais rápido do que outros frameworks. A referência está aqui

Eu voto no MarkoJS, nós fomos uma loja de guidão por muitos anos.

Quando fizemos a mudança estratégica para entrar em microsserviços e habilitar a arquitetura baseada em componentes para nossa plataforma, estávamos procurando a estrutura certa para ter um equilíbrio entre a renderização do lado do servidor e a renderização do cliente. Somos uma plataforma que tem classificados em 6 mercados diferentes, incluindo mercados emergentes como África do Sul e México, onde os dados são uma grande preocupação e precisamos ter um site que realmente respeite os requisitos de navegação do usuário em dispositivos que têm poucos anos e também usam menos dados. Além disso, o usuário estará navegando no site para frente e para trás até encontrar um item que goste de comprar, o que significa que precisamos ter uma renderização de servidor muito rápida acontecendo enquanto o usuário navega.

Após uma consideração cuidadosa, escolhemos o MarkoJS com o fato de que ele suporta:

1. Renderização rápida do servidor com bom desempenho do servidor
2. Empurra o primeiro byte o mais rápido possível
3. Capacidade de construir componentes secundários e renderizá-los de forma assíncrona quando os dados estiverem prontos
4. Capacidade de construir uma arquitetura de componente plug and play
5. Maximize a renderização do cliente com a mesma ou melhor arquitetura do React / Vue.
6. Testes conduzidos por componentes que podem ser usados ​​não apenas para testar a renderização, mas também o estado do componente

(Uma história de sucesso do eBay Classifieds)

+1 para Angular (NÃO AngularJS).

O Angular CLI é de longe o melhor de todos os frameworks, e com planos de migração em estoque para uma migração perfeita entre as versões, ele se encaixaria muito bem.

Além disso, o Angular é altamente adotado no reino empresarial, onde o WordPress poderia usar um pouco de amor se o WordPress continuar a crescer como uma plataforma para consultores e freelancers, e deixar de ser apenas uma corrida para o fundo.

Possui uma comunidade robusta de desenvolvedores de todos os níveis. É sempre incrível conversar com a equipe principal, quer trabalhem para o Google ou não. WordPress é em grande parte (para a maioria dos desenvolvedores de alto nível) uma comunidade na qual eles estão envolvidos, então direi que em termos de comunidade, o Angular se ajusta perfeitamente

Eu fiz uma palestra recentemente sobre o Vue em ambientes renderizados por servidor ( slides aqui ), e tendo trabalhado com o Vue em um ambiente .NET nos últimos meses, estou convencido de que não há nenhuma outra opção para trabalhar em ambientes Curtiu isso. Você obtém uma combinação realmente excelente de ser capaz de decompor o que precisa ser puxado para JS para interatividade pesada, enquanto permite que o back-end continue a controlar principalmente o site.

O que significa que é praticamente perfeito para construir em cima do que o WordPress tem agora. Qualquer outra biblioteca JS renderizada por servidor provavelmente exigirá um nó. Vue não; você pode registrar um componente como <gutenberg-editor> e fazer o WordPress enviar literalmente <gutenberg-editor> no HTML. O Vue pode usar o HTML enviado pelo WordPress para inicializar a página. Nesse aspecto, é um pouco parecido com os componentes da Web e não requer outra peça da tecnologia BE para obter a renderização do servidor.

É uma das razões pelas quais um framework como o Laravel o escolheu como padrão: é muito fácil de integrar em back-ends não-Node. Acho que o WordPress deveria adotá-lo pelos mesmos motivos.

Votei em Vuejs .
O mesmo caso com @borantula em seu comentário

Meu CTO apresentou os Vuejs à equipe - novatos no Front-end, e eles rapidamente entraram, agora estão felizes com os Vuejs. Minha equipe usa WordPress em muitos projetos.
Atualmente, estamos usando Vuejs e Custom Element para fazer o front-end de um projeto que usa WordPress no backend. Funciona muito bem.

Como @blake-newman e Evan disseram, Vuejs não depende mais de uma única pessoa chave, então pode-se dizer que os CONTRAS que @ahmadawais mencionou não existem mais.

MARKO funciona bem em nosso aplicativo da web. A renderização progressiva funciona perfeitamente.

Não posso dizer nada sobre Preact ou MarkoJS (muito referido nos comentários), mas posso falar sobre Vue quando apresentei à nossa equipe (trabalhando principalmente em php + jQuery naquela época) um ano atrás e isso gradualmente mudou sua compreensão de javascript, saindo do estado de espírito do jQuery.

Acho que seria uma boa escolha não apenas para Gutenberg, mas também para o objetivo de longo prazo do WordPress, fazer a transição para uma plataforma mais orientada para API com mais javascript nas interfaces. É mais fácil a curva de aprendizado e a familiaridade encorajará outros desenvolvedores do WP a intervir também.

Eu vi como o VueJS prosperou na comunidade Laravel e quase se tornou uma escolha de fato para a maioria, acredito que também será assim na comunidade WordPress.

Backbone.js

/ s

Queria dar meu apoio ao MarkoJS.

Dois anos atrás, mudei a infraestrutura da minha empresa de ExpressJS e Jade (agora PUG) para Marko JS. Minha empresa queria criar componentes complicados e reutilizáveis ​​em todo o nosso ecossistema. Os desenvolvedores queriam velocidade e capacidade de reutilização. Os designers queriam uma carga de design reduzida. Não olhamos para trás desde então.

Agora temos vários sites voltados para o cliente escritos em Marko e um sistema CMS inteiro também.

Por fim, escolhi o MarkoJS para o seguinte:

• Renderização rápida de servidor, mesmo com estruturas como Koa e ou ExpressJS
• Lida com renderização assíncrona de dados da página
• Capacidade de construir componentes plug and play para um ecossistema maior
• Melhor desempenho do que React / Vue
• Sintaxe de modelo extremamente fácil

Também gostaria de salientar que a equipe MarkoJS tem sido literalmente estelar. @ patrick-steele-idem e @mlrawlings sempre estiveram a bordo para instituir novas ideias, corrigir problemas e ajudar indivíduos.

👍 para MarkoJS

Preact é uma biblioteca compatível com React-API, o que significa que Preact se beneficia diretamente do ecossistema do React e do grande número de pacotes / componentes OSS disponíveis. O ecossistema de Vue é muito menor em comparação. A documentação para pacotes / componentes Vue de terceiros está em chinês.

Por favor, chega de "Eu voto XYZ", eles não fazem nada para adicionar à conversa além de enviar respostas desnecessárias para pessoas inscritas nesta edição

🔥 Angular

• PRO: Maior concorrente a reagir
  Para muitas pessoas. a pergunta geralmente é "Angular ou reagir?" / "React or Angular?". A comunidade Angular é indiscutivelmente a maior entre as alternativas do React e está crescendo rapidamente.

• PRO: Muitos recursos de aprendizagem
  Além dos documentos e guias oficiais da API, o Angular provavelmente tem o maior ecossistema de materiais educacionais, postagens em blogs, livros e muitos cursos em vídeo, tanto gratuitos quanto comerciais em todas as principais plataformas de aprendizagem, além dos GDEs do Google que ensinam isso em workshops e conferências.

• PRO: Integra-se bem com Redux
  Diretamente ou via RxJS habilitado Ngrx (apoiado por um membro da equipe Angular)

• PRO: Melhor suporte de ferramentas da classe

  • CLI tem muito mais recursos do que outros

  • Muito bom suporte ao editor no VS Code, especialmente com o serviço de linguagem

  • Escrito para TypeScript, oferece a melhor experiência em TypeScript

• PRO: rico em recursos, opinativo e organizado por padrão
  A separação lógica por meio de módulos angulares (NgModule), bem como recursos padrão para formulários, chamadas HTTP, roteamento, etc. torna mais fácil para outros desenvolvedores ler o código e contribuir para ele

• PRO: Melhor integração com RxJS
  Útil para muitos fluxos de API e muitos fluxos de eventos em uma página em geral

• PRO: Sistema DI integrado (injeção de dependência)
  Útil para criar pontos de extensibilidade e talvez até mesmo um sistema de plug-in, especialmente quando combinado com RxJS

• PRO: marca muitas outras caixas que outras bibliotecas cobrem

  • Bibliotecas UI com licenças permissivas
    Existem PrimeNg, Angular Material 2, ngx-bootstrap e muitos mais ...

  • Carregamento lento
    Suporte integrado para rotas de carregamento lento e também suporta módulos de carregamento lento manualmente

  • CSS específico do componente
    Garante que o CSS tenha como escopo apenas o componente, carregado apenas quando o componente for carregado e tenha ganchos para CSS global

  • Renderização do lado do servidor
    Já trabalhando com Node e ASP .NET Core, e obtendo melhor foco atualmente

  • Testando
    O Angular fornece auxiliares de teste agnósticos de estrutura de teste de unidade que tornam o teste de unidade muito fácil. Eles geram testes por padrão a partir da CLI usando Jasmine, que pode ser facilmente alternado para Jest. Eles também fornecem um transferidor de invólucro Selenium opcional para tornar o teste E2E mais fácil (embora você não precise realmente dele, eu uso Selenium .NET para meus aplicativos Angular, nada específico do Angular, mas eles tentam torná-lo ainda mais fácil).

  • Suporte móvel / PWA
    O Google é o maior apoiador de PWAs, e o suporte está sendo mostrado no Angular CLI já com Service Workers e Universal (suporte do lado do servidor) e Ionic (suporte Cordova) e NativeScript (aplicativos nativos)

• PRO: Foco no suporte do navegador
  Com uma página de polyfills dedicada nos documentos e inserindo polyfills (comentados) por padrão na CLI, o Angular mantém você informado sobre quais polyfills exatos você precisa para, digamos, IE <= 11, portanto, não é necessário carregar um polyfill muito maior definido sem motivo. Isso porque eles se preocupam com o suporte do navegador.

• PRO: Apoio de grande empresa
  Angular é uma das poucas bibliotecas discutidas aqui (a única?) Que é apoiada por uma grande empresa.
  Ao apoiar aqui, não apenas uma empresa que o usou em alguns projetos e contribuiu para o ecossistema, mas sendo mantenedores oficiais que pagam desenvolvedores e redatores técnicos para trabalhar em tempo integral e investem em líderes comunitários (GDEs e DevRel no caso do Google).
  Este é PRO não um CON porque vem com licença MIT sem cláusulas extras, sem notas de revogação ou qualquer outra coisa que pode ser confusa ou assustadora para algumas pessoas.

Implementei Vuejs para alguns projetos, como plug-ins, API REST. Devo dizer que é fácil de aprender, tem muitos recursos, comunidade enorme e seu ecossistema também é bom.

Hoje em dia, Vuejs está crescendo rapidamente. Será uma escolha inteligente se o Vuejs estiver integrado ao código do WordPress.

@cyberwani @thephilip @evoratec e outros.

@ntwb já respondeu o seguinte comentário:

Por favor, chega de "Eu voto XYZ", eles não fazem nada para adicionar à conversa além de enviar respostas desnecessárias para pessoas inscritas nesta edição

Então, por favor, pare de fazer comentários inúteis. Para mostrar seu apoio, você pode usar emojis github para curtir um comentário favorecendo sua biblioteca.

Vue.

A propósito, agora existe o Alibaba por trás do Vue, assim como o projeto Weex Apache, que permite a API Vue no celular.

Eu realmente colocaria alguma moderação aqui, muitos fãs meninos sem argumentos claros

Este é o aviso final, a próxima etapa é começarmos a excluir os comentários ...

Eu mesmo não usei Marko, Preact ou Vue.js, não estou familiarizado com nenhum deles, para ser honesto, adoraria ouvir e ler o que a comunidade WordPress tem a dizer sobre esses frameworks, cada um deles, os méritos técnicos de cada um, o ecossistema circundante de cada um, as ferramentas de construção e, por último, mas não menos importante, as pessoas e comunidades por trás desses projetos. 😄

Eu não quero ler "Meu voto é para XYZ", se você quiser adicionar um voto, role para cima e adicione uma reação emoji _thumbs up_ à sua estrutura de escolha que já foi mencionada acima. 👍

Não demorou muito para que dois novos comentários aparecessem desde o meu comentário anterior 😞

Para o efeito ... Se o seu comentário foi adicionado após https://github.com/WordPress/gutenberg/issues/2733#issuecomment -329705942 e tudo o que você disse é _ "Eu voto em XYZ" _ ou envie uma mensagem de texto para isso efeito, seus comentários têm uma chance muito alta de serem excluídos , comentários futuros do mesmo tipo também serão removidos .

Se você está voltando a este problema e se perguntando por que seu comentário foi excluído, é por isso

@ahmadawais Tenho alguns comentários.

A migração de Gutenberg de React para ...?

A respeito de:

@patrickgalbraith Essa é realmente a razão errada para considerar o Preact. Deve ser julgado por seus méritos e não porque seja mais fácil migrar para ele. Posso ver os seguintes problemas com o Preact

• Comunidade menor em comparação com VueJS
• Cheiro de código - A transição para uma biblioteca muito semelhante pode forçar práticas inadequadas (pela razão óbvia de ser o caminho mais rápido)
• Ficar com Preact é como ficar com React de qualquer maneira (leia em um tópico)

Acho que quando você tem um projeto com um número não trivial de linhas de código, você precisa ter muito cuidado. Os engenheiros gostam de reescrever coisas, de aprender novas linguagens e frameworks, e acham que farão um trabalho melhor se puderem reescrever esse código ... Joel falou sobre o perigo de reescrever de maneira bastante eloquente há muito tempo .
Usar o Preact economizará muito tempo. Você pode subestimar o tempo que levará para mudar para uma estrutura completamente nova. Não sei por que você escreveu "Essa é realmente a razão errada para considerar o Preact". Como engenheiro, os custos e o tempo de lançamento no mercado estão no topo da lista de critérios que utilizo para avaliar e escolher soluções.
Se o problema é mesmo a patente do Facebook, Preact resolve minimizando os custos. Preact tem mais desempenho do que React e até mesmo Vue: pegada menor e renderização de tempo de execução mais rápida. Verifique também o artigo de Addy Osmani sobre isso .

Não tenho certeza de como você avaliou o tamanho da comunidade Preact. Se estamos falando sobre o ecossistema e os componentes disponíveis, o uso do Preact permite que você use a maioria dos componentes de código aberto do React. Portanto, para uma questão prática, você tem pessoas que, mesmo que não estejam trabalhando explicitamente no Preact, ainda estão produzindo código do qual você pode tirar proveito. Você ainda pode considerar o ecossistema de React como parte do ecossistema de Preact.

Por que o Vue ainda é sua opção favorita?

Acho que o terceiro ponto aqui "Manter o Preact é como usar o React de qualquer maneira" é provavelmente a principal razão pela qual você está hesitando em escolher o Preact. Estou errado? O que há de errado com o React além de sua patente?

Olhando para o quadro geral

Eu li que o que você escolher para Gutenberg também será usado para Calypso.
Gutenberg está usando o React apenas no frontend. Quando você olha para a renderização do lado do servidor, a situação se torna mais complexa, mas Preact ainda parece uma opção de migração mais fácil.

Eu acho que você precisa olhar seus critérios. Se você está pensando seriamente em reescrever e manter a renderização isomórfica é importante, MarkoJS parece estar no topo da lista de candidatos.

Se eu comecei do zero e estava disposto a ignorar o ecossistema React, o MarkoJS é um acéfalo.

Estou olhando para as atuações e o MarkoJS parece não ter rivais . 40x mais rápido que React, 10x mais rápido que Vue e 6x mais rápido que Preact é uma loucura. No meu livro, melhorias de 30% são irrelevantes, mas quando você tem uma melhoria de mais de 10 vezes, você precisa prestar muita atenção.
Quando você tem uma presença modesta de sucesso e pode usar 10 servidores em vez de 100, ou 2 em vez de 20, isso faz uma grande diferença.

Divulgação total Não tenho qualquer ligação emocional com Preact ou MarkoJS. Só acho que eles fazem mais sentido do que as alternativas de uma perspectiva de engenharia.

Boa sorte com sua decisão 😃

@ChrisCinelli esses são números ssr ...

Eu sou do mundo Drupal (estamos observando esta edição: D), então não tenho nada a ver com isso. Mas lendo os comentários, é óbvio que existem cerca de 5 frameworks "top" aqui e todo mundo gosta daquele que escolheram, então eles darão suporte a ele.

O aspecto da velocidade é irrelevante atualmente. Os únicos dois fatores que devem ser levados em consideração são: a) você realmente deseja reescrever tudo eb) como será a transição para os desenvolvedores do React e como será o aprendizado do vencedor para os novos desenvolvedores.

Existem camadas pré-compatíveis, compatíveis com inferno ... para uma transição fácil, mas o desempenho será prejudicado. Por outro lado, ele fará a transição suave com o tempo, nem tudo precisa ser reescrito de uma vez. Do ponto de vista de negócios, isso é um acéfalo. Do ponto de vista da comunidade e do futuro, não faz diferença.

Agora o DX é onde está tudo. Qualquer pessoa com experiência em fws reativos não deve ter problemas para fazer a transição para o novo fw simplesmente porque os conceitos são os mesmos, apenas a sintaxe é diferente. Mas o novato é quem importa. Quão difícil / fácil é ser produtivo no novo fw. Quão difícil / fácil é ler e entender o código existente. E isso reside exclusivamente em a) boa documentação eb) comunidade (fóruns, SO, salas de chat, blogs ..).

Não direi qual FW prefiro, pois, como disse, não sou um cara de WP. Mas eu queria dar meu 2c para manter sua cabeça fria quando se trata de uma decisão tão importante que influenciará milhares de desenvolvedores ao redor do mundo.

@ntwb: Eu não tenho o meu comentário excluído, mas eu acho exclusão de comentários, mesmo aqueles dos meninos fãs, como uma espécie de censura.

Por quê:

Se o seu comentário foi adicionado após # 2733 (comentário) e tudo o que você disse foi "Eu voto em XYZ" ou um texto nesse sentido, seus comentários têm uma grande chance de serem excluídos, comentários futuros do mesmo tipo também serão removidos .

Eu vejo muitos comentários de fan boys acima disso. Por que eles ficam?
Parece um padrão duplo.

Angular, é uma escolha clara. Acho que Roy e Meligy têm pontos fantásticos e os apoiam 100%. O WordPress está se movendo para o reino empresarial não apenas em uso, mas também em termos de metodologia de desenvolvimento.

Vou criar um link de uma fonte divertida: https://vuejs.org/v2/guide/comparison.html e, em particular: "... a complexidade do Angular é em grande parte devido ao seu objetivo de design de atingir apenas grandes e complexos formulários...". Essa declaração simples acerta o prego na cabeça. WordPress é, e sua direção futura continuará a ser, um aplicativo robusto e complexo.

@ChrisCinelli Simplesmente porque foi quando pedimos às pessoas que se abstivessem de dizer "Eu voto em xyz", eu entendo de onde você vem, mas acho que remover esses comentários seria uma má forma, eu não gosto do fato de que tinha que remova qualquer um deles

Não trouxe isso antes porque não queria atacar frameworks que não recomendei (tendo recomendado Angular acima), mas apenas para completar, há algo que precisa ser esclarecido com Preact e outras bibliotecas semelhantes ao React . Vou colocá-lo aqui e cabe ao WordPress decidir se é uma preocupação.

O que se segue é uma citação de uma postagem escrita por um advogado de patente / IP na licença React, (destaque em negrito é copiado da fonte):

Eu recebi muito "bem, então vamos todos usar [estrutura alternativa aqui]." Espere um segundo. Se as patentes do Facebook cobrem React (diferenciação, componentização, etc.), essas patentes provavelmente cobrem Preact / Vue / et al.

Mas o React concede a você uma concessão de patente! Com uma estrutura alternativa, você é um infrator desde o primeiro dia. Isso tudo se resume a saber se o Facebook tem patentes e seu desejo de aplicá-las, mas se você quiser fazer um jogo de guerra ao enésimo grau, as alternativas React são mais arriscadas .

Agora, se meu entendimento estiver correto, o WordPress não está deixando o React porque está preocupado com a licença em si, mas apenas em ter que levar essa licença para seus usuários, trazendo assim a confusão e a necessidade de defender a decisão para si mesmo.

Indo para uma alternativa React, pode haver menos a defender se a licença alternativa for permissiva, mas também pode haver alguma confusão no WordPress ainda.

Cabe ao WordPress decidir se isso é ou não algo com que se preocupar.

@ChrisCinelli obrigado por sua crítica construtiva. Eu o recebo de mãos abertas.

Como engenheiro, sei que custo e tempo estão no topo da lista. Mas é o seguinte. Este não é um projeto de uma determinada empresa corporativa. Os objetivos aqui são diferentes.

O objetivo é encontrar um JS FW que seja bom para a comunidade. Gutenberg ainda não foi lançado. Se funcionou, então Preact teria sido o vencedor claro.

Agora, precisamos cuidar disso:

• JS FW é fácil de adotar para o conjunto mais amplo da comunidade
• JS FW que escolhermos deve ter sua própria comunidade e ecossistema
• Um histórico comprovado com um software FOSS de produção baseado em PHP é uma vantagem. Vue + Laravel
• Escolher JS FW com base em seus méritos e não apenas porque é mais fácil de migrar para

Em 11 anos que passei com o WordPress, e como um contribuidor regular regular, acredito que escolher Preact criaria muita confusão. A curva de aprendizado já é enorme para desenvolvedores intermediários / novos.

Colocá-los na bagunça da compatibilidade Preact-React logo no início desta nova fase de melhoria do WordPress pode fazer com que eles deixem a comunidade WordPress e aprendam algo mais com a curva de aprendizado semelhante. (_DICA_: Laravel + Vue em vez de WordPress + Preact + React) E, a propósito, você está esquecendo que é isso que acontece com o Drupal 8?

Por favor, não remova comentários civis. Obviamente, há uma necessidade ou desejo avassalador de expressar uma opinião sobre esse assunto. Eu vejo isso como uma coisa boa, pois as pessoas estão dizendo que se preocupam com o WordPress e querem ser ouvidas. Lembre-se de que a comunidade WordPress, não apenas seus desenvolvedores, foram direcionados ao Github para fornecer feedback. Se realmente não podemos tolerar comentários de +1, adicione um registro no topo que preserva os nomes de usuário.

Se você está apenas procurando uma discussão fundamentada, muitos comentários do tipo "Eu voto em X, Y ou Z" podem parecer apenas ruído, mas há um padrão claro emergindo de pessoas apoiando Vue.js. Minha opinião é que temos centenas, ou algumas centenas de pessoas que contribuirão com código para Gutenberg, mas dezenas de milhares que escreverão plug-ins e temas que interagem com ele. O sucesso de Gutenberg não será apenas a experiência do usuário final, mas também a experiência do desenvolvedor. Não é a única coisa, mas uma coisa importante que torna o WordPress um sucesso é que ele é facilmente extensível.

Embora eu não tenha uma estrutura específica em mente, eu diria que devemos ter em mente que o suporte ao navegador está começando a se encaixar com os componentes da web, uma estrutura que utiliza componentes da web ou pelo menos seus próprios componentes construídos como eles seriam à prova de futuro. Também existem polyfills para trazer componentes da web para navegadores que não os suportam.

Fui mencionado anteriormente e vim aqui apenas para desligar as notificações, mas vou ponderar um pouco.

Se você está construindo um aplicativo de página única do zero, o tempo é essencial e você quer uma estrutura bem suportada, documentada e testável, tenho muitas experiências concretas que mostram que é muito mais barato em tempo e tesouro para vá com Ember.

Se você estiver criando mais de um PWA ou soltando componentes em uma página renderizada pelo servidor, o Ember é uma escolha ruim e posso ver por que algo como o Vue seria atraente.

Acrescentarei que, de um lado da convenção das coisas, criei alguns PWAs com> 90 pontuações de farol usando o Ember.

Em nosso último projeto em que precisamos fazer isso, o processo levou <1 hora para obter a pontuação do farol e implantar o aplicativo com a renderização do lado do servidor habilitada.

O SSR e o cache do service worker necessários para altas pontuações de farol podem ser um processo muito complicado.
Com o Ember, esse processo é muito fácil e requer apenas a instalação de alguns complementos bem documentados e mantidos (para a maioria dos aplicativos).
Pela minha experiência, o Preact vem com esses dois recursos prontos para uso no Preact CLI, no entanto, existem convenções populares (P) React que podem quebrar os resultados de SSR.
Com o Vue, os documentos oficiais recomendam usar Nuxt.js ou seguir o guia SSR completo ; ambos introduzem mais padrões que precisam ser seguidos além da documentação básica do Vue.

Não repreendendo ninguém, mas vamos adiar a exclusão de comentários sobre questões, a menos que sejam palavrões ou abusivos. Eu entendo totalmente as pessoas que querem ajudar e focar a conversa, mas não devemos entrar na espiral de exclusão de comentários.

Não tenho certeza do que é "bem documentado" sobre o Ember em comparação com o VueJS @rtablada .

Eu pessoalmente teria um problema ao começar em Ember em comparação com Vue ou mesmo React.

@ahmadawais Todo mundo esquece que esta decisão terá um grande impacto e você vai querer mudar o quadro de qualquer maneira em alguns anos. Portanto, você gostaria de usar a bondade da estrutura moderna, mas não se vincular a ela para viver ou morrer. Parece impossível? Não é!

Algum tempo atrás tive um problema semelhante e após pesquisas e tentativas cheguei a uma solução que tenta conectar a água com o fogo. Em poucas palavras - os elementos personalizados do Web Component, envolvendo a tecnologia que você gosta (por exemplo, Vue, React, Angular) e expondo a API DOM padrão.

Nessa solução, você terá vários componentes e cada um deles tem:

• estrutura que você gosta (mas é claro de preferência apenas uma)
• API DOM padrão que outros componentes podem consumir facilmente. Você pode até manipulá-lo via JavaScipt simples

Como eu trabalhava com o Vue naquela época, escrevi o adaptador do Custom Element para o Vue - https://github.com/karol-f/vue-custom-element - então você tem compatibilidade superior (por exemplo, $ emit enviar evento DOM padrão do Vue que pode ser capturado via JS simples ou por exemplo, React / Angular) e compatibilidade do IE9 +.

Eu recomendo olhar para essa solução como você:

• será à prova de futuro
• não será amarrado com nenhuma estrutura que você escolher hoje
• seus usuários verão elementos HTML padrão e podem interagir com eles com a estrutura de que gostam ou até mesmo com JS simples
• Não haverá inicialização manual do Vue, pois o navegador dirá a você e o componente de inicialização automática se estiver na página (você pode até carregar o componente lentamente)

e muitos mais.

Essa solução não está vinculada ao Vue - você pode usar qualquer outra estrutura que desejar. Além disso, os elementos personalizados do Web Component são recursos padrão do navegador e não irão para lugar nenhum!

Saudações!

Minha opinião é que temos centenas, ou algumas centenas de pessoas que contribuirão com código para Gutenberg, mas dezenas de milhares que escreverão plug-ins e temas que interagem com ele. O sucesso de Gutenberg não será apenas a experiência do usuário final, mas também a experiência do desenvolvedor. Não é a única coisa, mas uma coisa importante que torna o WordPress um sucesso é que ele é facilmente extensível.

Citando o comentário acima de @dmccan porque é um ponto muito importante de apoio ao Vue.

O WordPress democratizou mais do que apenas a publicação. Eu me pergunto quantas carreiras e negócios de sucesso em tecnologia foram lançados devido à acessibilidade do WordPress. Minha, com certeza.

Vou jogar meu chapéu a favor de VueJS. O encontro local de JavaScript aqui é co-liderado por um dos membros da equipe principal da VueJS e parecia ser aquele com o qual as pessoas que participaram poderiam embarcar muito mais rápido do que outras. Minha experiência anterior foi com AngularJS e descobri que o VueJS é incrivelmente mais fácil de aprender e simplesmente comecei a programar, embora estivesse começando do zero.

Vejo que algumas pessoas estão falando sobre empresa e, portanto, Angular, mas embora o WordPress possa precisar de um pouco de amor nessa área, acho que a decisão deve se basear, além da funcionalidade e tal, na facilidade de integração dos desenvolvedores. Com as discussões que vimos sobre metacaixas e outros enfeites, os autores de plug-ins "Gutenberg-ify" seu trabalho em vez de apenas abandonar se / quando o editor clássico for embora.

É bom mencionar mais alguns pontos sobre o Vue.js : (apenas pensamentos pessoais, outras bibliotecas, FWs e opções são apreciados e com certeza têm seus próprios recursos e prós)

• PRO Não requer necessariamente um transpiler ou force como ser usado e pode ser executado diretamente na web como o jquery pode

Isso ajudaria surpreendentemente os desenvolvedores de plug-ins na integração com a IU do Wordpress. Eles podem anexar uma nova instância de vue a qualquer parte da página como um widget. Além disso, um grande projeto Wordpress pode ser adotado progressivamente com Vue.js sem a necessidade de grandes mudanças na base de código, já que o vue não assume como será usado. Eu acho que esta é a chave do sucesso porque o Laravel / Vue é tão popular e funciona bem juntos :)

• PRO JSX e css-in-js também são suportados!

Isso pode ajudar a migração de projetos WordPress atuais com código React / JSX mais rápido para vue.js com menos requisitos de mudança. (existe até um plugin babel: babel-plugin-transform-react-to-vue )

• O FACT Vue, assim como o Preact e ao contrário do Angular / React, não é um projeto de código aberto de propriedade de uma grande empresa como o Google ou o Facebook.

Isso seria algo crítico para um projeto ENORME como o Wordpress para escapar de um bloqueio de fornecedor potencial. Se um projeto de código aberto não pertencente a uma empresa, alguém deve iniciá-lo (portanto, "Dependência de pessoa-chave" não faz sentido ser mencionado como CON ).

Eu voto no VueJS.
Não porque eu saiba algo sobre isso, mas porque não tenho ideia de como é pronunciado na língua inglesa. No entanto, usei o Joomla por anos e achei errado o tempo todo.

Piada à parte.
Poucos aqui discutem qual estrutura é melhor no suporte a metaboxes antigas e campos personalizados. React foi muito ruim nisso, como sabemos agora.

Agora, apenas para cancelar a inscrição neste problema.

Para enfocar a discussão, criei um problema de tarefa aqui: https://github.com/WordPress/gutenberg/issues/2741

Eu sugiro Vue, apenas porque Laravel. Muitas pessoas do WordPress insatisfeitas com o curso que ele tomou ou ainda toma, passaram a usar o Laravel como seu framework CMS principal, mantendo o WP como a segunda escolha. Preact é apenas um clone e uma camada massiva de compatibilidade, mais ou menos o que o Novell DOS era para o MS DOS, PC DOS e vice-versa.

cu, w0lf.

Vue.js até o fim!

Você certamente deve dar uma olhada no Hyperapp .
Prós

1. É muito semelhante à arquitetura Elm (Model, View, Update).
2. Possui Redux embutidos como Redutores chamados "ações" (chamados para atualizar o modelo e, por sua vez, Visualizar).
3. Usa JSX
4. Encoraja projetos de "programação funcional"
5. Tem 1kb, portanto é fácil de carregar e de entender.

Contras

1. Ainda é novo, assim como o ecossistema. Mas você pode influenciá-lo e contribuir para isso.
2. Pode haver problemas que ainda não foram descobertos.

Os princípios dos blocos de Gutenberg combinam perfeitamente com os dos componentes da

Veja também: Polímero - Componentes da Web com algum açúcar.

Vue é uma opção fantástica, e aqui estão as razões pelas quais acredito que sim:

Comecei a assistir Vue no início de 2016. Eu adorei e queria determinar se algum dia estaria "em demanda" ou se seu crescimento era algo para escrever para casa. Na época, ele tinha 16.000 estrelas no Github. Foi legal e tudo, mas as pessoas realmente não se adaptaram a ele no meio de toda a porcaria Angular vs React.

Acabei perdendo _todos_ os meus dados e recomecei em 17 de setembro de 2016. Exatamente um ano atrás, hoje. ( Aqui está meu conjunto de dados atual. )

Durante o ano passado, observei a popularidade de Vue crescer (em termos de menções na internet e rastreamento de estrelas do Github) a uma taxa de _divulgação de registros_. Vue acumulou 40.000 estrelas em 365 dias. Isso é uma média de 109 por dia. Em comparação, o amado _Reato_ do mundo cresceu de 49.000 para 75.000 neste mesmo período. (71 por dia) O Vue ultrapassará o React nos próximos meses, em termos de avaliações de usuários.

Enquanto todos estavam falando sobre o crescimento de React ser o mais incrível de todos os tempos, eles não sabiam que Vue era o verdadeiro titular. Eles não sabiam que o Vue estava crescendo porque as pessoas realmente o amavam como uma ferramenta, e não por causa de qualquer apoio famoso (Facebook).

Vue está na lista de repositórios de tendências do Github todos os dias há mais de um ano. 99% dos dias está acima de Reagir. 10% dos dias, React não faz o corte.

Tudo isso grita "use Vue porque teve mais crescimento de popularidade!" Mas o que quero transmitir é que o Vue cresceu porque as pessoas genuinamente o amam porque é uma ferramenta excelente, intuitiva e poderosa (muitas vezes incorretamente apresentada como "ótima para aplicativos pequenos") para aplicativos de todos os tamanhos. Mas não apenas uma ferramenta. Vue é um ecossistema. Ele vem com uma enorme comunidade de apoio também.

Posso acrescentar ... os .vue arquivos são geniais. Muitas ferramentas estão sendo construídas para lidar com estilos no React porque aparentemente há algo errado com os módulos CSS e ter seus estilos em um arquivo externo. (Idk ...) Mas Vue não tem esse problema. O Vue tem instruções de controle incorporadas à sintaxe e (já que vi comentários sobre elementos personalizados acima) não apenas funciona bem com elementos personalizados ... É uma biblioteca / estrutura para elementos personalizados lógicos.

Preact é ótimo. Honestamente, eu comecei outro projeto com ele hoje. Mas quando eu olho para Preact, vejo um React fora da marca. Não foi construído para ser inovador ou para progredir na maneira como criamos software baseado na web. Ele foi criado para se parecer e funcionar como uma ferramenta pré-existente, mas para oferecer melhor desempenho.

Estes são meus dois centavos. Agora estou falido.

Espero que sua decisão final o deixe feliz e forneça uma ótima base para o futuro de seus produtos.

@ahmadawais :

• O tempo de lançamento no mercado é importante para projetos corporativos e de código aberto. Você pode encontrar exemplos de projetos que nunca foram enviados porque acabaram demorando muito e se tornando obsoletos antes de serem enviados. Alguns projetos acabaram sendo abandonados durante o trabalho em direção a um grande lançamento.
• Ser contrário ao Preact significa "cometemos um erro com o React por razões além do licenciamento". Acho que com "A curva de aprendizado já é enorme para desenvolvedores intermediários / novos", você quis dizer que os desenvolvedores do wordpress já se perderam com o React. Isso não me surpreende. Mas parece difícil acreditar que Vue, mesmo que menos prolixo, resolverá os problemas da curva de aprendizado. O antigo mecanismo WP do PHP e qualquer estrutura javascript de aplicativo de página única são muito diferentes. Vue e React são muito semelhantes entre si.
  Não sei por que você vê competição entre o Wordpress e o Laravel. Posso ser ingênuo aqui. Eu sei muito pouco sobre a história do Drupal 8.
  Do meu ponto de vista, o Wordpress é um CMS e atrai desenvolvedores devido à sua grande base de usuários não técnicos e aos recursos já integrados nele. Existem muitos modelos e os desenvolvedores podem construir rapidamente um novo site personalizável por um não desenvolvedor.
  Laravel é um framework PHP que, até onde eu sei, não oferece muitas das características de um CMS. Um desenvolvedor vai escolher porque precisa de mais liberdade.
• Não tenho certeza de como ter alguns sucessos com Vue + Laravel também significa "Vue é bom para Wordpress". Acho que há muito pouca sinergia intrínseca entre PHP e qualquer estrutura JS. Concordo plenamente que é importante encontrar uma estrutura que seja boa para a comunidade. Se a maior parte da comunidade atual de desenvolvedores da qual o wordpress depende está familiarizada com o Vue e eles o amam, isso tem um grande peso na sua decisão final.

Do ponto de vista da engenharia, acho que tanto o Marko JS quanto o Vue são frameworks mais novos. Eles aprenderam muito com o React e foram capazes de remover parte da verbosidade dele. Nesse sentido, Marko parece remover ainda mais código clichê do que Vue. Em particular, o Marko mantém um código coeso que é bom para manter no mesmo lugar e deixar em HTML para que serve o HTML e em Javascript para que serve o Javascript. E também é 10x mais rápido. Portanto, além do fato de que ultimamente o Vue tem muitos fãs, não vejo muitas razões para preferir o Vue ao Marko.

Desculpe, mas a sintaxe e a configuração de Marko são horríveis em comparação com o VueJS. Em termos de desempenho, não vi nenhuma fonte em que o MarkoJS seja mais rápido de forma significativa sem adicionar tempo para entender como funciona.

A sintaxe o lançamento que introduziu a sintaxe atual de Marko foi extremamente bem recebido pelos nossos usuários.

Pensamos muito na sintaxe do Marko para nos certificarmos de que ela seja familiar aos desenvolvedores que entendem de HTML e JS e queríamos que fosse o mais simples e poderoso possível com o mínimo de clichê. Acho que você vai descobrir que, com qualquer comparação lado a lado, o modelo Marko exigirá menos código (o que é ótimo para legibilidade e manutenção).

Aqui está um documento que eu montei rapidamente para que você possa ter uma visão geral das diferenças entre a sintaxe Marko e a sintaxe Vue:

Sintaxe: Marko vs Vue

Eu vinculei a ele anteriormente, mas para uma comparação mais aprofundada entre Marko e Vue (e React), consulte:

Meetup: Construindo a IU - uma comparação de React, Vue e Marko (do criador do Marko) - Vídeo | Slides

Quanto ao desempenho, temos alguns benchmarks que você pode conferir: https://github.com/marko-js/isomorphic-ui-benchmarks

Aqui está uma rápida execução dos benchmarks com Marko e Vue habilitados:

Desempenho de renderização do lado do 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

Desempenho do lado do cliente

_Chrome Versão 63.0.3218.0 (versão oficial) canário (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

Esses são os benchmarks que criamos para o Marko.js, então, obviamente, levamos esses resultados com cautela, mas fizemos todos os esforços para sermos justos.

Além disso, gostaria apenas de adicionar mais alguns comentários sobre Marko.js e facilidade de uso:

Marko sempre teve como objetivo ter a integração mais simples com Node.js. Depois de instalar o pacote marko via npm, aqui está todo o código necessário para renderizar um modelo para um fluxo de resposta 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);

Eu acho que é o mais simples que você vai conseguir.

Marko também trabalha com empacotadores de módulos JavaScript populares: http://markojs.com/docs/bundler-integrations-overview/

Para renderizar um componente de interface do usuário Marko de nível superior para o DOM aqui é tudo o que é necessário:

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 De acordo com http://www.stefankrause.net/wp/?p=431 benchmarks, markoJs
é tão performante quanto Vue et al.

Portanto, podemos concluir que em scripts do lado do cliente em geral, Markojs e Vue têm desempenho igual.

Claro, o benchmark, vinculei, não inclui ssr. Portanto, não vou comentar sobre isso.

Eu voto no Vue. jQuery já é quase um requisito para usar o WordPress. Pessoas familiarizadas com jQuery devem se sentir familiarizadas com a sintaxe Vue. Sua ideologia sobre o DOM não é tão extrema quanto algo como o Angular. Ele se baseia no princípio do WordPress para facilitar o usuário.

Como sugeri há cerca de dois anos para o Calypso , Mithril.js usando a API HyperScript seria uma boa escolha para substituir o React. Ele tem uma licença padrão do MIT.

Um pequeno investimento em novas ferramentas para fazer pelo menos parte do trabalho pesado automaticamente para a conversão do React para outra biblioteca vdom pode valer a pena em horas de desenvolvedor economizadas - como mencionado nessa edição como uma sugestão para a Automattic fazer com antecedência para se proteger sua aposta em React.

Mesmo sem considerar bibliotecas não vdom, há mais de 25 bibliotecas vdom (por exemplo, inferno.js, maquette, etc.) que poderiam ser consideradas - como nesta lista que fiz em janeiro de 2016 para um projeto diferente considerando opções vdom.

Aqui estão alguns motivos técnicos pelos quais Mithril.js ou outros vdoms enfatizando (ou pelo menos apoiando) a API HyperScript são as melhores escolhas.

Pessoalmente, acho que as abordagens de templates para fazer UIs baseadas em JavaScript, como o JSX do React, ou a abordagem de template do próprio Angular, ou os sistemas de templates em muitos outros sistemas de UI, incluindo o Vue, estão obsoletos. Por quê? Preferências e "melhores práticas" para escrever aplicativos da web baseados em modelos HTML gerados no lado do servidor usando folhas de estilo CSS complexas (como para plug-ins anteriores do WordPress) estão se tornando "piores práticas" para escrever aplicativos da web de página única. As necessidades técnicas para escrever aplicativos complexos e modernos do lado do cliente de página única são diferentes do código baseado principalmente no servidor, devido à crescente complexidade do código do lado do cliente. Resumindo, as velhas "melhores práticas" de usar modelos e folhas de estilo em cascata complexas simplesmente não são escalonadas, o que torna o código difícil de manter.

Qual é a alternativa emergente? Os aplicativos da Web modernos podem usar Mithril + Tachyons + JavaScript / TypeScript para escrever componentes em arquivos únicos onde todo o código é apenas JavaScript / TypeScript. Esses aplicativos não precisam ser parcialmente escritos em CSS ou alguma variante não padrão de HTML que reimplementa parte de uma linguagem de programação (mal). (Bem, pode ser necessário um pouco de CSS personalizado além dos Tachyons ou bibliotecas semelhantes, mas muito pouco.)

Aqui está um exemplo de um playground de codificação que escrevi dessa forma, com vários exemplos que usam essa abordagem.

Portanto, ao escrever UIs usando HyperScript (mais uma biblioteca vdom), você pode potencialmente (com algum trabalho) substituir um back-end como Mithril por quase qualquer outro vdom ou mesmo uma solução não-vdom. Portanto, quando tenho escolha, escolher usar a API HyperScript é uma maneira de reduzir o risco de bibliotecas subjacentes com bugs ou problemas de licenciamento.

Ao usar Tachyons ou bibliotecas semelhantes, eu reduzo o risco de arquivos CSS que não podem ser mantidos à medida que o aplicativo cresce.

Concedido, eu sei que muitos desenvolvedores da web cresceram ajustando HTML e amam modelos que parecem HTML. Então, eles amam JSX ou qualquer outra coisa e ficam felizes em ignorar o quão difícil é refatorar esse material não-código no meio de seus aplicativos ou validá-lo. É verdade que alguns IDEs estão ficando melhores na refatoração de modelos JSX. Mas eu vim para o desenvolvimento web de desktop e desenvolvimento embarcado trabalhando com sistemas em que você (normalmente) gerava UIs diretamente do código (por exemplo, usando Swing, Tk, wxWidgets e assim por diante). Gosto da ideia de que ferramentas padrão podem me ajudar a refatorar todo o código em que trabalho e detectar muitas inconsistências.

Supondo que todos os frameworks em execução aqui não tenham diferenças visíveis para o usuário por causa de sua velocidade no navegador de sua escolha, podemos parar de usar o desempenho do frontend como uma métrica para avaliar qual framework é a melhor escolha.

Mas se usarmos a renderização do lado do servidor, devemos examinar cuidadosamente o desempenho do SSR. Calypso parece que pretende ter SSR. E, se for bem-sucedido, um dia o Calypso executará a maioria dos sites do wordpress.com.

Uma empresa paga pela CPU dos servidores, não pela CPU dos navegadores. Portanto, de uma perspectiva de custo, o tempo de renderização 10x mais rápido do Marko provavelmente significa que o mesmo tráfego que no máximo 10 servidores com o MarkoJS levará pelo menos 100 servidores executando o Vue.

Se o Wordpress puder ignorar isso, terei prazer em trabalhar para a empresa e receber 10x o salário de mercado e usar o Vue que, a propósito, acho que é uma boa alternativa React =)

Quanto mais leve for a estrutura - isto é, quanto menos funcionalidade ela oferecer fora da caixa - mais rápido terá um desempenho. É pateticamente óbvio. Uma coisa é comparar o desempenho de vários algoritmos, mas quando o maior fator é quantas outras “coisas” são realizadas, você não precisa escrever testes.

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

@ahmadawais Equipe principal do Angular aqui - estamos em andamento em muitos trabalhos interessantes relacionados ao desenvolvimento do estilo CMS / Widget, incluindo o investimento em suporte a Elementos Personalizados (que, para mim, é a aposta de futuro inteligente para a construção de plataformas)

Em vez de bagunçar ainda mais o tópico, ficaremos felizes em conversar com vocês off-line, se vocês tiverem algum interesse. Escreva-me em robwormald at google dot com. Boa sorte nisso, eu não invejo você ter que fazer esta ligação ;-)

Eu fiz uma enquete simples aqui que pode ser usada para obter uma visão sobre o que as pessoas querem

atualmente trabalhando na página de resultados e autenticação nele. (novo no firebase)

PS. levou cerca de 1 hora para fazer isso usando o Vue 🖖

@vinayakkulkarni Que tal adicionar Mithril.js à sua enquete?

@pdfernhout : 👍

Feito. Eu adicionei MithrilJS à lista.

• [x] VueJS
• [x] Angular
• [x] Pré-ação
• [x] brasa
• [x] Marko
• [x] Inferno
• [x] Aurelia
• [x] Mitrhil

Vamos ver o que as pessoas decidem.
PS. houve uma enquete no Twitter de @ahmadawais também.

Oi. Sou um mantenedor central do Drupal. Como @ivanjaros mencionou em um comentário anterior, também estamos avaliando Preact, Vue ou qualquer outra coisa, para alguns bits futuros da IU administrativa do Drupal. Podemos decidir por algo diferente do que você escolhe, mas o que você escolher certamente será pelo menos um fator a ser considerado em nossa escolha.

Eu abri essas duas edições do Drupal até agora, e mais virão. Basta cruzá-los aqui, caso esses problemas / discussões sejam úteis para você.

• componentes que retornam vários nós raiz
• slots vs. adereços de vnode

Observe que ainda gosto muito do Vue, apesar desses dois problemas. Essas podem ser coisas com as quais estamos ok em conviver, a fim de obter todos os outros benefícios do Vue.

Como autor de Vue, evitarei fazer comentários sobre qual estrutura escolher aqui, pois sou obviamente tendencioso; mas como eu vi a afirmação de que "Marko é 10x mais rápido que Vue" repetida algumas vezes, acho que merece alguns esclarecimentos. Eu também não quero atrapalhar a discussão em um debate técnico, então eu anotei algumas idéias nesta essência para aqueles que estão interessados.

@ michaelbdavidson7 em relação às questões financeiras: Trabalho em tempo integral no Vue há mais de 1,5 anos e o suporte do Patreon tem sido realmente estável. Em vez de especular sobre as flutuações das promessas do Patreon, você pode verificar a atividade de commit de Vue para julgar por si mesmo. Além disso: ter um canal aberto de contribuição financeira significa que a WP / Automattic pode facilmente garantir a sustentabilidade da Vue ao se tornar um grande patrocinador (o próprio Matt já é um patrocinador pessoal!) - que na verdade se alinha com os interesses de ambos os projetos.

Eu voto Vuejs

@ tungbt94 Por quê?

Definitivamente VueJS

A grande questão, por que a reação foi escolhida antes desta questão da patente. Se não fosse patente, você ainda usaria o react? Muitos pontos feitos sobre NÃO escolher o pré-ato são o mesmo que não escolher o reagir.

Meu voto é com Preact

Como não tenho muita experiência com nada além do React, não vou pesar na estrutura a escolher.
No entanto, acho que o argumento da "grande comunidade" pode ter menos importância. Por quê? porque quando o Automattic decidir sobre uma estrutura, esse trabalho agrícola terá milhares de novos usuários. E se eu souber que a comunidade WP está correta, muitos deles começarão a contribuir para essa estrutura também e a popularidade aumentará.

Considerando onde Gutenberg e Calypso estão no momento, ainda acho que Preact é a melhor escolha de engenharia.

No entanto, se você ainda se sente forte para queimar pontes com qualquer semelhança com React ou se teve que começar do zero, ainda acredito que MarkoJs é a melhor escolha. Acho que o apoio da comunidade ainda pode ser uma preocupação.

Assumindo que as estrelas do Github estão de alguma forma correlacionadas com a comunidade, Vue ainda é 10x em comparação com MarkoJs, mas olhando para os gráficos, isso mudará rapidamente.

Vue está crescendo linearmente:

Mas MarkoJs parece estar no ponto de inflexão de um crescimento exponencial:

@ patrick-steele-idem, o autor principal de MarkoJs , sempre foi super responsivo em https://gitter.im/marko-js/marko

Quando as pessoas acabam escolhendo MarkoJs , mas realmente qualquer tipo de comunidade, sinto vontade de parafrasear a frase de JFK: "Não pergunte o que a comunidade pode fazer por você - pergunte o que você pode fazer pela comunidade."

Pessoalmente, gostaria de parabenizar @ahmadawais por criar um único problema que criou um envolvimento significativo de muitos JS Devs que usam e oferecem suporte às opções relevantes da Biblioteca JS.

Suspeito que este problema ajudou a informar mais JS Devs sobre os movimentos do WordPress em direção a mais desenvolvimento baseado em JavaScript via Gutenberg do que qualquer outra comunicação do Gutenberg até agora.

Eu uso o AngularJS, mas o que não gosto é a atualização principal de cada vez, então vou com o VueJS.

1 para Marko. Ótima biblioteca que nossa equipe usa e com a qual está muito feliz. Renderização assíncrona, super rápida (renderiza para string no servidor e para vdom no navegador), componentes de arquivos únicos ou múltiplos e IMO a melhor sintaxe de templates que existe.

Por favor, leve o hiperHTML de @WebReflection em consideração.

Eu gosto de angular

Eu voto angular

Eu escolho angular

apenas angular

Eu escolho angular

angular

Eu voto angular

Eu voto angular

Se você gosta de votar em uma estrutura, seria bom saber o motivo exato e como isso ajuda Gutenberg.

Para os peeps que vêm aqui apenas para dizer "Eu voto em X", por favor, nos dê algumas razões pelas quais devemos votar em X também. "Eu voto em X" não nos diz nada além de que você gosta de X.

Eu escolho angular. Angular teve grandes mudanças desde a versão 2. Agora, é um framework completamente bom, forte e amplamente usado. Como ele, como o iônico, não estude rapidamente, mas fortemente.

Com tantos spams “Eu votoframework ”, o github está reclamando para mim.

Peço aos desenvolvedores que votem gentilmente na sua escolha de estrutura em https://vinayakkulkarni.github.io/poll/ https://vinayakkulkarni.github.io/poll/ em vez de apenas postar 'Eu voto…';

Além disso, outra sugestão é bloquear esta conversa; a maioria dos principais desenvolvedores já deu sua opinião sobre isso.

Em 18 de setembro de 2017, às 20:01, Mingyue [email protected] escreveu:

Eu escolho angular. Angular teve grandes mudanças desde a versão 2. Agora, é um framework completamente bom, forte e amplamente usado. Como ele, como o iônico, não estude rapidamente, mas fortemente.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub https://github.com/WordPress/gutenberg/issues/2733#issuecomment-330241898 ou ignore o tópico https://github.com/notifications/unsubscribe-auth/AS3FbT23DvVwTLGL61tmK7KtuwZeg- ucks5sjn7SgaJpZM4PYie9 .

obrigado @kidwm por mencionar _hyperHTML_, mas acho que é melhor seguir a orientação deles:

Não apenas compartilhe qual framework JS você gosta, mas também porque

então deixe-me tentar fazer isso ...

: zap: hyperHTML :

• PRO : iniciante amigável e familiar para usuários P ​​/ React (em vez de JSX você escreve Literais de modelo)
• PRO : super rápido e sem VDOM; menos consumo de memória (mercados emergentes compatíveis com telefones)
• PRO : não requer ferramentas (requer literais de modelo transpilados apenas para IE <11)
• PRO : totalmente baseado em padrões JS / DOM / HTML, mas também compatível com TypeScript
• PRO : cabe em menos de 5K (min-zipado) sem a necessidade de polyfills extras ou patches do navegador
• PRO : 100% de cobertura de código até as peculiaridades do IE9
• PRO : compartilha a mesma API com sua contraparte NodeJS ; 100% compatível com renderização do lado do servidor
• PRO : pode adotar DOM existente sem destruir os layouts / nós de SSR
• PRO : funciona com elementos personalizados melhor do que P / React, também pode ser usado para definir elementos personalizados
• PRO : ele pode fazer o que React , Vue.js , Polymer , Angular ou Marko fazem, e ganha em termos de tamanho / largura de banda / desempenho de cada um deles

Agora, de acordo com as métricas utilizadas até agora neste tópico, o CONS

• CONTRAS : mesmo que tenha sido testado em batalha, totalmente coberto por teste e com uma API congelada, é um projeto relativamente novo (março de 2017), então não pode competir em termos de popularidade, adoção ou quantidade de colaboradores
• CONTRAS : a comunidade está ajudando muito e o projeto está crescendo, mas o maior contribuidor técnico até agora sou eu. No entanto, estou 100% comprometido com este projeto e disposto a empurrá-lo o máximo que puder, além de estar discutindo com poucos "_bigs_" sobre o uso de _hyperHTML_ em alguns dos próximos grandes projetos deles (não vou especular mais embora sinta-se à vontade para ignorar esta última parte)

: dart: Eu realmente acredito que o futuro da Web é usar a plataforma o máximo possível, o que é definitivamente muito melhor do que há 10 anos, e graças às modernas especificações ECMAScript é muito mais fácil de escrever, ler e manter. _hyperHTML_ representa o "_estado atual da arte da Web_" em termos de potenciais, enquanto todos os outros contendores nesta lista nasceram na era pré-ES6.

Eu entendo o tamanho da comunidade, contribuidores e estrelas do GitHub são importantes, mas acho que testes, cobertura de código cruzado de navegadores e quantidade de bugs também devem ser considerados, e estou fazendo o meu melhor para manter a contagem de _hyperHTML_ e amigos próximos zero (na verdade é zero agora, além de uma discussão que não é um bug).

Por último, mas não menos importante, se ninguém der uma chance às novas soluções e julgar apenas pelas estrelas e pelo exagero, as novas soluções levarão mais tempo do que o necessário para se tornarem mais populares.

Claro, já falei sobre minha solução mais recente, minhas considerações podem ser consideradas subjetivas, mas especialmente minha última frase sobre dar uma chance a novas soluções, foi muito geral, não apenas sobre minhas bibliotecas: smiley:

Cumprimentos

Eu gosto de angular

deve ser angular e google.

eu amo angular

Angular é apenas uma estrutura real!

Eu escolho Angular, não AngularJs.

Apenas angular é uma estrutura real!

Estou começando a suspeitar, esses comentários são feitos por bots.

@OP : Por favor, bloqueie este tópico.

Eu voto no Angular (NÃO no AngularJS).

Angular é um platorm, a equipe do google faz um trabalho muito bom para facilitar o andamento do desenvolvimento, incluindo o componente, o módulo, o roteador, com a injeção de dependência, você pode economizar muito trabalho para organizar toda a dependência, com o angular-cli, você pode economizar muito trabalho para iniciar um novo projeto, basta abrir a caixa e seu aplicativo está bem compilado com aot, tree shake e muitas outras otimizações.

O TypeScript é outra ótima ferramenta com angular, ele é fornecido pela MicroSoft, ou seja, toda a plataforma angular é construída com ts. Você constrói seu aplicativo com ts também! É uma ótima ferramenta para tornar a vida mais fácil quando a quantidade de código está ficando cada vez maior, você pode fazer refatoração no IDE (como vscode) com apenas um clique. A verificação estática de tipo faz com que você encontre os bugs o mais cedo possível. TS também fornece uma boa implementação de OOP, você pode organizar e reutilizar seu código de uma maneira muito melhor.

Há também muitos componentes construídos com base em angular, como meterial design2, primeng, e quero recomendar o Jigsaw , que é criado por nossa equipe. É adotado pelo Produto de Big Data da ZTE China. Ele está suportando todos os aplicativos da ZTE agora.

Anglar é uma ótima escolha !!

Para todos os bots: 🖕

Provavelmente alguém postou em uma comunidade AngularJs. Acho que as pessoas podem silenciar o tópico se não quiserem receber mais mensagens.

Eu acho que eventualmente uma conversa semelhante sobre este assunto terá que acontecer em um lugar onde existam apenas colaboradores do WordPress.

Eu gostaria de compartilhar algumas de minhas idéias sobre este assunto que já expressei principalmente no grupo da comunidade EmberJS slack, se você tiver 10 minutos para ler a discussão lá, eu recomendaria: https://embercommunity.slackarchive.io / wb-marketing / page-2 / ts-1505456102000189 Há muitos deles, mas eu recomendo dar uma olhada para obter uma compreensão diferenciada da discussão.

Meus principais pontos nessa discussão são os seguintes:

• Ao comparar um pico de 2-4 semanas de implementação de algo na estrutura Ember vs qualquer outra biblioteca, as outras bibliotecas tendem a ganhar no curto prazo, mas a Ember vence em qualquer projeto de longo prazo
• Ao considerar qual biblioteca ou estrutura acompanhar, é importante considerar não apenas a implementação técnica, mas também os aspectos de "habilidades sociais" (tamanho da comunidade, compromisso de apoiar o LTS, envolvimento da comunidade nas decisões centrais do projeto)
• Ember tem um histórico de fornecer grandes melhorias para aplicativos construídos usando o ember-cli "sob o capô", ou seja, sem a necessidade de atualizar qualquer código do aplicativo. Também houve casos de pequenas atualizações no código do aplicativo (com code-mod incluído usando coisas como ember-watson ) para obter um aumento significativo de desempenho e produtividade.

Não quero entrar em muitos detalhes neste comentário porque eu poderia escrever um ensaio de 10.000 palavras sobre os pontos acima. Gostaria, no entanto, de oferecer meu tempo a qualquer pessoa que queira discutir esse assunto com alguém que tenha uma "mentalidade Ember".

Se algum dos tomadores de decisão quiser ter uma ligação de uma hora comigo para fazer perguntas mais diretas sobre o ecossistema mais amplo do Ember, eu o faria com prazer. Você pode entrar em contato comigo no Twitter (DMs abertos). Posso não ser um membro da equipe principal, mas venho construindo aplicativos Ember desde antes de 1.0 e passei por todos os processos de atualização com vários aplicativos 👍

Eu trabalho para "Meu eBay" no eBay. Acabamos de lançar nosso primeiro aplicativo de página única . Aproveitamos cada fase de desenvolvimento usando o MarkoJS. Como eu, se você ama o paradigma de programação de streaming do node, então o MarkoJS suporta streaming e renderização assíncrona. Outros fatos que gostei sobre MarkoJS:

• sua vinculação eficiente de comportamento de componentes de IU renderizados no servidor e no navegador.

• Delegação de eventos muito eficiente

• Serialização rápida de estado do servidor para o navegador

@vinayakkulkarni Acho sua ideia boa, mas o problema é que posso deixar mais de 1 voto mudando de navegador (não tentei com o mesmo navegador).

Você provavelmente deve usar uma enquete do Twitter (mas já existe uma) ou implementar um sistema de login para tornar os votos exclusivos.

A renderização do servidor não é relevante para a conversa aqui. O Node não se tornará parte da pilha necessária do WordPress, então a rapidez com que essas estruturas são renderizadas no Node não é relevante para uma decisão.

Vue.js! olhe para este projeto https://github.com/bstavroulakis/vue-wordpress-pwa

Eu escolhi Angular (não AngularJS), ele tem a maior comunidade, um ecossistema estável e completo.

Angular é muito lento e com a v4 é baseado em texto datilografado, é inútil para o desenvolvimento do wordpress.

Eu escolho o Angular pela maturidade da plataforma

Eu votaria no Vue porque é mais fácil de aprender e porque meu framework favorito Ember Js é muito grande para o trabalho e Glimmer Js ainda é muito novo. :-)

A renderização do servidor não é relevante para a conversa aqui.

no meu caso, acabei de mencionar um recurso que outros consideraram relevante

O Node não vai se tornar parte da pilha necessária do WordPress

_hyperHTML_ pode pegar qualquer conteúdo renderizado do lado do servidor, incluindo PHP. Sou um engenheiro certificado pela Zend e já trabalhei com jornalistas / editores usando WordPress, minha dica não foi apenas do nada.

portanto, a rapidez com que essas estruturas são renderizadas no Node não é relevante para uma decisão.

o fato de uma estrutura funcionar no back-end também, pode pegar conteúdo renderizado do lado do servidor e seria até compatível com NativeScript talvez seja uma vantagem que é irrelevante hoje, mas um futuro compatível com um bom recurso, como um projeto de mente aberta pode considerar.

@webreflection Eu não quis dizer que esse comentário

Visão

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

Essa postagem não será publicada e, em vez disso, estou aqui para dizer que a equipe de Gutenberg vai dar um passo para trás e reescrever Gutenberg usando uma biblioteca diferente. Isso provavelmente atrasará Gutenberg pelo menos algumas semanas e pode levar o lançamento para o próximo ano.

E mais importante:

A Automattic também usará tudo o que escolhermos para Gutenberg reescrever o Calypso

Calypso já está usando renderização do lado do servidor. Veja: https://github.com/Automattic/wp-calypso/blob/master/server/render/index.js#L58

Então, meu entendimento é que os desempenhos de SSR são relevantes.

Eu amo angular também！
Estrutura real do AngularJS js！

Eu voto para angular

@chriscinelli Isso é

Obviamente, o Angular é a melhor escolha

Eu voto para angular

Eu voto para angular

Eu voto no Vue.js.
Isso economiza na maior parte do tempo, especialmente ao lidar com a camada de visualizações.

Devo votar no Vue !!!

Lance uma onda angular

@trotyl Esse comentário é inaceitável. Eu editei seu comentário para removê-lo.

oh, por favor, não AngularJS
agora é Angular.

@mAAdhaTTah da wikipedia:

WordPress foi lançado em 27 de maio de 2003, por seus fundadores, Matt Mullenweg e Mike Little como um fork do b2 / cafelog

Embora amplamente desenvolvido pela comunidade ao seu redor, o WordPress está intimamente associado à Automattic , a empresa fundada por Matt Mullenweg.

Este é o Calypso: https://developer.wordpress.com/calypso/ e o Calypso usa SSR.

Como eu escrevi em meu comentário anterior , é bastante claro na postagem do blog que retirou o suporte do ReactJS de Matt que eles querem manter Gutenberg e Calypso alinhados na mesma tecnologia. A Automattic fornecerá páginas Calypso de seus servidores com SSR.

Acho que isso é o suficiente para tornar o desempenho do SSR relevante nesta decisão.

Porém, em um futuro distante, uma vez que os desenvolvedores do Wordpress se acostumarem com o Preact (ou Vue ou Marko ou outro framework), um novo projeto maluco pode surgir e eles decidem servir ainda mais partes do Wordpress através do nó. Isso tornará o SSR ainda mais importante. Portanto, o desempenho do SSR pode ser ainda mais importante.

Como a conversa passou a discutir SSR, acho que é prudente mencionar que esta é uma prioridade muito alta para Ember e foi pensada extensivamente com o advento do Ember-Fastboot

Embora eu use o Fastboot (com ótimo efeito) com alguns aplicativos clientes, pois esta é uma discussão de tecnologia de alto nível, eu recomendaria entrar em @tomdale, pois ele foi o campeão do esforço do Fastboot 👍

@chriscinelli WordPress o projeto da comunidade e Automattic a empresa ainda são entidades separadas. Se a Automattic quiser argumentar a favor de um ou outro por causa do SSR, eles podem, mas isso ainda não muda como nós, a comunidade WordPress, devemos considerar a estrutura de escolha para o núcleo do WordPress, que não pode, e realmente não pode, requer nó para ser executado.

De qualquer forma, cancelei a inscrição neste tópico. Se você quiser continuar esta discussão offline, meu e-mail está em meu perfil.

não requer, e realmente não pode, exigir que o nó seja executado.

por favor, não vamos fazer da capacidade SSR um ponto discriminatório. Frameworks capazes de SSR de nó podem viver sem nenhum SSR de nó: é apenas um recurso extra, não um requisito, nem uma dependência.

Eu votaria no Vue.js

Sou um arco sênior que estudou no MIT e é considerado razoavelmente inteligente. Tenho feito isso há muitos anos e entrevistei alguns desenvolvedores aqui e ali. Eu sei que a web está cheia de pessoas inteligentes, mas qualquer um que pense que a simplicidade do Vue está a par da complexidade do Angular perdeu a perspectiva sobre o que constitui "complexo". Javascript baseado em componentes, como o Google o concebeu, é completamente não trivial. É ridiculamente complexo. Vue não é. Vue é tão fácil quanto PHP. Digo o óbvio, porque "Vue é mais fácil de aprender" nem chega perto de descrever como o Vue é muito mais fácil do que o Angular. E aqui está o problema - acho que também é muito mais fácil do que Reagir.

O React caminhava na linha entre o nível fácil e o nível do Google, para pessoas comuns. Para pequenas lojas, eu diria que o React é complexo o suficiente para desafiar equipes pequenas. React é mais complexo do que, por exemplo, PHP / Wordpress. Ao escolher React, o Wordpress / Automattic aumentou os requisitos para a entrada do desenvolvedor no mundo de desenvolvimento do Wordpress. Tenho certeza que centenas de pessoas gritarão: "Reagir é fácil" e "A web está ficando mais inteligente", mas mais complexo é ainda mais complexo, no final do dia.

Eu humildemente acho que voltar para a Vue seria mais perto das raízes do WP, e menos um fardo técnico para a comunidade do WP como um todo. Paradigmas da Web à parte - às vezes, simples é bom.

Angular e Vue são 2 coisas diferentes

Vue, React, MarkoJS, Inferno, Preact etc são bibliotecas que cobrem apenas a camada de visualização. Todos eles, incluindo o Angular, têm uma maneira de criar o HTML e alterar o DOM de forma declarativa. O Angular deseja fornecer uma estrutura completa para o desenvolvimento de front-end e tem muito mais coisas além da camada de visualização.

A sintaxe do React é a mais antiga neste exemplo. O Facebook fez um ótimo trabalho ao vincular uma biblioteca muito complexa que faz muitas coisas (talvez muitas) em uma superfície de protocolo muito limitada. Você não precisa saber nada dessa complexidade dentro do React para saber como usá-lo e ser produtivo com ele. Você pode aprender o básico e começar a usar na metade do dia.

Todas as outras bibliotecas desta lista aprenderam com o React. Eles tentaram simplificar a sintaxe, melhorar o desempenho do React, reduzir o tamanho do código Javascript necessário para fazer as mesmas coisas e adicionar alguns recursos em cima dele.
O Preact fez um ótimo trabalho em manter uma interface muito semelhante ao React em apenas 3 KB.
Inferno e Marko otimizaram massivamente os desempenhos de renderização.
Marko e Vue simplificaram muito a sintaxe para reduzir o código clichê.
Marko também adicionou uma sintaxe Jade / Pug opcional para manter o código mais DRY e a capacidade de criar modelos assíncronos mantendo tudo simples e intuitivo para o usuário.

No entanto, todas essas bibliotecas além do Angular requerem que os engenheiros apresentem uma estratégia e mecanismos para buscar dados, roteamento, etc. Redux e seus middlewares são uma forma popular que Gutemberg usou para gerenciar a camada de dados.

Na migração do React, Gutenberg não precisa de "apenas mais uma coisa para mudar". Mesmo que o Angular se esforce para se manter agnóstico para o usuário, usá-lo com Redux e Javascript (vs Typescript) não é uma escolha natural, apesar de bibliotecas como https://github.com/angular-redux/ng-redux terem sido desenvolvidas e suportadas para Javascript está disponível. Além disso, olhando para os votos até agora, parece que a comunidade de Gutenberg se opõe fortemente à estrutura do Google. Portanto, provavelmente o Angular não será uma opção.

PHP e qualquer um desses frameworks Javascript são feras completamente diferentes

Você pode ter um back-end de PHP e um front-end de aplicativo de página única, mas não há sinergia e há poucas semelhanças.

Qualquer aplicativo Javascript tem pelo menos uma ordem de complexidade acima do que você pode ter ao escrever código PHP simples polvilhado com algum jQuery. Todos os aplicativos Javascript modernos têm que lidar com os dois monstros de grande complexidade: estado e fluxos assíncronos . Eles só são mitigados pela imutabilidade e async / await nestes últimos anos. O fluxo do desenvolvedor fica lento conforme o aplicativo cresce. Ao alterar algum código, você precisa recompilar, reinicie e o aplicativo terá que passar pela inicialização novamente. Uma quantidade enorme de ferramentas foi construída para implementar recargas quentes e, mesmo que impressionantes, ainda estão longe de serem perfeitas.
Não importa qual biblioteca você escolher para a camada de visualização, você terá que lidar com a complexidade extra.

No PHP, você altera o código, salva um arquivo e pode recarregar imediatamente a página sem construir ou recarregar. Tudo funciona. E o mais importante, o PHP é completamente sem estado . Cada vez que você recarrega a página, você tem uma tela em branco. Mesmo as variáveis ​​globais têm um estado limpo com cada solicitação (mas não é uma boa desculpa para usá-las = P). Não escrevo código PHP há alguns anos, mas ainda sinto falta de sua simplicidade e de sua experiência de desenvolvedor. Se você usa um framework moderno como CakePHP, Symphony ou Laravel, você não perde muito em comparação com outras linguagens e frameworks que são mais bem-vindos por engenheiros sofisticados. A exceção é a velocidade. PHP paga sua simplicidade com performances de tempo de execução. Cada vez que você recarrega uma página, todo o código precisa ser executado novamente. As performances aumentaram muito com HHVM e PHP7, mas em geral ainda estão longe do que você pode alcançar com node.js.

Conclusão

Não importa qual biblioteca você usou recentemente para o frontend. Mesmo que você ame, isso não significa que seja a melhor escolha para Gutenberg.
O fato de que _a maioria dos principais colaboradores de Gutenberg_ podem gostar de uma biblioteca específica é importante.

No final:

Um homem convencido contra sua vontade ainda é da mesma opinião

Eu acho que há uma quantidade bastante substancial de informações neste tópico sobre prós e contras de diferentes bibliotecas viáveis.

Os colaboradores de Gutenberg e Wordpress devem ser deixados sozinhos, podem se reunir em "portas fechadas", longe dos fanboys frontend.
Pode ser hora de esclarecer seus valores, objetivos e restrições que você tem e escolher a estrutura com base no que maximiza seu resultado.

E boa sorte novamente com sua decisão 😃

Eu votei em Vue. Amigável para iniciantes e robusto. Quando comecei a usar o Vue, tive aquela sensação que tive quando comecei a desenvolver com WordPress. + 💯

@ tons coloridos apenas para iniciantes não é bom o suficiente! Cada projeto tem um ciclo de vida, a maior parte do trabalho está no andamento da manutenção.

@ChrisCinelli Alguns esclarecimentos e opiniões:

O Angular deseja fornecer uma estrutura completa para o desenvolvimento de front-end e tem muito mais coisas além da camada de visualização.

O Vue tem bibliotecas oficiais para roteamento, gerenciamento de estado, teste, linting e muito mais, além de uma ferramenta cli oficial. Todos eles estão sob a organização vuejs, mantidos por membros centrais e em sincronia com o próprio Vue, mas a melhor parte é que você não precisa aprender ou usá-los (daí a filosofia 'Estrutura Progressiva'). Ao contrário do React, isso efetivamente o torna uma estrutura em sua forma oficial. Pequeno trocadilho: tudo isso sendo mais fácil de aprender, mais rápido e mais leve do que o Angular. :sorriso:

Marko também adicionou uma sintaxe Jade / Pug opcional

.vue arquivos podem usar qualquer pré-processador para o modelo, o script ou o estilo (por exemplo, pug, typescript, coffescript, sass, stylus ...). Use o que melhor se adapta ao seu projeto!

exigem que os engenheiros apresentem uma estratégia e mecanismos para buscar dados

Este é apenas um exemplo, mas a busca de dados não precisa ser sobrecarregada:

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

A partir daí, você pode criar um plugin Vue muito simples para tornar o código ainda mais conciso.

O próprio Vue não deve ser a biblioteca certa para este trabalho, já que sempre haverá bibliotecas dedicadas melhores (é também por isso que não oferecemos filtros de data por padrão, por exemplo, já que você acabaria usando o momento ou outra grande biblioteca) . Também estamos escrevendo um livro de receitas com caminhos e práticas recomendadas para vários negócios e casos de uso.

Ao alterar algum código, você precisa recompilar, reinicie e o aplicativo terá que passar pela inicialização novamente.

A única diferença real é a etapa de construção, que é fácil de configurar hoje em dia usando ferramentas como o vue-cli ou poi oficial. Quando você salva um arquivo, o aplicativo está quase instantaneamente pronto para ser atualizado (os tempos de construção também são muito bons para projetos grandes e, com base na experiência, desenvolver um grande aplicativo PHP usando uma estrutura como Symfony é mais doloroso). Além disso, o recurso Hot Module Remplacement é uma grande vantagem que não existe no mundo do PHP (que eu saiba) e permite que um novo código esteja disponível para teste no navegador em um tempo quase instantâneo, mesmo em grandes projetos (a menos que você tenha operações caras, como compilar Sass - mas você teria o mesmo problema ao usar PHP). A propósito, o Vue suporta muito bem o webpack HMR.

Você terá que lidar com a complexidade extra.

IMHO, alguns frameworks PHP muito populares parecem ser mais complexos e mais difíceis de aprender do que algumas bibliotecas / frameworks front-end como o Vue. (O oposto também é muito verdadeiro.)

Com base na minha experiência de mais de 2 anos construindo um editor baseado em blocos semelhante ao Gutenberg, acho que há várias questões iniciais a serem abordadas ao escolher a estrutura certa, por exemplo

• Como o VueJS / Marko / Angular se integraria ao arrastar e soltar? Como o arrastar e soltar em Gutenberg funcionaria? Ao arrastar, você está clonando um elemento fantasma ou usando o elemento existente? Ao soltar, onde você pode inserir marcadores de posição para soltar um bloco?

• Como o VueJS / Marko / Angular (e seu DOM virtual) funcionaria com os editáveis ​​de conteúdo e a API de seleção e intervalo de DOM? Inconsistências entre navegadores com esta gama e seleção podem ser muito difíceis de detectar aqui.

• Até que ponto copiar / cortar / colar funcionará no editor de Gutenberg? Posso fazer uma seleção de texto entre vários blocos e executar um recortar / copiar / colar? Os editáveis ​​de conteúdo residem em cada bloco individual ou está tudo contido em um conteúdo editável mestre?

• Se houver blocos de Gutenberg que contenham iframe incorporáveis, por exemplo, incorporar um player do YouTube ou feed do Twitter em uma postagem de blog, mover este bloco de uma posição DOM para outra faria com que o iframe recarregasse a si mesmo. Outras advertências incluem a incapacidade de obter eventos propagados do iframe de volta para o editor (imagine se você estiver arrastando um elemento de bloco pelo editor e seu cursor estiver pairando no iframe entre sites e tudo parar de funcionar).

Todos os frameworks são ótimos para trabalhar com o Virtual DOM, mas muito uso do WYSIWYG fica fora do Virtual DOM. Acho que as áreas a serem focadas ao avaliar o framework certo para Gutenberg é quão bem o framework pode lidar com o tratamento de eventos DOM, e para requisitos de ponta que não podem ser construídos com framework, quão gerenciável é construí-lo fora do framework e conecte-o novamente.

Visão

O Wordpress é fácil o suficiente para novos desenvolvedores aprenderem e também é poderoso se você olhar um pouco mais a fundo, o mesmo pode ser dito do Vue.
Ficarei feliz se o WP usar esta estrutura!

Meu voto é VUE!

Em termos de construção de componentes da web personalizados, o que eu acho muito importante daqui para frente, este site fornece uma pontuação para cada estrutura listada com parâmetros de teste e pontuações. É instrutivo, então encorajaria todos a dar uma vez mais:

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

Meu voto para VueJS. Framework incrível, acho que o Laravel provou isso.

WP + Sage 9 (roots.io) + VueJS => pilha perfeita

Pode haver um problema com o Preact também.

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

Usar o Preact pode deixá-lo pior do que usar o react. O Facebook teria permissão para bloquear você de usar react ou preact mesmo se você não tivesse iniciado o processo. Este advogado parece pensar que Preact não seria capaz de manter seus direitos autorais no tribunal e seria considerado infrator se reagisse.

Me diga se estou errado. Não sei muito sobre direito, mas queria ser útil.

Eu li isso e é semelhante ao conselho jurídico que recebemos depois de decidir
abandonar React em nossos projetos. Não é que o risco seja enorme. Ao invés nós
queria minimizar o risco para clientes downstream. Este advogado apenas adiciona um
opinião concordante. Estamos usando Polymer e Vue, ambos funcionam muito bem
para casos de uso específicos.

Em 20 de setembro de 2017, 23h04, "Coding Friend" [email protected] escreveu:

Pode haver um problema com o Preact também.

https://blog.cloudboost.io/3-points-to-consider-before-
migrating-away-from-react-because-of-facebooks-bsd-
patente-licença-b4a32562d268

Usar o Preact pode deixá-lo pior do que usar o react. Facebook seria
tem permissão para bloquear você de usar react ou preact mesmo que você não tenha iniciado
o processo. Este advogado parece pensar que Preact não seria capaz de segurar
são direitos autorais em tribunal e seriam considerados infratores ao reagir.

Me diga se estou errado. Não sei muito sobre direito, mas queria ser útil.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/WordPress/gutenberg/issues/2733#issuecomment-331045326 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AH2_iHc8Rg54IDHqe8GIyVTdSbcJbZ9Iks5skeBngaJpZM4PYie9
.

Jurei a mim mesmo que nunca mais tocaria no WP depois de ver o código horrível, mas se você usar o VueJS, posso reconsiderar com um pouco de Valium.

Isenção de responsabilidade: não sou advogado. Seguir é estritamente minha opinião.

@ codingfriend1 esse artigo tem pouco mérito prático.

Existem três suposições feitas:

1. O Facebook tem patentes que são amplas o suficiente para cobrir o pré-ato.
2. Se uma empresa que usa o preact, digamos ABC, processar o FB por violação de patente, então o FB usará as patentes react para processar o ABC.
3. A patente do Facebook tem mérito.

Vamos dar uma olhada em todas as suposições:

1. O Facebook tem patentes que são amplas o suficiente para cobrir o pré-ato.

Não há prova disso até a data. Lembre-se de que todas as patentes são públicas. O código-fonte do Preact é de conhecimento público.
Além disso, Jason Miller (autor do pré-ato) afirmou que "nada do Preact é patenteável - é óbvio demais".

Portanto, eu diria que é improvável que essa suposição seja verdadeira. É possível, mas improvável.

1. Se uma empresa que usa o preact, digamos ABC, processar o FB por violação de patente, então o FB usará as patentes react para processar o ABC.

Isso destruirá a reputação do Facebook. Embora eu espere que o FB lute com unhas e dentes, usar a patente do react dessa forma irá rotular o FB como "troll de patentes".

Enquanto isso, o FB tem recursos suficientes para lutar por meios legais. Portanto, acredito que essa suposição também seja improvável.

1. A patente do Facebook tem mérito.

Sim, isso é uma suposição, não um fato.

Acontece que "ter uma patente" e "ter uma patente válida" são duas coisas diferentes.
Eu li este artigo fantástico em que o tribunal considera as patentes inválidas.

Sempre existe a possibilidade de que a patente do FB seja ampla demais para ter mérito.
Agora se poderia pensar que, se o Facebook tiver uma patente, ela terá _alguns_ méritos. No entanto, logicamente falando, se abrange pré-ação, então é muito amplo e, portanto, sem mérito. Portanto, esta suposição está em conflito direto com a suposição 1.

Considerando que o Facebook está usando patentes para se defender, é mais provável que as patentes do Facebook sejam amplas e sem mérito, em vez de serem aplicáveis.

Conclusão:

Tenha em mente que todas as três suposições não foram testadas. Se todos eles forem verdadeiros, - e isso é tecnicamente possível - então, "sim, usar pré-ação é perigoso."

No entanto, na prática, as chances de todas as três suposições serem verdadeiras são muito baixas, especialmente as suposições 1 e 3 juntas.

Portanto, até e a menos que o tribunal decida de outra forma, eu diria que usar o preact (e outras bibliotecas vdom) é bastante seguro.

Em relação ao ponto 1, o Facebook tem uma patente chamada Delegação eficiente de eventos em scripts de navegador . Essa é basicamente a função live() do jQuery (mais tarde fazendo parte de on() na API do jQuery)!

No entanto, independentemente da validade das suposições, o motivo pelo qual o WordPress está se afastando do React não é que o WordPress se preocupa com o Facebook. E estou citando o post de anúncio com link na edição acima ( destaque o meu):

Acho que a cláusula do Facebook é realmente mais clara do que muitas outras abordagens que as empresas poderiam adotar, e o Facebook tem sido um dos melhores contribuidores de código aberto que existe. Mas temos muitos problemas para resolver, e não cabe a nós convencer o mundo de que a cláusula de patente do Facebook é adequada.

Com base nisso, é a percepção, confusão e perguntas que a patente traz que afastou o WordPress. Acho que as mesmas preocupações também se aplicam ao Preact, conforme explicado em meu comentário anterior .

Em relação ao ponto 1, o Facebook tem uma patente chamada Delegação eficiente de eventos em scripts de navegador. Essa é basicamente a função live () do jQuery (mais tarde fazendo parte de on () na API jQuery)!

Isso significa que eles inventaram a ideia de delegação de eventos ?! Eu vejo algumas citações lá que datam do ano de 1995, o que isso significa?

@ChrisCinelli em relação ao que você chamou de "parece ser o ponto de inflexão de um crescimento exponencial" no caso de Marko.

Acredito que seja apenas uma questão de escala. Quando um projeto tem 5k ou até 10k estrelas no Github, um único acontecimento como por exemplo um link no topo da página do Hackernews pode trazer 1k estrelas em um dia, que no caso do Marko é 20% do número recente.

Na escala de 65k estrelas que Vue possui, não é tão visível. Você pode até ver que, por causa de como o script de história das estrelas funciona, em algum ponto ele para de mostrar as flutuações e é apenas uma linha reta até o fim.

Tal situação não é exclusiva do próprio Marko, aconteceu com o Inferno ou recentemente com o MoonJS, que é um microframework inspirado no Vue. Você poderia até dizer que Preact parece estar em um ponto semelhante por causa de quantas estrelas ganhou recentemente devido a todo o drama das patentes React.

Você pode observar do que estou falando no gráfico a seguir, da mesma fonte que a sua:

O tempo dirá se essas pessoas realmente tentarão a estrutura em desenvolvimento, se a usarão na produção e se continuarão a usá-la mais tarde. Desejo o melhor ao Marko, como a todas as outras bibliotecas de código aberto.

Quanto ao Vue, sim, é um crescimento estável sem grandes oscilações. Com a velocidade atual, deve superar o React antes do Natal. Pelo menos no Github. :)

E @aurelia?
Site: aurelia.io
@EisenbergEffect criou isso.

Para mim é um ótimo framework!

1. Convenções simples (podem ser personalizadas)
2. HTML simples
3. Vanilla JS
4. Sem intervenção de estrutura!

Você pode até mesmo plugin sua escolha de biblioteca (jQuery, Vue.js, Preact, Ember, HyperHTML, etc ...) que deseja usar e ensinar Aurelia como usá-lo!

É tão simples e baseado em padrões que você nem precisa do suporte da comunidade, e se você realmente acha que o suporte da comunidade é importante, eles também ajudam você (com mais de 10 mil estrelas).

Recursos para @aurelia :

1. Apresentando Aurelia
2. Aurelia Blog
3. Aurelia Docs

Parece que o React está sendo licenciado novamente pelo MIT: https://code.facebook.com/posts/300798627056246

A decisão deve ser revertida agora, suponho.

Holly Molly! React está de volta aos negócios. WordPress fez isso? Não tenho certeza! São 3 da manhã e estou super animado com isso! E se você!

Relicenciando React, Jest, Flow e Immutable.js

Na próxima semana, vamos relicenciar nossos projetos de código aberto React, Jest, Flow e Immutable.js sob a licença do MIT. Estamos relicenciando esses projetos porque o React é a base de um amplo ecossistema de software de código aberto para a web e não queremos atrasar o progresso por motivos não técnicos.

Esta decisão vem após várias semanas de decepção e incerteza para nossa comunidade. Embora ainda acreditemos que nossa licença BSD + Patentes oferece alguns benefícios aos usuários de nossos projetos, reconhecemos que não conseguimos convencer de forma decisiva esta comunidade.

Na esteira da incerteza sobre nossa licença, sabemos que muitas equipes passaram pelo processo de seleção de uma biblioteca alternativa para React. Lamentamos a rotatividade. Não esperamos reconquistar essas equipes fazendo essa mudança, mas queremos deixar a porta aberta. A cooperação amigável e a competição neste espaço nos impulsionam a todos e queremos participar plenamente.

Essa mudança naturalmente levanta questões sobre o restante dos projetos de código aberto do Facebook. Muitos de nossos projetos populares manterão a licença BSD + Patentes por enquanto. Estamos avaliando as licenças desses projetos também, mas cada projeto é diferente e as opções de licenciamento alternativas dependerão de uma variedade de fatores.

Incluiremos as atualizações da licença no lançamento do React 16 na próxima semana. Estamos trabalhando no React 16 há mais de um ano e reescrevemos completamente seus componentes internos para desbloquear recursos poderosos que beneficiarão a todos que criam interfaces de usuário em escala. Em breve compartilharemos mais sobre como reescrevemos o React e esperamos que nosso trabalho inspire os desenvolvedores em todos os lugares, quer usem o React ou não. Estamos ansiosos para deixar essa discussão sobre licença para trás e voltar ao que mais nos preocupa: o envio de produtos excelentes.

Na minha opinião, com a licença do MIT e com a maior e mais ativa comunidade de JS de código aberto por trás dela - React é a escolha definitiva para seguir.

Meu voto está de volta com React agora . - Fé na humanidade restaurada.

Vote com 👍 em vez de comentários semelhantes.

Quero expressar meus MUITOS AGRADECIMENTOS ao Wordpress por ter participado do que levou a essa mudança no lincenciamento do React.

Ainda acho que Vue seria a melhor solução. Muitos dos pontos fortes do Vue ainda se aplicam, mas eu quero apontar que a facilidade de início e não ter que usar uma etapa de construção são, na minha opinião, recursos matadores no ambiente wordpress.

para a missa
com certeza
para vueJS

Eu também escolhi Angular2.0 + (não AngularJS), que tem a maior comunidade, uma forte equipe de desenvolvedores e um ecossistema estável e completo.

@CrazyBBer Onde posso encontrar alguns dados sobre a maior comunidade sendo o Angular 2/4? Isso me ajudaria com uma postagem no blog.

Enfim, pessoal acabou, o React veio para ficar com o WordPress e mesmo como um entusiasta do Vue, acho que da melhor maneira possível a situação poderia virar, dada a quantidade de código já escrito com o React.

@ahmadawais @gustojs pessoas no Reddit levantaram preocupações de que o MIT cobre apenas direitos autorais, então os desenvolvedores NÃO terão uma concessão de patente ao usar o React, o que eu presumo que ainda seja um problema.

Além disso, esta declaração realmente me incomoda:

reconhecemos que não conseguimos convencer de forma decisiva esta comunidade.

Dizendo efetivamente "Não estávamos errados - vocês, desenvolvedores, simplesmente não nos entenderam".

@ahmadawais : Eu ainda acho que ir com o Vue seria uma escolha melhor, já que você viu um exemplo perfeito de como o licenciamento do React pode ser inconstante, primeiro eles tinham BSD + Patents license agora, mudando para o MIT. Quem sabe em um futuro próximo eles podem voltar para alguma Licença / Patente de propriedade do FB e então todo mundo vai querer secar. A Vue é MIT desde o início e é mais voltada para a comunidade do que para uma grande corporação.

Mais o que @ atanas-angelov-dev disse.

Não há porque mudar agora.
Acho que Vue está oferecendo uma perspectiva melhor, mas isso significaria reescrever tudo

Ahh! Vamos pessoal, dê uma chance a Aurelia, sim!
Ele foi criado por um dos desenvolvedores líderes da equipe Angularjs.
Você pode ir de uma pequena adoção a um framework completo, como o Vue.js

Até a equipe do portal @azure disse que se tivessem começado agora, teriam escolhido Aurelia ao
E quem sabe?! eles podem estar migrando para Aurelia aos poucos agora.

Comece devagar, sei que você vai gostar!

Nirmal4G,
Sua tese parece tão comercial que é ridícula.
Na verdade, acredito que todo o framework tem as mesmas falhas desta página 404 que você vincula diretamente em sua postagem.
http://aurelia.io/get-started.html

@ bovas85 Não comercialmente, nem faço parte desse time. Eles nem sabem que estou usando a estrutura deles.

@ cr101 / cc

Não julgue o livro pela capa

Usei muitos frameworks populares antes mesmo de saber sobre o Aurelia. Se eu tivesse que empilhá-los, balanceando todos os critérios existentes, para minha aplicação (acredite em mim, é uma aplicação grande), então Aurelia encabeça a lista e seguida por Vue.

Acredito que todo o framework tem as mesmas falhas desta página 404 que você vincula diretamente em sua postagem.

Cada link que postei nunca vai para uma página 404. É culpa do github redirecionar um site http para https. Está consertado agora. Veja, um bug. Diga-me qualquer framework que não tenha bugs, eu te desafio.

Só que com outros frameworks você tem muitas abstrações redundantes (mas úteis). A comunidade W3C nunca adota um design de estrutura pública em sua API, então aí está, Muitas abstrações.

Cada estrutura é tão focada na compatibilidade com versões anteriores que perdem compatibilidade com versões anteriores, mas Aurelia não faz isso, contanto que você siga as especificações W3C e ECMAScript de HTML, JS, seu código funciona bem.

_Se não houver Aurélia eu não me importaria de ficar com Vue. É a segunda melhor coisa._

_É apenas uma questão de aceitar um padrão do que criar uma nova maneira de reinventá-lo._

@ Nirmal4G forneça provas de suas reivindicações ou evite nomes. Eu dificilmente acredito, especialmente quando se trata de LOC, o Vue era menos que hiperHTML. Tudo o que escrevi em hiperHTML em layout e a lógica . Por mais que eu nem mesmo acredite em LOC como métrica relevante para qualquer coisa, ler FUD não comprovado não parece justo para mim.

@WebReflection Controle seus cavalos, eu não disse que você é pior do que Vue. Desculpe se eu te ofendi.

Meu aplicativo usa tudo que você pode jogar nele. Eu tentei um protótipo com muitos frameworks, um dos critérios que eu tinha era o LOC mas do ponto de vista visual, não é pelo motivo que você pensa, o desempenho de qualquer framework pode ser melhorado mas são as escolhas de design, que vem com o nome.

Eu avaliei o HyperHTML, o desempenho foi impressionante, nenhum polyfills é ótimo, mas infelizmente para os meus requisitos ele não foi aprovado.

Cada framework tem uma coisa melhor. Meu desejo é que se alguém pudesse juntar o melhor de todos os frameworks por aí com um design melhor, isso seria divino, mas não vai acontecer. Então, eu tenho que encontrar aquele equilíbrio onde um framework pode melhorar no futuro e onde não irá.

É muito bom saber que React agora vai ser MIT.
Isso me deixa muito animado com este projeto e estou ansioso para começar a usar o WordPress novamente depois de muito tempo, uma vez que React e WP API serão totalmente suportados. :)

Vamos esperar para ver qual será a licença real do React. MIT ou MIT + Patentes ..? ;)

Pessoalmente, gosto do React, mas acho o Vue mais produtivo. Eu ficaria feliz com qualquer um, mas ...

... tendo em vista o forte apoio da comunidade ao Vue, sugiro levar isso em consideração, além do licenciamento.

Vue parece ser a escolha mais apropriada para WordPress.

O Facebook removeu 4 itens de seu conjunto de armadilhas de litígio. Estes agora são todos licenciados pelo MIT:

• Reagir
• Jest
• Fluxo
• Immutable.js

Enquanto isso, a licença Categoria X do Facebook ainda se aplica a:

• React Native
• GraphQL
• Fio
• Retransmissão
• IDE Atom
• e provavelmente qualquer outra coisa feita por eles e com código "aberto"

Eu ainda digo vá com Vue. Vale a pena no longo prazo. React nunca fez sentido para mim para Wordpress de qualquer maneira. Está tão fortemente integrado na comunidade PHP que o Vue sempre pareceu a escolha mais sensata (além disso, não é doloroso de usar como o React).

Enquanto isso, a licença Categoria X do Facebook ainda se aplica a:

React Native
GraphQL
Fio
Retransmissão
IDE Atom
e provavelmente qualquer outra coisa feita por eles e com código "aberto"

@TheJaredWilcurt desculpe, mas talvez você queira remover o fio dessa lista .. o fio não tem essa licença "Categoria X do Facebook" -> https://github.com/yarnpkg/yarn

@ atanas-angelov-dev

Pessoas no Reddit levantaram preocupações de que o MIT cobre apenas direitos autorais, então os desenvolvedores NÃO terão uma concessão de patente ao usar o React, o que eu presumo que ainda seja um problema.

O MIT é uma ótima licença. jQuery também é licenciado pelo MIT. Eu espero que você saiba disso.

@vinayakkulkarni Eu ainda acho que ir com o Vue seria uma escolha melhor, já que você viu um exemplo perfeito de como o licenciamento do React pode ser inconstante, primeiro eles tinham a licença BSD + Patentes agora, mudando para o MIT. Quem sabe em um futuro próximo eles podem voltar para alguma Licença / Patente de propriedade do FB e então todo mundo vai querer secar. A Vue é MIT desde o início e é mais voltada para a comunidade do que para uma grande corporação.

Não é assim que funciona. Eu li o comentário de Samuel no Facebook sobre uma pergunta semelhante. Depois de licenciar o MIT, você pode bifurcá-lo para alterar a licença ou simplesmente não pode. Mas não sou advogado.

Além disso, pessoalmente, acho que o Facebook fez isso como um gesto de boa fé e não para enganar as pessoas. Isso significa algo para mim.

Além disso, pessoalmente, acho que o Facebook fez isso como um gesto de boa fé e não para enganar as pessoas. Isso significa algo para mim.

Essa não é uma afirmação muito lógica. Você está recompensando um grupo porque eles pararam de fazer algo negativo, em vez de recompensar o grupo que nunca fez nada negativo. Além disso, como mencionado acima, eles ainda estão usando o licenciamento da Categoria X em outros projetos semelhantes, o que não é um sinal de boa fé para mim.

O Vue tem uma curva de aprendizado e adoção MUITO mais suave.
E essa tem sido a principal ideia subjacente do WordPress desde o início.

@ahmadawais eu sei - o MIT é tão bom quanto as licenças, mas, e este é um grande "mas", o Facebook aparentemente tem patentes no React e enquanto o MIT permite que você use o código para qualquer propósito, você ainda pode acabar infringindo o do Facebook patentes (tome tudo isso com uma pedra de sal - IANAL)

E, para permanecer no tópico, devo dizer que vejo muito do que tornou o WordPress excelente no Vue também - na minha humilde opinião, nenhuma outra biblioteca adequada é tão fácil de aprender e usar como o Vue.

O Facebook aparentemente tem patentes no React

que parte do React você acha que é patenteada? (nada no React é patenteado, tente fazer uma pesquisa primeiro) mostrar links, não apenas "aparentemente" .., esse é o tipo de comentário que não ajuda em nada. se você quer recomendar sua biblioteca favorita faça da maneira certa, mostrando seus méritos, não apenas divulgando FUD.

Por que a mudança original para BSD + Patentes se nenhum dos React tem patentes por trás disso? O Facebook não disse o que é ou o que não é.

Por que mexer com o licenciamento por 2 anos e fazer uma mudança apenas para parte do portfólio deles, tendo consistentemente dito que não iriam mudar, e dito "basta lidar com isso, não importa se você usa ou não".

Por que excluir React Native, GraphQL etc etc do "novo" licenciamento? Qual será a versão futura do React? Não há garantias quando você tem o licenciamento de dois níveis do Facebook, dependendo de quem reclama ...

E se parte do código React Native for transferido para o React. Onde você fica se uma implementação de GraphQL funciona em uma base de código ..?

Esta ação do Facebook levanta mais perguntas do que respostas, e ainda significa que cada uso do React é um risco potencial para verdadeiros projetos de código aberto.

Basta adotar a biblioteca sem bagagem que já está consagrada no mundo do PHP - Vue.

@bjrmatos https://www.google.com/patents/US20170221242 Acho que sim !

Mais um +1 para Vue. O Facebook ainda usa duas licenças em seus projetos. Isso não é bom.

@PericlesSouza você claramente ignora o grande esforço que uma empresa como o Facebook está fazendo para melhorar as coisas e levar a web adiante, todas as suas perguntas podem ser respondidas se você apenas ler o post sobre a mudança para o MIT. Eu realmente não sei por que você ainda está levantando essa preocupação irracional com a licença do MIT, com a mudança, React está na mesma posição que qualquer outro projeto "True Open Source" (eu não sei o que você chama de projeto True Open Source btw).

@Raymonf bem, basicamente qualquer estrutura moderna por aí já está violando essa patente (incluindo Vue), então qualquer pessoa está na mesma posição, não importa se você usa React, Vue ou outra estrutura que implemente o conceito descrito no link (btw basicamente qualquer web projeto lá fora já está violando duas ou três patentes de outras empresas, você ficará surpreso em saber que tipo de coisas são patenteadas por empresas atualmente). Se você está realmente preocupado com isso, significa que você não pode usar qualquer framework que atualize a IU dessa forma ... então, neste contexto legal, não há alternativa melhor ou pior.

Não quero me envolver nesse tipo de conversa novamente porque será impossível chegar a um acordo, então vou parar com meus comentários. A comunidade React está feliz com a mudança para o MIT (mesmo os maiores detratores da licença original)

Boa sorte para a equipe do wordpress na decisão, o principal problema sobre a licença React BSD + Patents está resolvido, agora cabe a eles decidir.

Então, o Facebook mudou recentemente seu licenciamento para React. Isso significa que o WordPress continuará a usar o React ou ainda mudará a estrutura de front end padrão?

@bjrmatos isso não é verdade

basicamente qualquer estrutura moderna que existe já está violando essa patente

por exemplo, o hiperHTML não usa DOM virtual, ele usa diretamente a API DOM (impossível de patentear) por meio de chamadas de retorno de chamada regulares (impossíveis de patentear) e o único algoritmo de diffing para transformar c hildNodes: depois em listas de nós é baseado na distância de Levenshtein (não patenteável) e a menor quantidade de operações de emenda (não patenteável, eu escrevi isso e é ISC ).

E embora neste ponto eu ache que este tópico está obsoleto e sem sentido, eu não entendo a necessidade de continuar espalhando FUD. Se você fez uma escolha e gostou dela, não há razão para dizer a todos que eles estão fazendo algo errado ou estão com os mesmos problemas que você. Eu gostaria que pudéssemos concordar com isso.

@noncototient é uma pergunta de um milhão de dólares, não é? 💯

Acabei de cancelar a inscrição aqui, pois a discussão está ficando um pouco sem sentido.
Acho que muitos pontos positivos foram adiantados e foi uma experiência de aprendizado para todos que leram esta edição com atenção.

Eu concordo, isso agora é inútil. Eu sugiro que este tópico seja bloqueado (ou talvez apenas colaboradores). Já houve feedback suficiente sobre este assunto, e agora está chegando ao ponto em que só levará a argumentos não construtivos.

Este problema será encerrado?
Parece que @WordPress não está interessado em migrar para o novo JavaScript Framework agora. 🤔

Para mim, pessoalmente gosto de @vuejs. Mas parece que isso não importa agora. 😅

Pessoalmente, eu preferiria muito mais o Vue, independentemente.

Para mim, e acredito que para muitas outras pessoas, nunca foi sobre licenciamento. Esta foi apenas uma desculpa para se afastar de React.

Marko é incrivelmente poderoso e fácil. No momento, estamos concluindo uma reescrita completa de uma loja virtual dinâmica com 50.000 produtos e ela é impressionante e repleta de recursos. Siga este caminho e não olhe para trás.

Marko é bom, mas Prarko é 100 bytes menor (GZipped) e é 0,01% mais rápido em um teste auto-otimizado, então temos que usar isso, mesmo que ninguém mais o faça. Embora amanhã Plarko seja lançado, com fibra adicionada, o que torna _tudo_ redundante.

Desculpe, mas é assim que o resto deste tópico se encaminha.

Vamos esperar e ver qual é o licenciamento real quando for lançado, quais são as implicações do licenciamento de duas camadas do Facebook e ver qual decisão a equipe do WordPress tomará depois de investigar o problema minuciosamente.

Quer dizer, originalmente ele pedia informações sobre os motores que a comunidade gosta. E parece ser isso que as pessoas estão postando, mas algumas pessoas simplesmente pulam em cima das pessoas para enviar comentários que estão alinhados com o que foi solicitado. Meio estranho.

Todas as bibliotecas / estruturas mencionadas aqui são excelentes; alguns são mais adequados a alguns cenários do que outros. Cada um terá seus defensores, cada um estará ultrapassando os outros em termos de desempenho / recursos, dependendo de seus ciclos de desenvolvimento.

Talvez comece com uma pergunta simples, como faço na maioria dos projetos:

1. Precisamos de uma estrutura de SPA?

Se a resposta for sim, explique por quê. Isso fornece um conjunto de critérios para avaliar os candidatos em potencial; talvez para renderização do lado do servidor, talvez roteamento, etc.

Se não, faça a próxima pergunta:

1. O que realmente precisamos é de um mecanismo de template?

VanillaJS tem a maior comunidade do planeta e sem problemas de licenciamento. Também é compatível com os padrões;), e com módulos ES6, pode oferecer uma base adequada para o desenvolvimento do núcleo, com a capacidade de suporte a plug-ins para usar mecanismos de _template_ como React, Vue, Preact, Aurelia etc. etc., o que for lançado em nos próximos anos, conforme exigido pelos desenvolvedores.

Matt Mullenweg postou sua resposta ...

Estou surpreso e animado em ver a notícia de que o Facebook vai retirar a cláusula de patente sobre a qual escrevi na semana passada. Eles anunciaram que, com o React 16, a licença será apenas do MIT normal, sem adição de patente. Aplaudo o Facebook por fazer essa mudança e espero que o uso de cláusulas de patentes seja reexaminado em todos os seus projetos de código aberto.

Nossa decisão de nos afastarmos do React, com base em sua postura anterior, gerou muitas discussões interessantes no mundo do WordPress. Particularmente com Gutenberg, pode haver uma abordagem que permite aos desenvolvedores escrever blocos de Gutenberg (Gutenblocks) na biblioteca de sua escolha, incluindo Preact, Polymer ou Vue, e agora React também pode ser uma opção com suporte oficial.

Quero agradecer a todos que participaram da discussão até agora, agradeço muito. O vigoroso debate e discussão nos comentários aqui e no Hacker News e no Reddit foi ótimo pela paixão que as pessoas trouxeram e pela oportunidade de aprender sobre tantos pontos de vista diferentes; era ainda melhor que o Facebook estivesse ouvindo.

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

@ahmadawais @m

Nossa decisão de nos afastarmos do React, com base em sua postura anterior, gerou muitas discussões interessantes no mundo do WordPress. Particularmente com Gutenberg, pode haver uma abordagem que permite aos desenvolvedores escrever blocos de Gutenberg (Gutenblocks) na biblioteca de sua escolha, incluindo Preact, Polymer ou Vue, e agora React também pode ser uma opção com suporte oficial.

Essa situação pareceria uma vitória para todos. Vamos esperar para ver como isso realmente acontece.

Basta encerrar esta edição agora .. só vai ver como o mundo é inconstante .. triste ver as pessoas não cumprindo sua palavra.

[Editar: removido devido a declaração ofensiva]

Boa sorte a todos que precisam usar Gutenberg e a pesada curva de aprendizado do aprendizado React with it.

Paz.

👋 Acho que todos nós discutimos muito aqui. Gostaria de agradecer a todos que se importaram em conversar e comentar sobre o assunto. IMHO, parece que todas as opções que temos agora são boas opções.

Se acabarmos com uma API agnóstica de framework melhor, será possível usar qualquer JS Framework que desejar em seus aplicativos. Com a licença do MIT, o React tem uma posição tão forte para ser usado no núcleo quanto qualquer outra biblioteca com uma boa licença de código aberto (compatível com leitura).

🎯 Se você está torcendo por um framework JavaScript específico ou construiu um (equipes principais), sugiro que crie exemplos reais para os desenvolvedores do WordPress para que as pessoas possam começar a brincar com a ideia de usar o seu framework JavaScript preferido nos aplicativos baseados no WordPress que eles Construir.

Estou fechando este tíquete por enquanto. E na esperança de contribuir mais para o sucesso do WordPress tanto como plataforma quanto como comunidade. Esperando o mesmo de todos aqui. Eu realmente acredito que esta será uma aventura de montanha-russa para quem trabalha com o software WordPress.

Daqui a algum tempo, podemos acabar melhorando o software para ajudar a torná-lo mais fácil para seus usuários (cerca de 30% dos sites da Internet) como se fosse há alguns anos. Estou torcendo pelo WordPress aqui, como todos vocês!

Felicidades!

Não está muito claro a partir do comentário de Matts se a decisão de se afastar do React foi rescindida.

Em primeiro lugar, a licença real que o Facebook usará ainda não foi publicada , então fingir que tudo acabou não é uma atitude muito sensata.

Em segundo lugar, não aborda o licenciamento de duas camadas que o Facebook está seguindo: React pode ser MIT, mas React Native será + Patentes (não divulgadas) .

Então ... o que acontece com os componentes que são compartilhados por ambos?

E quanto ao código React Native sendo usado no React? O Fiber será compartilhado entre duas licenças diferentes? Ou o código GraphQL encontra o caminho para React?

O que acontecerá com o WordPress se ele seguir o caminho do React, com todos esses projetos relacionados do Facebook publicados sob uma licença diferente, e então o Facebook decidir que alguns aspectos do React estão realmente sujeitos a, por exemplo, uma concessão de patente do React Native, ou uma fibra Concessão de patente?

Sério, pense muito bem sobre isso. Por que arriscar quando existem alternativas que a maioria prefere usar, que não tem esse problema - Vue.

Eu não confiaria em um contrato de licenciamento que muda com o vento, em vez de ser bem pensado. Os advogados do Facebook podem mudar isso por um capricho.

Fique com o código aberto genuíno.

@PericlesSouza A licença será exatamente o que as pessoas aqui imaginam a partir da descrição do post do blog: uma licença padrão do MIT, nada mais. O React não depende do React Native. As peças que são compartilhadas por ambos vivem no projeto React, não no React Native. O React e suas dependências de propriedade do FB estarão disponíveis no MIT assim que nossa equipe tiver tempo para confirmar as alterações. Não estamos planejando nenhum negócio engraçado.

@sophiebits

Você trabalha para o Facebook. Se você não é um advogado autorizado a falar em nome do Facebook, não importa o que você reivindique. Não importa o código que você escreve. Desculpa.

Licenças de "imaginação" não valem no tribunal.

Por exemplo, você pode declarar categoricamente por que o Facebook adotou a concessão de patente, o que as patentes eram (ou não eram) ou por que eles dizem que estão mudando agora, sem dizer 'IANAL' (Eu não sou um advogado)?

As peças que são compartilhadas por ambos vivem no projeto React, não no React Native

Mas você pode dizer isso com uma garantia legal? Não?

O React e suas dependências de propriedade do FB estarão disponíveis no MIT assim que nossa equipe tiver tempo para confirmar as alterações

Quais partes estão sendo removidas para permitir que o React seja publicado no MIT? Quais _dependências não pertencentes ao FB_ que presumivelmente não eram compatíveis com o MIT você já estava usando ..? Os advogados do Facebook estarão garantindo que tudo está realmente de acordo com o MIT? Quanto tempo vai demorar para a Apache Software Foundation certificar isso?
.

Parece que eu estava certo em destacar que o código é compartilhado entre dois projetos que aparentemente terão licenciamento em duas camadas.

Você está distorcendo minhas palavras. O código compartilhado entre React e React Native será licenciado pelo MIT. Tudo o que você chama de fibra será licenciado pelo MIT. O React não incluirá ou dependerá de qualquer código licenciado sob as Patentes BSD + ou qualquer outra concessão de patente que você despreze. Não estamos removendo peças do React. A única dependência não pertencente ao FB do React que conheço é a atribuição de objeto, que também está sob o MIT.

Não estou sugerindo que você tome minhas palavras como uma garantia legal. Ambos estamos cientes de que meus comentários aqui não alteram a licença do React. Você pode escolher ser cético e não ter que acreditar em mim agora, mas em um ou dois dias verá que o que estou dizendo aqui é verdade.

@sophiebits

Não estou distorcendo suas palavras - e respeito tanto o trabalho que você faz quanto sua prontidão para se envolver aqui.

Estou simplesmente dizendo que, a menos e até que obtenhamos compromissos legais do Facebook, por funcionários autorizados da empresa, verificados por órgãos externos de código aberto, ainda estaremos na mesma posição em que começamos - ninguém pode ter certeza de qual é a situação legal real é, como você concorda em declarar:

Não estou sugerindo que você tome minhas palavras como uma garantia legal. Ambos estamos cientes de que meus comentários aqui não alteram a licença do React.

E:

Tudo o que você chama de fibra será licenciado pelo MIT.

Não importa o que eu pense como Fibra, depende totalmente do que os advogados do Facebook e as patentes registradas definem como Fibra.

Por que o React Native atualmente pretende ser licenciado de forma diferente do React, quando compartilha o código com o React? Isso não invalida (com o perdão do trocadilho) a licença do MIT?

Também observo que você não mencionou GraphQL. Mais alguma coisa que eu perdi?

O ponto principal do desastre do licenciamento React é a falta de segurança jurídica.

@sophiebits

Noto sua edição em resposta aos meus pontos:

O React não incluirá ou dependerá de qualquer código licenciado sob as Patentes BSD + ou qualquer outra concessão de patente que você despreze. Não estamos removendo peças do React. A única dependência não pertencente ao FB do React que conheço é a atribuição de objeto, que também está sob o MIT.

Mas você disse que estava removendo partes do React e verificaria o código "nos próximos dias".

O React e suas dependências de propriedade do FB estarão disponíveis no MIT assim que nossa equipe tiver tempo para confirmar as alterações

E você esqueceu o IANAL ... :-)

Oh, na verdade você disse de forma longa:

Não estou sugerindo que você tome minhas palavras como uma garantia legal. Ambos estamos cientes de que meus comentários aqui não alteram a licença do React.

De novo:

O ponto principal do desastre do licenciamento React é a falta de segurança jurídica.

Concordo com a afirmação de que ainda não existe certeza jurídica. Mas eu pessoalmente acredito que este tópico tenha terminado; melhor marcá-lo apenas como contribuidores e esperar até que a licença real seja publicada e a equipe possa fazer sua avaliação.

Cancelando a inscrição agora.

Por favor, não descarte React, o Facebook fez sua decisão https://thenextweb.com/dd/2017/09/25/facebook-re-licenses-react-mit-license-developer-backlash/

@vinayakkulkarni Embora eu entenda ser apaixonado por algo, não é motivo para fazer um comentário como você fez. Um espaço público (que são os comentários do GitHub) deve ser um lugar seguro para qualquer pessoa. Sua analogia foi ofensiva e, como tal, foi editada. No futuro, por favor, pense que todos os gêneros, todos os tipos de pessoas usam este espaço e como o que você diz pode ofendê-los.

@sophiebits, apenas uma pequena nota para agradecer por ter vindo a este tópico. Agradecemos

Este pode ser um tópico para um novo tópico, mas infelizmente a licença do MIT (mesmo a padrão) não resolve o problema de "incerteza" com patentes, o que levou à decisão do WordPress anteriormente.

A licença do MIT dá a você o direito de usar a propriedade intelectual patenteada? Leia o que um advogado tem a dizer sobre isso: The MIT License, Line by Line

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

O MIT aparentemente não concede a você uma licença de patente. O Facebook tem patentes no React, que afirma conceder a você em sua licença atual. Com a licença atual, pelo menos você sabe que recebeu todas as licenças existentes e sabe quais condições as revogam. Com um MIT, você nem mesmo obtém uma concessão de licença.

A concessão de patentes significa que existem patentes envolvidas (ou o que ela concede?). Exceto que ninguém sabe o que são as patentes. O Facebook não disse nada, nem mesmo quando os concedeu, e nem quando anunciou a remoção da concessão.

Independentemente do que eu, pessoalmente ou a equipe do WordPress, possamos pensar que isso significa, o que parece estar presente ainda é a confusão em torno da situação legal das patentes do Facebook (ainda não listadas) que tem no React, que qualquer um que usa [[pode - ou- pode não]] precisar se preocupar em violar, ao processar o Facebook hoje, ou apenas usando React após a nova licença.

Novamente, pode ou não, o problema é a incerteza, e é isso que estou sugerindo que não foi resolvido.

Como um lembrete, a maioria que ofereceu sua opinião sobre este tópico quer uma solução baseada no Vue.

Existem várias razões para isso, não se restringindo ao fato de que Vue não tem confusão de licenciamento (que ainda permanece com a política de licença de dois níveis do Facebook):

1. O Vue foi projetado desde o início para ser adicionado de forma incremental, com ilhas de funcionalidade, permitindo o aprimoramento gradual de uma base de código.

2. Além disso, e opcionalmente, ele fornece soluções de roteamento e gerenciamento de estado com suporte oficial.

3. Ele suporta múltiplos processadores para HTML, dando aos desenvolvedores uma escolha de linguagem de template - HTML, JSX, Pug, etc, ou funções de renderização.

4. Componentes de arquivo único e CSS com escopo (Stylus, SASS, SCSS, PostCSS, Componentes CSS) - da maneira mais fácil possível. Literalmente, apenas adicione o atributo com escopo às declarações de estilo de seus componentes e pronto.

5. Suporte para propriedades computadas (com memoização) embutidas (ou seja, sem dependências como MobX).

   6+. Desempenho superior ao React, curva de aprendizado muito menor, maior adoção na comunidade PHP, verifique o Laravel Mix por exemplo - você pode usar isso sem usar o próprio Laravel. Ou apenas inclua o Vue via https://unpkg.com/vue e comece a codificar.

Vue é simplesmente mais adequado para WordPress.

Reaja :

76.364 estrelas do Github
571 Problemas em aberto (!)
4325 questões fechadas
178 Abrir solicitações pull (!)
5.644 solicitações pull fechadas

Vue :

68, 246 estrelas do Github (a trajetória é para ultrapassar React no Natal)
62 Problemas abertos (muito mais responsivo à correção de bugs, adicionando recursos solicitados)
5.629 questões fechadas
17 solicitações Open Pull
863 solicitações pull fechadas

@Meligy

O MIT aparentemente não concede a você uma licença de patente. O Facebook tem patentes no React, que afirma conceder a você em sua licença atual. Com a licença atual, pelo menos você sabe que recebeu todas as licenças existentes e sabe quais condições as revogam. Com um MIT, você nem mesmo obtém uma concessão de licença.

A concessão de patentes significa que existem patentes envolvidas (ou o que ela concede?). O Facebook não disse nada, nem mesmo quando os concedeu, nem quando anunciou a remoção da concessão.

É aí que reside o problema com o código-fonte não totalmente aberto de uma grande empresa. Em última análise, seus advogados irão anular quaisquer que sejam as boas intenções das equipes de desenvolvimento, agora ou no futuro.

O Facebook enquadrou sua licença de + Patentes como uma defesa agressiva de 'algo ou qualquer coisa', e agora somos solicitados a acreditar que o mesmo 'algo ou qualquer coisa' não existe realmente para React, mas _ainda existe_ para React Native e GraphQL etc.

A Automattic pode prometer que vai assumir o peso de si mesma e levar o React, bifurcá-lo, desenvolvê-lo por conta própria, quando o Facebook mudar novamente sua licença e opinião sobre o React?

Para mim, parece que o Facebook está criando uma armadilha para o WordPress. 25% de todos os sites do mundo são grandes pegadinhas.

marque este tópico como _contribuidores apenas_ o mais rápido possível, seria ótimo ler o resultado de qualquer colaborador, em vez de apenas FUD e especulações, sem a necessidade de cancelar totalmente a inscrição. Obrigado.

As partes interessadas do @WebReflection Wordpress não são apenas seus desenvolvedores principais, mas também a comunidade estendida.

@PericlesSouza citando estrelas do Github não significa nada. E que esse problema está sendo apressado por pessoas fazendo afirmações ridículas, não significa que devemos ignorar os fatos: https://npmcharts.com/compare/react , angular, @ angular / core , ember-cli, vue

Vue não é muito mais do que um sinal no radar. A impressionante maioria usa React e certamente também não concordaria com seus pontos.

@PericlesSouza citando estrelas do Github não significa nada. E que esse problema está sendo apressado por pessoas fazendo afirmações ridículas, não significa que devemos ignorar os fatos: https://npmcharts.com/compare/react , angular, @ angular / core , ember-cli, vue

Vue não é muito mais do que um sinal no radar. A impressionante maioria usa React e certamente também não concordaria com seus pontos.

Estatísticas do NPM? Quer dizer que as mesmas estatísticas que eles admitem contam cada pedido para verificar se você está ou não usando a versão mais recente, ou através de cada dependência, como um pedido de download? (Eles admitiram isso em seu blog quando as pessoas riram de suas alegações de "bilhões de pacotes por mês").

Se você quiser seguir esse caminho, todo mundo está usando jQuery.

Talvez tente figuras para pacotes que não têm esse campo de distorção de dependência:

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

Imagem completamente diferente daquela que você escolheu para apresentar.

Ou que tal o uso do site:

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

Que é apoiado por estatísticas BuiltWith:

Ah, e vou deixar essa foto aqui - de quando a equipe perguntou à própria comunidade. Você deve ouvi-los em vez de tratá-los com desprezo.

@PericlesSouza Não faz sentido comparar vue-cli com create-react-app, pois há outras ferramentas de construção muito populares para React como Next.js e GatsbyJS .
Muitos desenvolvedores do React nem mesmo usam uma CLI e, em vez disso, usam seus próprios scripts de compilação de Webpack personalizados, assim como fazem Gutenberg e Calypso.

A realidade é que o ecossistema React é muito maior que o de Vue. Tomemos por exemplo o Material UI for Vue.js, que tem 4.339 estrelas, enquanto o Material UI for React tem 29.078 estrelas.

Um componente nativo da caixa de seleção que fornece funcionalidade semelhante ao Select2 sem a sobrecarga do jQuery: Vue select tem 1.348 estrelas, enquanto o React select tem 8.493 estrelas.

@PericlesSouza , @drcmda , todos esses dados podem ser contestados de várias maneiras, até mesmo as estatísticas npm com os cli's, se você adicionar AngularCLI e EmberCLI verá dados totalmente diferentes, o que não significa nada:

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

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

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

Mas essa conversa não deve ser sobre qual framework é mais usado, mas qual será melhor para o ambiente Wordpress como um todo.

@PericlesSouza @willgm As regras se aplicam a ambos. Ambos são contados exatamente da mesma maneira, muito hipócrita afirmar que não é justo. Apegar-se a CLIs opcionais ou sites sugestivos contando "curtidas" e "estrelas" é inútil. Mesmo stackoverflow é altamente subjetivo e eu nunca tinha ouvido falar do site "builtwith ..." até hoje, e as estatísticas de CLI, bem, refletem quantos usam uma CLI (a maioria não).

Os dados da fonte mais óbvia e importante, refletindo ambientes de produção reais sob as mesmas circunstâncias exatas, é a única estatística que você não gosta que eu receba, não muda o jeito que está.

Mas essa conversa não deve ser sobre qual framework é mais usado, mas qual será melhor para o ambiente Wordpress como um todo.

E imagino que você saiba qual é o mais adequado. Você acha que as 400.000 pessoas por dia tirando o React do npm estão todas enganadas. O Vue poderia competir por conta própria, realmente não precisa de uma multidão correndo para rastrear problemas.

@PericlesSouza @willgm As regras se aplicam a ambos. Ambos são contados exatamente da mesma maneira, muito hipócrita afirmar que não é justo. Apegar-se a CLIs opcionais ou sites sugestivos contando "curtidas" e "estrelas" é inútil.

Não. React tem 16.800 pacotes dependentes que distorcem os números. O NPM admite que tudo o que conta como download é um código de 200 resultados ao chamar um URL, como resultado de uma verificação de dependência, ou um bot, ou um espelho, ou qualquer coisa. A propósito, eles também dizem que a maioria dos downloads na China, onde o Vue é altamente popular, são de espelhos e não são contados.

A julgar pelo seu uso da linguagem - 'apego', 'sites sugestivos', 'fútil', você não tem nenhum argumento real sobre este assunto, enquanto que, conforme solicitado pela equipe, eu postei os aspectos positivos do uso do Vue (consulte acima ).

Contando estrelas - outros fazem isso quando apontam para o sucesso do React, mas você critica o valor deles quando usado para indicar a popularidade do Vue? Você também não faz nenhuma menção ao número muito maior de questões pendentes ( 571 ) e ao número bastante notável de solicitações de pull pendentes ( 178 ) ainda pendentes para React, que quando comparado com a maior capacidade de resposta da comunidade Vue na correção de bugs e adicionar recursos é um motivo válido de preocupação ao propor o uso do React.

O que me leva a:

Contando Gostos - bem, esse foi o ponto principal deste tópico, iniciado pela equipe e solicitado à Comunidade - acho que você simplesmente não gostou do resultado. Aqui está novamente, e muito conclusivo é:

Não. React tem 16.800 pacotes dependentes que distorcem os números.

@PericlesSouza Como você chega a essa conclusão. Isso significa o que deveria significar: 16.800 pacotes declararam React como sua dependência em package.json. Nem bots, nem China, ... pacotes. O Vue tem cerca de 2580, o que significa que tem um ecossistema e uma base de usuários muito menores. Por que estamos discutindo isso? Isso se reflete diretamente nas estatísticas de uso. Atualizações, pessoas reais ou bots, se aplica a ambos os pacotes. A menos que você assuma que os bots estão deliberadamente ignorando o Vue por algum motivo.

Separar um pacote em um rastreador que trata cada pacote da mesma forma faz quase nenhum sentido. Por outro lado, contar curtidas significa nada mais do que a comunidade XY sabia onde votar.

@dcrmda

Acho que o que ele quis dizer é que toda vez que você instala um pacote que tem dependência do React e atinge o NPM para verificar as versões e dependências, esse NPM conta isso como download do pacote, mesmo que não seja baixado.

Se é isso que ele quer dizer, então está totalmente correto; é explicitamente declarado pelo NPM que eles fazem isso; eles descrevem sua 'metodologia' como 'intencionalmente ingênua' (eles também mencionam que bots e espelhos podem distorcer os números, já que não têm mecanismo para determinar para que serve uma solicitação, eles apenas contam). E o React tem pacotes mais dependentes, portanto, esse efeito é mais pronunciado.

Quanto a muitos pacotes dependentes - sim, o React, sendo um framework mais antigo, tem mais, e meio que precisa deles. Eu desenvolvo com React e Vue, e com Vue você tende a precisar de menos pacotes adicionais, já que o núcleo é bem completo, e o Roteador e Vuex oficiais também seguem a filosofia de dependências baixas. O próprio Vue não depende de nenhum pacote, o React depende de alguns. Eles têm abordagens diferentes a esse respeito.

Outro exemplo é que as pessoas tendem a usar um pacote de integração entre, digamos, Bootstrap e React, ou usam bibliotecas como componentes estilizados, nomes de classe etc. Com o Vue geralmente não é necessário, embora tais projetos também existam. Acho o Vue muito mais fácil de trabalhar, pois posso ter CSS com escopo de componente pronto para uso, sem bibliotecas ou configurações adicionais, e posso escrever minhas próprias integrações simples com frameworks CSS conforme necessário, em vez de importar uma biblioteca de integração inteira e depois tentar a árvore - sacudindo os 75% que não preciso.

@PericlesSouza, você perdeu alguns itens bastante relevantes de sua postagem 'Pros of Vue':

Slots nomeados para permitir componentes de modelo reutilizáveis, como formulários, entradas, layouts, etc, que são mais flexíveis do que o uso de filhos do Reacts.

Componentes condicionais com a capacidade opcional de manter o estado local ativo sem destruir o componente não ativo.

O elemento HTML 'É' uma sintaxe do componente Vue para modelos de string, que evita a elevação de elementos HTML renderizados que resultam em HTML inválido.

Fluxo de dados unilateral com adereços, mas com a adição de um fluxo muito simplificado de 'emitir' e 'barramento de eventos' para notificar ou atualizar irmão ou pai. Isso pode ser útil para a intercomunicação entre:

Várias instâncias do Vue em uma página, controlando regiões específicas. Essa técnica é útil para painéis dinâmicos ou widgets conectáveis ​​e gerenciamento de memória.

Componente global e local e registro de diretiva personalizada.

Filtros encadeados, além de propriedades calculadas.

Todos os itens acima fazem parte da biblioteca central do Vue.

O React é um ótimo framework e eu gosto de usá-lo, mas pessoalmente acho que o Vue é mais adequado para este caso de uso proposto.

@mcquiggd

Sim, estava com pressa e não tive tempo de fazer uma lista completa das vantagens do Vue.

É interessante que você mencionou que o React tem dependências, pois percebi que ele depende de fbjs . Eu adicionei alguma ênfase às partes que devem disparar sinais de alarme se as pessoas estiverem considerando o React, com a estratégia de licenciamento de dois níveis do Facebook, enquanto compartilho código entre projetos licenciados de maneiras diferentes. Dica tudo sobre ele é preocupante principalmente quando você vê a lista de projetos que dependem dele, mas têm licenças diferentes.

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

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

Objetivo

Para tornar mais fácil para o Facebook compartilhar e consumir nosso próprio JavaScript.

Nota: _Se você está consumindo o código aqui e também não é um projeto do Facebook, esteja preparado para momentos difíceis_. _Esta biblioteca está sendo publicada com nossos casos de uso em mente e não se destina necessariamente ao consumo do público em geral. Provavelmente, não aceitaremos suas solicitações de recursos, a menos que estejam alinhadas com nossas necessidades.

571 Problemas em aberto (!)

Agora é 338. (Passei alguns dias limpando-os.)

Durante os últimos meses, a equipe do React esteve ocupada preparando uma nova versão do React 16 compatível com as versões anteriores. Foi nosso maior lançamento de todos os tempos, então não fomos uma resposta no rastreador de problemas, então sinto muito por isso. Acontece que o React 16 também resolveu muitos desses problemas. :-)

Quero salientar que a maioria dos 338 problemas restantes são solicitações de recursos e discussões. Uma pesquisa pelo rótulo do bug me dá cerca de 60 questões. E, dado que o ecossistema React é maior que o Vue no momento, não é surpresa que as pessoas se deparem com mais casos extremos e inconsistências e comecem mais discussões. Eles também esperam que o React faça o polyfill de mais inconsistências do navegador, então muitos dos bugs estão relacionados à falta de cobertura deles. Além disso, mantemos a documentação no mesmo repositório, portanto, muitos desses problemas são sobre documentos.

Espero que isso lhe dê uma ideia de por que tendemos a ter uma contagem de problemas mais alta do que a de Vue.

É interessante que você mencionou que o React tem dependências, pois percebi que ele depende de fbjs. Eu adicionei alguma ênfase às partes que devem disparar sinais de alarme se as pessoas estiverem considerando o React, com a estratégia de licenciamento de dois níveis do Facebook, enquanto compartilho código entre projetos licenciados de maneiras diferentes. Dica tudo sobre ele é preocupante principalmente quando você vê a lista de projetos que dependem dele, mas têm licenças diferentes.

Infelizmente, este é um FUD sem base, ponto final. Não tenho certeza de qual é a sua motivação para divulgá-lo, mas o React foi relicenciado como MIT, e isso inclui qualquer código do qual o React dependa (como fbjs). Não há nenhum esquema sorrateiro aqui.

Você pode ver por si mesmo que a licença fbjs também foi alterada para MIT em https://github.com/facebook/fbjs/commit/c69904a511b900266935168223063dd8772dfc40 cinco dias antes de seu comentário. A versão React 16 lançada há alguns dias não contém um único byte não-MIT.

O fato de que outros projetos dependem de fbjs mas têm uma licença diferente, é completamente irrelevante, assim como é irrelevante que o código do seu aplicativo provavelmente não seja MIT, mas dependa do Vue.

PS Acho que Vue é ótimo e não quero empurrar o React para ninguém. Mas quero ter certeza de que basearemos essa discussão em fatos. :-) Estamos sempre abertos a críticas e tenho certeza que tanto o Vue quanto o React têm coisas a aprender um com o outro.

Tudo isso é conversa emocionante.

Eu tenho que perguntar - por que uma estrutura / biblioteca afinal? Conforme mencionado anteriormente, o padrão do Web Component parece fornecer o que ReactJS, Vue e outros foram desenvolvidos para fornecer (já que o padrão não existia).

Você pode usar bibliotecas de estado como Redux muito bem com componentes da web. Semelhante às bibliotecas de roteamento. O SSR não é tão desenvolvido com Web Components, no entanto, há pessoas trabalhando lá também. Parcialmente, o maior valor do React são as várias bibliotecas de suporte ao seu redor - que não são necessariamente perdidas com o uso da plataforma.

O que o framework XXX oferece sobre componentes da Web de plataforma?

Conversa empolgante mesmo ...

O quarto licenciamento do React, até agora.

1. Originalmente Apache 2.0. Deveria estar bem, certo? Qual era o problema?
2. Então BSD + Patentes. Sem revelar o que as patentes existem ou não existem.
3. Em seguida, ligeiras alterações, supostamente para agradar ao Google. Sem quaisquer detalhes sobre o porquê.
4. Agora MIT, com refatoração não especificada do React, mas não para projetos diretamente relacionados, como React Native, GraphQL, etc ... e a dependência compartilhada com a descrição pública "Para tornar mais fácil para o Facebook compartilhar e consumir nosso próprio JavaScript. Basicamente, isso nos permitirá enviar o código sem nos preocupar muito com onde ele está "

Aparentemente, não há nada com que se preocupar.

[editar removido por Tammie Lister: textos explicativos pessoais como este são inaceitáveis]

@PericlesSouza Você pode argumentar que não devemos ser confiáveis ​​porque as licenças eram confusas antes. Isso é válido se for o seu argumento. Mas as licenças não devem ser confusas agora.

React é MIT.
Sua dependência fbjs é MIT.
O código que o React e o React Native compartilham (que esteve e continua a estar no repositório React) é o MIT.
O React, incluindo todas as suas dependências, é o MIT.
Não é necessário criar o aplicativo React para usar o React, mas ele também é um MIT.
Relay e graphql-js não são necessários para usar o React, mas também são MIT.

Lançamos o React 16.0 com a nova licença. É fácil verificar isso.
Também lançamos uma nova versão do React 15.x com a licença MIT como 15.6.2.
Estamos planejando lançar todas as versões futuras do React sob a licença do MIT também.

Além disso, outro funcionário do Facebook neste tópico admitiu que React (MIT para 16? Para <16? 17+? Melhor observar esse package.json com cuidado) e React Native compartilhar código, que exigiu refatoração (então edita seu comentário para remover essa afirmação, depois de citá-la).

Eu sou esse engenheiro. (Dela.)

Você comentou https://github.com/WordPress/gutenberg/issues/2733#issuecomment -331737418, então eu respondi https://github.com/WordPress/gutenberg/issues/2733#issuecomment -331738521.

Aqui está o conteúdo original de nossos dois comentários, conforme registrado em meu cliente de e-mail:

Aqui está o conteúdo certo neste momento:

Depois que fiz meu comentário, você editou seu comentário para ficar muito mais longo, incluindo a pergunta adicional:

Quais partes estão sendo removidas para permitir que o React seja publicado no MIT?

que não estava em seu comentário original. Então, em resposta à sua edição, editei meu comentário para adicionar:

Não estamos removendo peças do React. A única dependência não pertencente ao FB do React que conheço é a atribuição de objeto, que também está sob o MIT.

O que você então achou apropriado chamar-me no seguinte comentário. Como ouso editar meu comentário para responder a uma pergunta que você adicionou em sua edição. Eu não removi ou editei qualquer reclamação sobre o código de compartilhamento React e React Native.

-

Por favor, pare de me iluminar. É exaustivo.

@youknowriad Você poderia fazer a gentileza de bloquear este tópico? Não consigo imaginar nenhuma discussão mais produtiva acontecendo aqui.

Se mais alguém aqui ainda estiver legitimamente preocupado com a licença, sinta-se à vontade para me enviar uma mensagem DM e farei o possível para esclarecer.

O que você então achou apropriado chamar-me no seguinte comentário. Como ouso editar meu comentário para responder a uma pergunta que você adicionou em sua edição. Eu não removi ou editei qualquer reclamação sobre o código de compartilhamento React e React Native.

Obviamente respondi à sua edição, esse é o seu problema?

Não há necessidade de iluminação a gás, simplesmente abertura e consistência do Facebook, da equipe de desenvolvimento do React e licenciamento, e como os quatro modelos de licenciamento no Reacts indicam, o tempo de vida relativamente curto e sua postagem (atual), infelizmente isso está faltando.

Resumidamente, deixando de lado o licenciamento: Novamente, o que o React oferece hoje que é obtido acima e além dos componentes da Web? Assumindo que você ainda usará uma seleção de bibliotecas de suporte em ambos (ou seja, Redux).

Com os componentes da Web, o WordPress pode criar muitos elementos que podem ser usados ​​em várias bibliotecas / frameworks front-end. Isso permitiria que os usuários finais com React, Vue, Angular ou qualquer front end que estivessem usando "instalassem" componentes do WordPress.

@sophiebits Não tenho certeza de qual versão de sua postagem responder agora, então vou esperar e ver no que ela finalmente se tornará. É realmente uma situação semelhante à do React.

@ Brian-McBride

Você fez um bom ponto e acredito que foi levantado anteriormente no tópico - "por que não usar vanilla javascript", baseado em padrões, totalmente compatível.

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 eu disse pessoal, tenham muito cuidado com o controle de versão se estiverem usando o React.

Sim, nós acidentalmente confirmamos três arquivos com o cabeçalho errado, de solicitações pull que foram abertas antes da mudança de licença. Nenhum estava em uma versão lançada (nem poderia ser - um eram testes de unidade, dois faziam parte do site).

Erros acontecem. Corrigimos quando descobrimos e adicionei um script ao nosso IC para verificar no futuro se não há mais referências acidentais sendo adicionadas. Você pode ver isso nesse commit.

Uma coisa adicional que eu acho que os projetos de software livre devem considerar - o Facebook se beneficia do uso do React.

Mas os valores do Facebook geralmente não se alinham com os do movimento do software livre - tudo, desde manipulação antiética de usuários a ataques à neutralidade da rede ("Free Basics"), incapacidade de deletar dados, incapacidade de bloquear a coleta de dados, censura, jardim murado , câmaras de eco e muito mais.

[Facebook] é como quando meu irmão costumava me fazer me dar um soco e perguntar: "Por que você está se socando?" Então ele diria a minha mãe que não foi culpa dele.

Ao assistir o Facebook por muitos anos, estou cada vez mais perto da conclusão de que não quero mais apoiar essa empresa de forma alguma, então, pessoalmente, não uso o software FB sempre que houver alternativas.

Eu li um livro sobre React e parece ótimo do ponto de vista da programação - mas as alternativas também são ótimas e não vêm com a bagagem de apoiar o Facebook.

Acho que os projetos de software livre devem sempre preferir bibliotecas de software livre independentes, sempre que estiverem disponíveis. Existem muitas alternativas excelentes para o WordPress, incluindo Vue, componentes da web, Ember e Mithril. O Vue tem um grande suporte na comunidade PHP e não tem nenhum problema ético associado a ele, então parece que se encaixaria bem. Se for apenas para o painel, pode valer a pena dar uma olhada em algo ainda mais interessante do que JavaScript: Elm .

Não deve ser sobre o que está na moda ou legal no momento, mas deve ser sobre o que fornece mais liberdade de tecnologia para as próximas gerações - direta ou indiretamente.

Apenas outro pensamento a considerar ...

Obrigado a todos que expressaram suas opiniões enquanto tentavam ter uma conversa respeitosa. Eu também gostaria de adicionar um agradecimento especial a @sophiebits , @gaearon , @blake-newman e a todos os outros representantes de projetos que gentilmente gastaram seu tempo respondendo perguntas. Seu conhecimento é muito apreciado e sempre bem-vindo.

Desde então, a conversa mudou para as reuniões de JavaScript no canal # core-js do Slack. Há um bom resumo aqui . Se você estiver interessado em participar dessas discussões, nós o convidamos a se juntar a nós. Como alternativa, temos duas abordagens para interoperabilidade que podem usar contribuições, testes e feedback: # 2463 e # 2791.

E com isso, este tópico seguiu seu curso. Estamos bloqueando o problema, mas encorajamos você a continuar a conversa nos locais mencionados acima.

Este tópico gerou uma boa discussão, mas algumas delas mostraram um comportamento inaceitável e foram editadas. É importante lembrar que https://wordpress.org/about/etiquette/ se aplica a qualquer projeto WordPress e não toleraremos violações ou aqueles que as cometam. Obrigado a todos, que contribuíram para a conversa de forma atenciosa e respeitosa.