Gutenberg: 为古腾堡（〜WordPress）选择JavaScript框架

我的投票是通过VueJS进行的

我选择VueJS

Vue拥有一个强大的社区，应该成为前进的选择。

角JS

我将投票支持VueJS。 如上所述，它是初学者友好的工具，已成功与Laravel结合使用。 这使其成为理想的选择。

我也会投票给Vue JS

请注意，仅喊“我更喜欢Vue”或“我想要XY”并不能真正帮助您做出任何决策。 如果您想投票，我建议您使用表情符号反应或类似的方法，而不是在评估不同框架时避免出现可能会成为记录发现结果的地方。

我会选择Vue。 它更容易学习和适应。 另外，它没有Preact引起争议。

对于不时出现的“关键人物依赖”问题，这不是每个WordPress功能插件或未知技术都是什么吗？ 库普（Koop）建立了旧的媒体处理方式，韦斯顿（Weston）做了大量的Customizer工作，马蒂亚斯（Matías）和其他一些人正在研究古腾堡（Gutenberg），在过去几年中对WordPress所做的每一个重大变化几乎都由一小部分人来进行或了解它。

我可能会以错误的方式看待这个问题，但是任何选择的“关键人物依赖性”似乎都是一条红鲱鱼。 随着采用，关键人员的依赖性被完全消除。 WordPress曾经也是关键人物（迈克和马特）的依赖项目。 我认为这是避免采用的一个弱论据。

再说一次，我可能会想到这完全是错误的，但这是我不时弹出的一个共同思路，并且不理解它的表面重要性。

要添加到@swissspidy的注释中，先显示而不是告诉也可以有所帮助。 如果人们强烈希望进行替换，请演示更改以及分支中代码的外观（就像＃2734为Preact所做的一样）。 无论最终决定是什么，古腾堡都将通过探索而不是混乱的讨论主题来做得更好。

我会投票支持VueJS！ 到目前为止，这是社区最容易适应的。

我认为应该认真考虑Web组件（没有Polymer，但是如果需要虚拟DOM，则带有lit-html或类似内容）。 使用平台和标准比任何库或框架都要好！ 建立了一个健壮且未来安全的组件结构，该结构自然可以与所有框架互操作。 （Vue，Angular，React-当前程度不同：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

如果需要，我很乐意帮助该项目试用Vue或Web组件。

另请检查PR＃2463中的古腾堡_“与框架无关的块互操作性（Vanilla，Vue）” _

由于一些原因，我建议您倾向于Vue.js。

1. 在PHP框架Laravel中的可靠记录。
2. 似乎很容易被接受和采用，因此更多的人可以做出贡献。
3. 如果我们要远离React，那就让它清晰明确地偏离它（使用Preact似乎在某种意义上就是紧紧抓住了它（React））。

只是我的意见，但这似乎是更好的选择，并且许多其他人似乎都喜欢Vue，而且无论如何至少要考虑一下。

Vue似乎比Preact拥有更大的动力和更好的社区支持。 它解决了更多的问题（因为它带有状态管理功能），并且学习曲线更柔和。 该文档是_excellent_。

我对Preact的担心是，React感觉在法律上是安全的（React的专利可能涵盖Preact），并且与React也不一样，它是一个简单的端口（存在_enough_差异以破坏帮助程序库，插件等）。

Vue一路宝贝！

• [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星->这里
如果Vue.js对WordPress开发人员来说绝对是激动的

随着时间的流逝，Vue建立了一个强大的社区，并定期对框架进行更新/升级。

PS。 加入https://chat.vuejs.org以获得很棒的社区体验..一些真正的dopeass开发人员:)

@jbreckmckye我不是要破坏对话，但是您了解专利条款的含义吗？ 这是关于保护facebook免受其他公司的专利诉讼。 例如，假设我的公司生产智能冰箱，而我们在UI中使用react。 假设我们对此拥有一项专利，然后FB开始侵犯该专利...如果我们起诉我们不能再使用react。

它与专利中的反应无关（我什至不确定Facebook是否具有...否则，事实，特质以及其他拥有类似框架的人现在都将受到起诉）。

作为Vue.js的核心成员，我想解决总线因素问题。 我们知道这是目前提出的一个非常重要的问题，我们现在正在采取措施解决一些问题。

1）npm的Vue.js组织帐户，因此我们可以更轻松地以团队形式发布
2）内部管理详细信息以保持运行（网站等）
3）建立一个开放的集体，以吸引贡献者并支持不断发展的社区。 https://medium.com/the-vue-point/vue-is-now-on-opencollective-1ef89ca1334b
4）Vue生态系统迅速发展，越来越多的核心资源库贡献来自社区本身。 https://www.youtube.com/watch?v=993X1kiisFE
5）在查看Vue官方存储库时，您可以发现实际上许多其他核心团队成员现在对它们的维护要比Evan多

总体而言，Vue.js迅速增长，并且“总线系数”已大大减少。 正如@philiparthurmoore指出的那样，Evan将始终参与其中，这是一件好事。

这里似乎有很多VueJS粉丝。 有人真的将大型代码库从React迁移到Vue吗？ 迁移路径如何？

从我可以看到的角度来看，Preact似乎是一个更为实用的选择，因为它与React兼容。 而迁移到Vue将需要更广泛的重写。

@patrickgalbraith这实际上是考虑使用Preact的错误原因。 应该从它的优点来判断它，而不是因为它更容易迁移到它。 我可以看到Preact的以下问题

• 与VueJS相比，社区规模较小
• 代码闻起来-过渡到非常相似的库可能会导致不良做法（显然是因为它是更快的路径）
• 坚持使用Preact就像仍然坚持使用React（在线程中阅读）

我仅以有限的方式使用Preact，所以这就是我的想法。

@ blake-newman感谢您删除并清除它。 💯

应该从它的优点来判断它，而不是因为它更容易迁移到它。

对。 这是一个长期的决定。

@patrickgalbraith如果整个项目

由于该项目仍处于早期阶段，就像@ahmadawais一样，这不是问题。

Vue，React和Preact也具有非常相似的范例。 您可以轻松地在两者之间切换，会有差异。

尽管在这种情况下可能还不完全实用，但也有一些工具可以帮助移民和平。 https://github.com/SmallComfort/react-vue

尽管这不是比较相同的工具，但是本文提出了很多要考虑的问题。 https://medium.com/unicorn-supplies/angular-vs-react-vs-vue-a-2017-comparison-c5c52d620176

@ blake-newman是否真的只是早期阶段，尽管考虑到它已经开发了6个月以上？ 另外请记住，Calypso也已经有两年以上的历史了。

无论如何，鉴于您所说的在React和Vue之间切换很容易，我确信这将不是问题，我很期待看到它的请求请求。

模具看起来也很有希望。

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

我的观点是，这两点为Vue提供了强有力的证明：

• 初学者友好和..
• 大量的社区支持

在我看来，两者都是WordPress项目的两个核心支柱。

我也许很孤单，但在过去六个月左右的时间里，我一直在密切关注埃文的《 Patreon》，而且它读到，如果他无法从中获得资金，他将需要做更多的工作。

当一个项目的资金很少并且基本上由一个人撰写时（截至六个月前），这是一个真正的风险。 实际上，他的Patreon人数最近有所下降。 如果主要负责人说，如果财务状况不佳，他可能将无法继续工作，那么财务状况将是非常现实的风险。 一个大型的长期项目的框架选择取决于一个（出色的）开发人员是否可以支付SF租金，这很重要。

当然，Vue可以得到其他公司的慷慨支持，但很难知道。

伙计们，采用社区也不能保证框架的使用寿命。 如果您没有注意到，框架始终会“消亡”。

就是说，令我印象深刻的是，核心Vue团队的一名成员出席了会议，实际上是解决了唯一的贡献者问题/总线因素，甚至还用名字来表达了这一点，并给出了一些原因，即单个开发者问题可能没那么大问题。 但这是最近的一个实际问题。

我投票支持Vue

• 简单的api /您可以在一周内学习最基本的知识
• 通过vuex实现简单的流量
• 快速结果：P
• 成长中的社区
• 麻省理工学院

由于上述所有原因，Vue再次投票。 我向任何已激活邮件通知的人致歉！

@ michaelbdavidson7 ，Vue最终将得到Evan的支持，Patreon竞选活动是为了支持他做更多的Vue工作。 他没有通过Patreon获得足够的收入，无法从事其他我认为不会危及Vue的工作。 正如@ blake-newman（Vue的主要贡献者）所建议的（几个月前和Evan本人一样），Vue不再仅依赖一个人。 WordPress不仅不依赖一个人。 我们有Matt，是的，但是WordPress可以在没有Matt的情况下继续发展（对不起Matt;））。 Vue也是如此（对不起Evan;））。
我也觉得@ahmadawais关于“关键人物依赖”并不准确。

如果实现了这个目标，我可以花更少的时间思考私人获利渠道（例如签订支持/咨询合同），而可以在使整个Vue社区受益的内容上投入更多工作...

^这个目标没有实现，甚至没有实现。 假设他的意思是他说的话，他可能仍在考虑签约，如果改变了，则应视为最近的发展。 到目前为止，它仍然在那里。 如果关键人物签约支付租金，则有风险，他可能不会继续研究该框架，并且如果这种情况发生了变化，那么它就在最近发生了变化。

在过去的几年中，大家大喊大叫的框架对他们一无所知。

@ michaelbdavidson7实现了支持Evan全职工作的目标。 另一个目标是帮助他进一步和部分地支持社区。 因此，公开集体运动的诞生，其目的仅仅是为了支持社区。

我还要指出，Patreon运动并不是通过捐款获得收入的唯一来源，不幸的是Patreon并不适合所有公司赞助。 因此，一些会费是分开支付和开具发票的。

人数减少的原因是，其中一个赞助商来自中国，并且一年中可以从中国支出的资金数量受到限制。 这只是暂时的，希望会得到支持。

埃文（Evan）通过参加研讨会获得的其他收入渠道，不仅对社区有所帮助，而且对他也有帮助。 这样，他就可以直接接触以支持学习图书馆的用途和用途。 因此，它实际上并不像看起来那样糟糕。

Vue具有可持续性，我不代表埃文发言，但我确信他对当前的财务状况感到非常满意。

我对React确实很感激的一件事是它的可访问性文档。 我认为这是在考虑新框架时要意识到的事情。 这里提到的可访问性原则适用于任何防御性编写的Web应用程序，但是拥有一些特定于框架的文档可能会有所帮助。

Vue.js的可访问性有一个

最终，拥有一个框架可以使自动测试变得简单而自动，这样我们就可以消除大多数的错误和警告，这将是很棒的。

如果仅由于许可证就希望轻松过渡，那么您可以考虑选择InfernoJS。 https://github.com/infernojs/inferno，它提供了几乎相同的API，占地面积更小，运行速度更快。 其MIT许可。 我是inferno的维护者之一，可以为过渡做贡献。

@Havunen感谢您的

就上下文而言，Inferno的作者已被Facebook聘用。

我投票支持markoJS http://markojs.com/

古腾堡使用了一些新的React 16功能，即Portals和可能的Fragments ，Inferno和Preact均不支持，因此在讨论类似React的库时，如果这些功能的使用对于gutenberg至关重要，则可以考虑在内。

我建议使用DIO 8，主要是因为就API而言，它是目前与React 16最接近的东西。

也就是说，设置古腾堡别名作为提到的类似React的库，并查看它们是否在没有任何更改/问题的情况下为任何愿意的人工作，可能是一个很好的好奇实验。

我不确定它们是否完全相同，但是对于门户网站，有一个由@LinusBorg开发的vue-portal ，这是vue核心团队成员之一：）

@youknowriad我被Facebook录用了。 @Havunen和Inferno背后的团队在没有我的情况下做得很好。 他们在Inferno上所做的工作非常出色，如果有机会，该项目值得Inferno进行检查:)

我是Marko.js的作者之一，并希望将Marko.js纳入考虑范围。 我们的许多社区成员都与我们联系，并向我们指出了这个GitHub问题。 Marko.js拥有开放源代码的MIT许可证，并且正在用于构建eBay.com，并且社区数量不断增长。 它带来了来自React和Vue的许多好主意，但是我们付出了很多努力来使事情变得更简单，更快（通过编译时优化），并且我们尽可能地删除了样板。 我只想强调以下一些功能：

UI组件

Marko的组件模型在概念上与React的模型非常相似（输入，状态，事件绑定，生命周期事件，虚拟DOM渲染，DOM差异/修补等）。 Calypso的过渡不需要太多的认知开销。 Marko还支持单文件UI组件。 这是Marko UI组件的外观：

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>

句法

Marko不使用JSX，而是支持JS表达式的HTML的超集。 它与HTML非常相似，但不像Vue那样完全限于HTML。 这为诸如循环和条件之类的事情提供了更好的语法，并使与标准HTML字符串相比更清楚地在何处使用表达式。 我们觉得Marko.js模板具有很高的可读性和可维护性（Marko还支持简洁的，基于缩进的语法）。

服务器端渲染

我不知道它对WordPress有多么重要，但是Marko还支持Node.js下的高性能服务器端渲染，并支持异步和流渲染。

进一步阅读：

• Marko vs React
• 使用Marko，Preact，Rax，React和Vue进行服务器端渲染枪战
• 为什么Marko快？
• 10个很棒的Marko功能
• 聚会：构建UI-对React，Vue和Marko的比较（来自Marko创建者）-视频| 滑梯

我投票支持Marko ！！ 🙂

如果WordPress小组的任何人（@ahmadawais？@m？@swissspidy？）想快速聊天以回答有关Marko的任何问题，我们Marko小组将很乐意这样做。 ：call_me_hand：😸

@我在@m的博客上对此进行了评论，但想以更公开的形式在此处发布：

我建议使用Ember生态系统，包括Ember和Glimmer.js。
对于较小的Web组件（例如放置编辑器和其他内容行为），Glimmer提供了很好的体验，并创建了可以在框架外部运行的Web组件。

对于像Guttenberg和Calypso这样的大型项目，其中包含路由，复杂的状态管理，访问控制，内容管理等功能：Ember提供了最佳的工具集和生态系统
贡献者众多：Ember的设置模式，附加组件和构建系统有助于在应用程序扩展时保持应用程序的性能和可维护性。
Ember Engine和回购插件有助于使应用程序的可选部分保持模块化，并可以安装给最终用户。

Ember被其他内容管理系统大量使用，并且可以基于，学习和共享努力。
正如@m博客先前的评论中所述， Ghost使用Ember作为其管理员和编辑器，但Ember也与Drupal headless， Cardstack和内容公司（例如Conde Nast ， Bustle等）一起使用。
这意味着Ember Addon生态系统中可以使用诸如标签列表，基于组件的编辑器（特别是Mobiledoc编辑器）等常用功能。

从社区和开发人员的经验来看，Ember最适合Wordpress生态系统（作为在Wordpress中工作超过5年的开发人员）。
Ember具有许多最佳实践，它们是内置的，有据可查的或可以通过附加组件获得的； 这减少了“可以在我的应用程序中使用”的问题，并有助于更好地减少可能的安全性或性能错误。
Ember建立在可自定义的抽象之上，这意味着可以从最终开发人员中提取复杂性，并且可以限制困难的代码的范围，以使自定义变得轻松有趣。
Ember插件会自动发现并具有默认配置，因此它们与Wordpress插件和主题非常匹配，但可以进一步定制以满足最终用户的需求。
现有一个名为Ember Observer的Ember Addons策展工具，可帮助您找到最受欢迎，维护最好和最稳定的插件。

Calypso和Guttenberg是具有成熟需求的大型宏伟项目。 Ember社区对于可访问性，国际化和现代Web应用程序的其他要求具有成熟的解决方案。

我是Ember.js学习团队的一员，并且与核心贡献者紧密合作。我很想与其他Ember团队成员讨论或建立对话，以探讨Ember和Glimmer如何满足您的需求。

我注意到有人提到React门户，并想再说2美分，Ember拥有一个维护良好的插件，称为Ember Wormhole以提供此功能，并且在此基础上构建了许多插件以提供诸如对话框，文档头更改之类的功能。 ， 和更多。

我为Marko投票，因为它具有本机异步渲染支持和快速服务器端性能。

@ patrick-steele-idem和@ mlrawlings-感谢您的

我会继续研究。

我曾在一个大型企业组织（其中应用程序在其他应用程序中运行）和一个非常小的小型独立应用程序启动公司中使用过Ember.js。 随着团队和应用程序的发展，Ember.js的强烈见解和约定有助于保持高效且可维护的代码库。 它不仅能够跨项目共享代码（通过引擎或附加组件），而且还使学习过这些约定的开发人员能够高效地工作并为几乎所有Ember应用程序做出贡献。

灰烬的最大好处是它的稳定性而不会停滞。 无需更改任何模板，发布新版本的Ember完全重构了我们的渲染引擎后，我们获得了巨大的性能优势。 对于可能会增长并且需要扩展到遥远未来的现代富Web应用程序来说，抽象级别似乎恰到好处。

当需要进行更改时，迁移是一个核心问题，弃用指南可帮助您完成每一个步骤（最近使用JavaScript AST / CST转换来自动升级应用程序）。

@rtablada未提及的其他使用Ember的流行Web应用程序包括Twitch.tv ， Heroku仪表板， Travis CI和Discourse 。

@SaladFork感谢您的更新，我首先在内容管理领域命名了大多数公司。

大型开源Ember应用程序的一些示例包括：

• 特拉维斯CI
• 医院运行-专为离线使用而构建的EMR（电子病历）系统，特别是在非洲低连接性的情况下
• 鬼

我不确定他能透露多少细节，但我正在ping

我为Marko的性能，灵活性以及非常清晰，易于理解的语法而投票！

同样，Marko +1。 在我开始脱发和变老之前（例如，很久以前），已经做好了前端工作，这一直是我多年来一直在寻找的前端框架/库。 这也是我也喜欢与@ patrick-steele-idem和@mlrawlings一起在eBay工作的一个重要原因。

我是Marko JS。 考虑到它的易用性和性能，它被大大低估了。

我喜欢marko-widget和高效的marko。 简单出色的精益框架。 它的方式比其他框架更快。 基准在这里

我投票支持MarkoJS，多年来我们一直是车把店。

当我们采取战略性行动进入微服务并为我们的平台启用基于组件的体系结构时，我们正在寻找合适的框架以兼顾服务器端渲染和客户端渲染。 我们是一个已在6个不同市场进行分类的平台，其中包括南非和墨西哥等新兴市场，在这些市场中，数据是一个令人关注的大问题，我们需要拥有一个能够真正满足用户对使用了几年并且还在使用的设备上的浏览要求的网站较少的数据。 另外，用户将来回导航该站点，直到找到喜欢的商品为止，这意味着我们需要在用户导航时进行非常快速的服务器渲染。

经过仔细考虑，我们选择了MarkoJS并支持以下事实：

1. 具有良好服务器性能的快速服务器渲染
2. 尽快推出第一个字节
3. 能够构建次要组件并在数据准备就绪时异步呈现它们
4. 能够构建即插即用的组件架构
5. 使用React / Vue中相同或更好的架构最大化客户端渲染。
6. 组件驱动的测试不仅可以用于测试渲染，还可以用于组件的状态

（来自eBay分类广告的成功案例）

+1表示Angular（NOT AngularJS）。

到目前为止，Angular CLI是所有框架中最好的，并且已准备好用于在版本之间进行无缝迁移的迁移计划。

加上Angular在企业领域得到了很好的采用，如果WordPress将继续作为顾问和自由职业者的平台发展，而不再只是底下的竞赛，那么WordPress可能会有些爱。

它拥有一个强大的各个级别的开发人员社区。 核心团队总是很乐意谈论他们是否为Google工作。 WordPress在很大程度上（对于大多数高级开发人员而言）是他们所参与的社区，所以我会说在社区方面，Angular非常适合

我最近在服务器渲染环境中做了有关Vue的演讲（幻灯片），并且过去几个月在.NET环境中使用Vue工作，我坚信在该环境中没有其他选择。像那样。 您获得了一个非常出色的组合，它能够将需要拉入JS的内容进行组件化以实现高交互性，同时允许后端继续主要控制站点。

这意味着它非常适合在WordPress现在的基础上构建。 任何其他服务器呈现的JS库都很可能需要require节点。 Vue不会； 您可以注册<gutenberg-editor>类的组件，并让WordPress在HTML中直接发送<gutenberg-editor> 。 Vue可以使用WordPress发送的HTML引导页面。 在这方面，它有点像Web组件，并且不需要其他BE技术即可获得服务器渲染。

这是Laravel之类的框架选择它作为默认框架的原因之一：它非常容易集成到非Node后端。 我认为WordPress应该出于同样的原因采用它。

我投票支持Vuejs 。
@borantula在他的评论中也是如此

我的CTO向团队介绍了Vuejs-前端的新手，他们很快就加入了，现在他们对Vuejs感到满意。 我的团队在许多项目中都使用WordPress。
当前，我们正在使用Vuejs和Custom Element制作一个在后端使用WordPress的项目的前端。 它工作非常顺利。

正如@ blake-newman和Evan所说，Vuejs不再依赖单个关键人物，因此可以说@ahmadawais提到的CONS不再存在。

MARKO在我们的Web应用程序中运行良好。 渐进式渲染的工作原理就像一种魅力。

我不能说任何关于Preact或MarkoJS的信息（在评论中经常提及），但是在一年前我向我们的团队介绍Vue时（我当时主要从事php + jQuery的工作），我可以谈谈Vue，并且逐渐改变了他们对javascript的理解，摆脱jQuery的思想状态。

我认为，这不仅对于古腾堡（Gutenberg）也是一个不错的选择，对于WordPress的长期目标来说，过渡到具有更多Javascript接口的面向API的平台是一个不错的选择。 更容易的学习曲线和熟悉度也会鼓励其他WP开发人员也介入。

我看到VueJS如何在Laravel社区中蓬勃发展，并且几乎成为大多数人的事实上的选择，我相信在WordPress社区中也是如此。

Backbone.js

/秒

我想将我的支持抛给MarkoJS。

两年前，我将公司的基础架构从ExpressJS和Jade（现为PUG）迁移到了Marko JS。 我的公司希望在整个生态系统中创建复杂且可重复使用的组件。 开发人员想要速度和可重用性。 设计师希望减轻设计负担。 从那以后我们再也没有回头。

现在，我们有多个使用Marko编写的面向客户的网站以及整个CMS系统。

最终，我为以下项目选择了MarkoJS：

• 即使使用Koa和ExpressJS之类的框架，也可以进行快速的服务器渲染
• 处理页面数据的异步呈现
• 能够为更大的生态系统构建即插即用组件
• 比React / Vue更好的性能
• 极其简单的模板语法

我还要指出的是，MarkoJS团队的确名副其实。 @ patrick-steele-idem和@mlrawlings一直致力于提出新的想法，解决问题并帮助个人。

Mark对于MarkoJS

Preact是与React-API兼容的库，这意味着Preact直接受益于React的生态系统和大量可用的OSS软件包/组件。 相比之下，Vue的生态系统要小得多。 第三方Vue软件包/组件的文档为中文。

拜托，别再“我投票给XYZ”，除了向订阅此问题的人发送不必要的回复外，他们什么也没添加

🔥角度

• 专业人士： React的最大竞争对手
  对许多人来说。 问题通常是“ Angular还是React？” /“反应还是角度？”。 Angular社区可以说是React替代方案中规模最大的社区，并且正在迅速发展。

• PRO：很多学习资源
  除了官方的API文档和指南之外，Angular可能拥有最大的生态系统的教学材料，博客文章，书籍以及许多视频课程，包括在每个主要学习平台上的免费和商业视频课程，以及在工作坊和会议上进行教学的Google GDE。

• PRO：与Redux很好地集成
  直接或通过RxJS授权的Ngrx（由Angular团队成员支持）

• PRO：一流的工具支持

  • CLI具有比其他方式更多的功能

  • VS Code中非常好的编辑器支持，尤其是在语言服务中

  • 专为TypeScript编写，可提供最佳的TypeScript体验

• 专业版：功能丰富，自觉且默认情况下井井有条
  通过Angular Modules（NgModule）进行逻辑分隔，以及表单，HTTP调用，路由等标准功能，其他开发人员可以更轻松地阅读代码并做出贡献

• PRO：与RxJS的最佳集成
  通常可用于一页中的许多API流和许多事件流

• PRO：内置DI（依赖注入）系统
  对于创建扩展点甚至是插件系统很有用，尤其是与RxJS结合使用时

• 专家：勾引其他图书馆介绍的许多其他箱子

  • 具有许可许可证的UI库
    有PrimeNg，Angular Material 2，ngx-bootstrap等等。

  • 延迟加载
    内置对延迟加载路径的支持，并手动支持延迟加载模块

  • 特定于组件的CSS
    确保CSS仅作用域为组件，仅当组件加载时才加载，并且具有全局CSS的钩子

  • 服务器端渲染
    已经在使用Node和ASP .NET Core，并且现在越来越集中精力

  • 测试中
    Angular提供了与单元测试框架无关的测试助手，从而使单元测试变得非常容易。 他们默认使用Jasmine从CLI生成测试，可以轻松切换到Jest。 他们还提供了一个可选的Selenium包装量角器，以简化E2E测试（即使您实际上并不需要它，我也将Selenium .NET用于我的Angular应用程序，与Angular无关，但它们试图使它更容易）。

  • 移动/ PWA支持
    Google是PWA的最大支持者，该支持已在Angular CLI中得到了支持，其中包括Service Workers和Universal（服务器端支持），Ionic（Cordova支持）和NativeScript（本地应用程序）

• PRO：专注于浏览器支持
  在文档中有专用的polyfill页面，并且默认情况下在CLI中插入了（注释的）polyfill，Angular使您始终了解IE <= 11所需的确切polyfill，因此您无需加载更大的polyfill设置没有理由。 那是因为他们关心浏览器的支持。

• PRO：大公司的支持
  Angular是这里讨论的少数几个由大公司支持的库之一（唯一的一个？）。
  通过这里的支持，不仅是在几个项目中使用过它并为生态系统做出贡献的公司，而且还是官方的维护者，他们支付开发人员和技术作家全职工作的时间，并投资于社区领导者（在这种情况下为GDE和DevRel Google）。
  这不是PRO，不是CON，因为它带有MIT许可证，没有多余的条款，吊销说明或任何其他可能使某些人感到困惑或恐惧的东西。

我已经为某些项目（例如插件，REST API）实现了Vuejs 。 我必须说，它易于学习，具有许多功能，庞大的社区及其生态系统也很好。

如今，Vuejs迅速发展。 如果将Vuejs集成到WordPress代码中，这将是一个明智的选择。

@cyberwani @thephilip @evoratec等。

@ntwb已经回复了以下评论：

拜托，别再“我投票给XYZ”，除了向订阅此问题的人发送不必要的回复外，他们什么也没添加

因此，请停止发表无用的评论。 为了显示您的支持，您可以使用github表情符号来添加喜欢您的库的评论。

Vue。

顺便说一下，现在Vue背后有阿里巴巴，还有在手机上启用Vue api的Weex Apache项目。

我真的要在这里发表一些评论，有太多没有明确论据的粉丝男孩

这是最后的警告，下一步是我们开始删除评论。

我，我自己，我还没有使用过Marko，Preact或Vue.js，说实话，我不熟悉其中的任何一个，我很想听听和阅读WordPress社区对这些框架的看法，每个项目，每个项目的技术优势，每个项目的周围生态系统，构建工具，以及最后但并非最不重要的项目背后的人员和社区。 😄

我不想阅读“我的投票是针对XYZ”的信息，如果您想添加投票，请向上滚动并向上面已经提到的所选框架添加表情符号_thumbs up_反应。 👍

自从我之前的评论之后，很快就出现了两个新评论

为此，...如果您的评论是在https://github.com/WordPress/gutenberg/issues/2733#issuecomment -329705942之后添加的，而您所说的只是_“我为XYZ投了票” _或该文本效果您的评论被删除的几率很高，同一同类的未来评论也将被删除。

如果您要返回此问题并想知道为什么删除您的评论，这就是为什么

@ahmadawais，我有几点评论。

古腾堡从React迁移到...？

关于：

@patrickgalbraith这实际上是考虑使用Preact的错误原因。 应该从它的优点来判断它，而不是因为它更容易迁移到它。 我可以看到Preact的以下问题

• 与VueJS相比，社区规模较小
• 代码闻起来-过渡到非常相似的库可能会导致不良做法（显然是因为它是更快的路径）
• 坚持使用Preact就像仍然坚持使用React（在线程中阅读）

我认为，当您的项目的代码行数很少时，您需要非常小心。 工程师喜欢重写事物，学习新的语言和框架，并认为如果他们可以重写该代码，他们会做得更好。...很久以前，Joel曾雄辩地谈到过重写的危险。
使用Preact将节省大量时间。 您可能低估了迁移到全新框架所需的时间。 我不确定您为什么写“这实际上是考虑使用Preact的错误原因”。 作为一名工程师，在我用来评估和选择解决方案的标准列表中，成本和上市时间都很高。
如果问题确实出在Facebook专利上，那么Preact可以解决该问题，从而将成本降到最低。 与React甚至Vue相比，Preact的性能更高：占地面积更小，运行时渲染更快。 还要检查Addy Osmani的文章。

我不确定您如何评估Preact社区的规模。 如果我们正在谈论生态系统和可用的组件，那么使用Preact可以使您使用React的大多数开源组件。 因此，实际上，您有一些人，即使他们没有明确地使用Preact进行开发，他们仍然在生产可以利用的代码。 您仍然可以将React的生态系统视为Preact的生态系统的一部分。

为什么Vue仍然是您最喜欢的选择？

我觉得这里的第三点“坚持使用Preact就像仍然坚持使用React一样”可能是您犹豫选择Preact的主要原因。 我错了吗？ 除了专利之外，React有什么问题？

放眼大局

我读到，您为古腾堡（Gutenberg）选择的任何物品也将用于卡吕普索（Calypso）。
古腾堡只在前端使用React。 当您查看服务器端渲染时，情况变得更加复杂，但是Preact似乎仍然是一个更容易的迁移选项。

我认为您需要查看您的标准。 如果您正在认真考虑重写并且保持同构渲染很重要，那么MarkoJS似乎在候选列表中

如果我从头开始，并愿意忽略React生态系统，那么MarkoJS毫无疑问。

我正在看表演， MarkoJS似乎没有任何竞争对手。 比React快40倍，比Vue快倍，比Preact快
如果您的成功程度不高，并且可以使用10台服务器代替100台服务器，或者使用2台服务器代替20台服务器，则将有很大的不同。

全面披露我对Preact或MarkoJS没有任何情感依恋。 我只是认为它们比工程前景中的替代方案更有意义。

祝你好运decision

@ChrisCinelli这些是

我来自Drupal世界（我们正在关注这个问题：D），所以我对此一点都不感兴趣。 但是阅读这些评论，很明显，这里大约有5个“顶级”框架，每个人都喜欢他们选择的框架，因此他们会提供支持。

如今，速度方面确实无关紧要。 唯一需要考虑的两个因素是：a）您是否真的要重写所有内容； b）React开发人员的过渡将如何，新开发人员如何学习获胜的软件工程师。

有易兼容的，易兼容的...层，易于转换，但性能会受到影响。 另一方面，随着时间的推移，它将使过渡更加顺畅，而不是必须立即重写所有内容。 从业务POV来看，这毫无疑问。 从社区POV和未来来看，这没有什么区别。

现在DX就是一切所在。 任何具有反应式Fws经验的人都不会因为过渡到相同的概念而只是过渡到语法上就没有问题。 但是新手，那才是最重要的。 要在新的固件中发挥作用有多难/容易。 阅读和理解现有代码有多么困难/容易。 这完全取决于a）良好的文档和b）社区（论坛，SO，聊天室，博客..）。

我不会说我更喜欢哪个FW，因为正如我所说，我不是WP工作人员。 但是我想给我2c一点，以便在影响全球成千上万开发人员的重大决策时保持冷静。

@ntwb：我没有我的评论删除，但我想删除注释，即使是那些风扇的男生，为某种检查制度。

为什么：

如果您的注释是在＃2733（注释）之后添加的，而您所说的只是“我为XYZ投赞成票”或表示您对此注释的文本很有可能被删除，则相同同类的未来注释也将被删除。

在此之上，我看到很多粉丝男孩的评论。 他们为什么留下？
似乎是双重标准。

有角度的，这是一个明确的选择。 我认为Roy和Meligy提出了奇妙的观点，并100％支持它们。 WordPress不仅进入使用领域，而且进入其开发方法的研究领域。

我将链接一个有趣的资源： https :

@ChrisCinelli仅仅因为那是当我们要求人们不要说“我为xyz投赞成票”时，我确实知道您的

我没有提过这个是因为我不想攻击我不推荐的框架（上面推荐了Angular ），但是为了完整起见，Preact和其他类似React的库需要清除一些东西。 我将其放在此处，由WordPress决定是否要考虑。

以下是来自专利/ IP律师关于React许可黑体）：

我已经得到了很多“好吧，那就让我们都使用[这里的替代框架]。” 稍等一下。 如果Facebook专利涵盖React（差异化，组件化等），则这些专利可能涵盖Preact / Vue / et al。

但是React为您提供了专利授权！ 使用替代框架，您从第一天开始就是侵权者。 这一切都取决于Facebook是否拥有专利以及他们想要实施专利的意愿，但是如果您想将专利打到第n级，

现在，如果我的理解是正确的，WordPress不会离开React是因为它担心许可证本身，而只是担心必须将此许可证带给其用户，因此给自己带来了困惑和捍卫决定的需要。

转到React替代方案时，如果替代许可是许可的，则可能需要捍卫的东西更少，但是WordPress仍然可能带来一些混乱。

WordPress可以决定是否要担心。

@ChrisCinelli感谢您的建设性批评。 我张开双手欢迎它。

作为一名工程师，我知道成本和时间都很高。 但是，这就是事情。 这不是特定公司企业的项目。 这里的目标是不同的。

目标是找到对社区有益的JS FW。 Gutenberg尚未发射。 如果可行，那么Preact无疑是赢家。

现在，我们需要注意以下事项：

• JS FW易于为更大范围的社区所采用
• 我们选择的JS FW必须具有自己的社区和生态系统
• 具有基于PHP的生产FOSS软件的可靠工作记录者优先。 Vue + Laravel
• 根据优点选择JS FW，不仅是因为它更容易迁移到

在使用WordPress的11年中，作为常规的核心贡献者，我相信选择Preact会造成很多麻烦。 对于中级/新开发人员来说，学习曲线已经很大。

在WordPress改进的这一新阶段开始时，让他们经历一堆Preact-React兼容性问题，可能会使他们离开WordPress社区，并以类似的学习曲线学习其他知识。 （_HINT_：Laravel + Vue，而不是WordPress + Preact + React）而且顺便说一句，您是否忘记了Drupal 8会发生什么？

请不要删除民事评论。 对于这个问题，显然存在压倒性的需求或愿望。 我认为这是一件好事，因为人们说他们关心WordPress并且希望被人们听到。 请记住，WordPress社区（不仅仅是其开发人员）被定向到Github提供反馈。 如果我们确实不能容忍+1注释，那么请在顶部添加一个保留用户名的提示。

如果您只是在寻找合理的讨论，那么很多“我赞成X，Y或Z投票”的评论似乎听起来像是噪音，但是支持Vue.js的人们出现了一种清晰的模式。 我的看法是，我们有一百或几百人为Gutenberg贡献代码，但数以万计的人会编写与之交互的插件和主题。 古腾堡（Gutenberg）的成功不仅将是最终用户体验，还将是开发者体验。 这不是唯一的事情，但使WordPress成功的重要一件事是它易于扩展。

虽然我没有特定的框架，但我想说的是，我们应该记住的一件事是，浏览器支持已开始与Web组件融为一体，该框架利用了Web组件或至少像他们将是未来的证明。 还可以使用polyfill将不支持Web组件的Web组件带到浏览器。

之前提到过我，我只是来这里是为了关闭通知，但我会稍加说明。

如果您是从头开始构建单个页面的应用程序，那么时间至关重要，并且您需要一个受良好支持的，有文档证明的和可测试的框架，我有很多具体的经验表明，这样做的时间和成本要便宜得多和Ember一起去。

如果您要构建更多的PWA或将组件放入服务器渲染的页面中，那么Ember是一个糟糕的选择，我可以理解为什么Vue这样的东西会吸引人。

我要补充一点，从约定俗成的角度来看，我使用Ember创建了一些PWA，灯塔得分大于90。

在我们需要执行此操作的上一个项目中，该过程花费了不到1小时的时间来获得灯塔得分并在启用服务器端渲染的情况下部署应用程序。

高灯塔得分所需的SSR和服务人员缓存可能是一个非常棘手的过程。
使用Ember，此过程非常简单，只需要安装一些文件良好且维护良好的插件（对于大多数应用程序）。
根据我的经验，Preact在Preact CLI中确实具有这两个功能，但是流行的（P）React约定可能会破坏SSR结果。
对于Vue，官方文档建议使用Nuxt.js或遵循完整的SSR指南； 这两种方法都引入了更多的模式，除了基本的Vue文档之外，还需要遵循这些模式。

没有告诉别人，但是让我们推迟删除有关问题的评论，除非他们是亵渎或辱骂。 我完全希望人们帮助和集中讨论，但是我们不应该陷入删除评论的漩涡中。

与VueJS @rtablada相比，我不确定Ember的“文献记载”如何。

与Vue甚至React相比，我个人从Ember开始都会遇到问题。

@ahmadawais每个人都忘记了此决定将产生重大影响，并且您将想在几年后改变框架。 因此，您想使用现代框架的优点，但又不将其与生死攸关。 听起来不可能？ 不是！

不久前，我遇到了类似的问题，经过研究和尝试，我想出了一种解决方案，试图将水与火联系起来。 简而言之-Web组件的自定义元素，包装您喜欢的技术（例如Vue，React，Angular）并公开标准DOM API。

在这种解决方案中，您将具有多个组件，并且每个组件都有：

• 您喜欢的框架（但当然最好只有一个）
• 其他组件可以轻松使用的标准DOM API。 您甚至可以通过普通的JavaScipt操作它

当我当时与Vue一起工作时，我为Vue编写了Custom Element的适配器-https: //github.com/karol-f/vue-custom-element-因此您具有出色的兼容性（例如Vue的$ emit发送标准DOM事件，可以通过纯JS或例如React / Angular捕获）和IE9 +兼容性。

我建议您考虑以下解决方案：

• 将是面向未来的
• 不会与您今天选择的任何框架捆绑在一起
• 您的用户将看到标准的HTML元素，并可以使用他们喜欢的框架甚至是纯JS与之交互
• 没有手动的Vue初始化，因为浏览器会告诉您并自动初始化组件是否在页面上（您甚至可以通过这种方式延迟加载组件）

还有很多。

这样的解决方案与Vue无关-您可以使用任何其他喜欢的框架。 Web组件的“自定义元素”也是标准的浏览器功能，不会消失！

问候！

我的看法是，我们有一百或几百人为Gutenberg贡献代码，但数以万计的人会编写与之交互的插件和主题。 古腾堡（Gutenberg）的成功不仅将是最终用户体验，还将是开发者体验。 这不是唯一的事情，但使WordPress成功的重要一件事是它易于扩展。

@dmccan引用上面的评论，因为这是支持Vue的重要点。

WordPress不仅使发布民主化了。 我不知道由于WordPress的可访问性，已经成功启动了多少成功的技术职业和业务。 我的，当然。

我要向VueJS表示感谢。 这里的本地JavaScript聚会是由VueJS核心团队的一位成员共同领导的，似乎参加会议的人可以比其他人更快地上岗。 我以前的经验是使用AngularJS，我发现VueJS的学习非常简单，即使我从头开始也只是开始编码。

我看到有些人在谈论企业，因此在谈论Angular，但是WordPress在这方面可能需要一些帮助，但我认为决定应该基于功能以及其他方面，从而简化了开发人员的入职。 通过我们在meta框上进行的讨论以及诸如此类的讨论，使插件作者可以“ Gutenberg-ify”他们的工作，而不仅仅是在经典编辑器消失时放弃它。

关于Vue.js值得一提的

• PRO它不一定需要编译器或强制使用方式，并且可以像jquery一样直接在Web上运行

这将极大地帮助插件开发人员与Wordpress UI集成。 他们可以将新的vue实例作为小部件附加到页面的任何部分。 大型Wordpress项目也可以逐步采用Vue.js，而无需在代码库中进行重大更改，因为vue无需假设其使用方式。 我认为这是Laravel / Vue如此受欢迎并能很好地合作的成功关键:)

• 还支持PRO JSX和css-in-js！

它可能有助于将具有React / JSX代码的当前WordPress项目更快地迁移到vue.js，而对变更的要求却更少。 （甚至还有一个babel插件： babel-plugin-transform-react-to-vue ）

• FACT Vue与Preact一样，与Angular / React不同，它不是由Google或Facebook这样的大公司拥有的开源项目。

对于像Wordpress这样的庞大项目来说，避免潜在的供应商锁定至关重要。 如果不是公司所有的开源项目，则应该启动它（因此，“关键人物依赖项”被称为CON毫无意义）。

我投票支持VueJS。
不是因为我对此一无所知，而是因为我不知道英语是怎么发音的。 但是，我使用Joomla多年了，并一直都说错了。

开个玩笑。
这里没有太多人讨论哪种框架在支持旧的元框和自定义字段方面更好。 正如我们现在所知道的，React非常糟糕。

现在，只是取消订阅此问题。

为了集中讨论，我在这里创建了一个任务问题： https :

我建议Vue，只是因为Laravel。 许多WordPress人士对它所采用或仍然采用的方法感到不满意，他们转而使用Laravel作为其主要CMS框架，同时保留WP作为第二选择。 Preact只是一个克隆和巨大的兼容性层，就像Novell DOS对MS DOS，PC DOS一样，反之亦然。

铜，w0lf。

一路Vue.js ！

您当然应该看看Hyperapp 。
优点

1. 它与Elm（模型，视图，更新）体系结构非常相似。
2. 它具有Reduce之类的内置Redux，称为“动作”（用于更新模型和依次查看）。
3. 使用JSX
4. 鼓励“功能编程”设计
5. 它是1kb，因此易于加载且易于理解。

缺点

1. 它仍然是新事物，生态系统也是如此。 但是您可以影响它并为此做出贡献。
2. 可能有些问题尚未发现。

Gutenberg块的原理与Web Components的原理很好地吻合。 它是低级的，与框架无关的，并且是一个新兴的标准（具有成熟且经过测试的polyfill）-非常适合WordPress。

另请参阅：聚合物-含糖的Web组件。

Vue是一个很棒的选择，这是我相信的原因：

我从2016年初开始观看Vue。我很喜欢它，并想确定它是否“很受欢迎”，或者它的增长是否值得一提。 当时它在Github上有16,000颗恒星。 一切都很酷，但是在Angular vs React的所有废话中，人们并没有真正适应它。

我最终丢失了所有数据，并于2016年9月17日重新开始。正好是一年前的今天。 （这是我当前的数据集。 ）

在过去的一年中，我看到Vue的受欢迎程度以破纪录的速度增长（就互联网上的提及和追踪Github明星而言）。 Vue在365天内累积了40,000颗星。 那是平均每天109。 相比之下，世界上最受欢迎的_React_在同一时间范围内从49,000增长到75,000。 （每天71个）在用户评分方面，Vue将在未来几个月内超过React。

当每个人都在谈论React的增长是有史以来最令人难以置信的增长时，他们并没有意识到Vue是真正的冠军持有者。 他们没有意识到Vue的增长是因为人们真正喜欢Vue作为一种工具，而不是因为任何著名的支持（Facebook）。

Vue每天都在Github的趋势回购清单中，已有一年多的历史了。 它高于React的天数为99％。 在10％的日子里，React不会晋级。

所有这些喊话是“使用Vue，因为它的受欢迎程度有所提高！” 但是我要表达的意思是，Vue之所以发展，是因为人们真诚地喜欢它，因为它是适用于各种规模应用程序的强大，直观和强大的工具（通常错误地表示为“小型应用程序的绝佳选择”）。 但不仅是一种工具。 Vue是一个生态系统。 它还带有庞大的支持社区。

我可能会添加... .vue文件是天才。 由于在CSS模块中存在明显的问题并且将样式保存在外部文件中，因此在React中构建了很多工具来处理样式。 （Idk ...）但是Vue没有这个问题。 Vue的语法中包含了控制语句，并且（因为我已经看过上面的自定义元素注释了）不仅可以与自定义元素一起使用……它是逻辑自定义元素的库/框架。

精确度很高。 老实说，我今天才开始另一个项目。 但是，当我看一下Preact时，会看到一个品牌外的React。 它并不是为了创新或为了改进我们创建基于Web的软件的方式而构建的。 创建它的目的是使外观和行为像现有工具一样，但是可以提供更好的性能。

那是我的两分钱。 现在我破产了。

希望您的最终决定能让您满意，并为产品的未来打下良好的基础。

@ahmadawais ：

• 上市时间对于企业和开源项目都很重要。 您可以找到从未交付过的项目的示例，因为这些项目最终花费的时间太长，并且在交付之前就已过时。 一些项目最终在进行主要发行的工作中被放弃了。
• 反对Preact意味着“我们出于许可之外的原因对React犯了一个错误”。 我认为，“对于中级/新开发人员而言，学习曲线已经非常庞大”，这意味着Wordpress的开发人员已经被React迷失了。 这并不令我惊讶。 但是，似乎很难相信Vue即使解决了一些冗长的问题，也能解决学习曲线问题。 旧的PHP WP引擎和任何单页应用javascript框架都非常不同。 Vue和React彼此非常相似。
  我不确定为什么您会看到Wordpress和Laravel之间的竞争。 我在这里可能很幼稚。 我对Drupal 8的故事了解得很少。
  从我的角度来看，Wordpress是CMS，它吸引了开发人员，因为其庞大的用户群（而非技术用户）及其内置的功能。 有许多模板，开发人员可以非常快速地构建非开发人员可以自定义的新站点。
  据我所知，Laravel是一个PHP框架，没有为您提供CMS的许多功能。 开发者会选择它，因为他需要更多的自由。
• 我不确定在Vue + Laravel上取得一些成功也意味着“ Vue对Wordpress有好处”。 我认为PHP与任何JS框架之间几乎没有内在的协同作用。 我完全同意，找到一个对社区有益的框架很重要。 如果wordpress所依赖的当前开发人员社区中的大多数人都熟悉Vue并且很喜欢Vue，那么这对您的最终决定很重要。

从工程学的角度来看，我认为Marko JS和Vue都是较新的框架。 他们从React中学到了很多东西，并且能够消除其中的一些冗长。 从这个意义上讲，Marko似乎比Vue删除了更多样板代码。 特别是，Marko保持了凝聚力的代码，该代码很好地保留在同一位置，并在HTML中保留了HTML的优点，而在Javascript中保留了Javascript的优点。 而且速度也快10倍。 因此，除了最近Vue有很多粉丝的事实之外，我看不出有很多理由喜欢Vue而不是Marko。

抱歉，但Marko的语法和设置与VueJS相比更可怕。 在性能方面，我没有见过任何来源，其中MarkoJS在没有增加任何时间来了解它如何工作的情况下以任何重要方式都可以更快。

@ bovas85语法是主观的，但是我认为您没有任何根据认为Marko的语法“比较可怕”。 真正的Marko早期版本的语法与Vue的基于HTML的语法更接近，而引入Marko当前语法的发行版深受用户欢迎。

我们对Marko语法进行了大量考虑，以确保了解HTML和JS的开发人员熟悉它，并且希望它尽可能简单，功能强大且模板最少。 我想您会发现，通过进行任何并排比较，Marko模板将需要更少的代码（这对于可读性和可维护性而言非常有用）。

这是我快速整理的文档，以便您可以大致了解Marko语法和Vue语法之间的区别：

语法：Marko vs Vue

我之前已链接到它，但是要更深入地比较Marko和Vue（以及React），请参阅：

聚会：构建UI-对React，Vue和Marko的比较（来自Marko创建者） -视频| 滑梯

至于性能，我们有一些基准可以检查： https :

以下是启用Marko和Vue的基准测试的快速运行：

服务器端渲染性能

_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

客户端性能

_Chrome版本63.0.3218.0（正式内部版本）金丝雀（64位）_

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

这些是我们为Marko.js创建的基准，因此显然要花些时间才能得出这些结果，但我们已尽一切努力做到公平。

另外，只想添加一些有关Marko.js和易用性的注释：

Marko一直致力于与Node.js进行最简单的集成。 通过npm安装marko软件包后，这里是将模板呈现到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);

我认为这就像您将要获得的一样简单。

Marko还可以与流行的JavaScript模块捆绑器一起使用： http :

要将顶级Marko UI组件呈现到DOM，这里需要做的就是：

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根据http://www.stefankrause.net/wp/?p=431基准，markoJs
与Vue等人一样出色。

因此，我们可以得出结论，在一般的客户端脚本中，Markojs和Vue的性能相同。

当然，我链接的基准测试不包括ssr。 所以我不会对此发表评论。

我投票支持Vue。 jQuery已经是使用WordPress的迫切要求。 熟悉jQuery的人应该熟悉Vue语法。 关于DOM的意识形态并不像Angular那样极端。 为了用户的方便，它依赖于WordPress主体。

正如我大约两年前为Calypso所建议的那样，使用HyperScript API的Mithril.js是替换React的不错选择。 它具有标准的MIT许可证。

在新工具上进行少量投资，至少可以完成一些自动完成的工作，以便从React转换到另一个vdom库，这可以节省大量开发人员的时间-正如该期中提到的，这是建议Automattic提前对冲它押注于React。

即使不考虑非vdom库，也可以考虑25个以上的vdom库（例如inferno.js，maquette等），正如我在2016年1月列出的考虑vdom选项的其他项目中列出的那样。

以下是一些技术原因，为什么Mithril.js或其他强调（或至少支持） HyperScript API的vdom是最佳选择。

就我个人而言，我觉得使用模板方法来制作JavaScript驱动的UI（如React的JSX或Angular自己的模板方法）或许多其他UI系统（包括Vue）中的模板系统已经过时了。 为什么？ 使用复杂CSS样式表（如以前的WordPress插件）来编写服务器端生成的基于HTML模板的Web应用程序的首选项和“最佳做法”正成为编写单页Webapp的“最差做法”。 由于复杂的客户端代码越来越复杂，因此编写复杂的现代单页客户端应用程序的技术需求与主要基于服务器的代码不同。 简而言之，使用模板和复杂级联样式表的旧“最佳实践”只是无法扩展，这导致难以维护代码。

什么是新兴的替代方案？ 现代Web应用程序可以使用Mithril + Tachyons + JavaScript / TypeScript在单个文件中编写组件，而所有代码都只是JavaScript / TypeScript。 这样的应用程序不需要用CSS或HTML的某些非标准变体来部分编写（重新实现一部分编程语言）（严重）。 （嗯，在Tachyons或类似库的顶部可能需要一点自定义CSS，但很少。）

这是我以这种方式编写的编码场所的示例，其中有几个使用该方法的示例。

因此，通过使用HyperScript（加上vdom库）编写UI，您可以（通过一些工作）用几乎任何其他vdom甚至非vdom解决方案替换像Mithril这样的后端。 因此，当我有选择时，选择使用HyperScript API是我减轻存在错误或许可问题的基础库带来的风险的一种方法。

通过使用Tachyons或类似的库，随着应用程序的增长，我降低了无法维护的CSS文件的风险。

当然，我知道许多Web开发人员都是在调整HTML并喜欢HTML外观模板的基础上长大的。 因此，他们喜欢JSX或其他任何东西，并乐于忽略在其应用程序中间重构或验证此类非代码内容有多么困难。 当然，某些IDE在重构JSX模板方面变得越来越好。 但是我是从台式机和嵌入式开发进入Web开发的，该系统与您通常通过代码（例如，使用Swing，Tk，wxWidgets等）直接生成UI的系统一起使用。 我喜欢标准工具可以帮助我重构所有工作代码并检测出许多不一致之处的想法。

假设此处运行的所有框架由于它们在所选浏览器上的速度而对用户没有任何可见的差异，我们可以停止使用前端性能作为度量标准来评估哪个框架是最佳选择。

但是，如果使用服务器端渲染，则应仔细查看SSR性能。 Calypso似乎旨在拥有SSR。 如果成功，那么有一天，Calypso将在wordpress.com上运行大多数站点。

公司为服务器上的CPU付费，而不是为浏览器上的CPU付费。 因此，从成本角度来看，Marko的渲染时间提高了

如果Wordpress可以忽略这一点，那么我将很乐意为公司工作并获得10倍的市场薪水，并使用Vue，顺便说一句，我认为这是一个不错的React选择=）

框架越轻便，即开箱即用提供的功能越少，执行起来就越快。 这是可悲的明显。 比较各种算法的性能是一回事，但是当最大的因素是执行了多少其他“填充”时，则无需编写测试。

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

@ahmadawais Angular核心团队在这里-我们正在进行许多与CMS / Widget样式开发相关的有趣工作，包括对Custom Elements支持的投资（以我的钱，这是构建平台的明智之选）

如果您有兴趣的话，我们将不愿意与所有人闲聊，而不是让话题更加混乱。 在google dot com的robwormald给我留言。 祝您好运，我不必羡慕您必须拨打电话;-)

我在这里整理了一个简单的民意调查，可用于深入了解人们的需求。

当前在结果页面上工作并对其进行身份验证。 （Firebase的新手）

PS。 用Vue🖖花费了大约1个小时

@vinayakkulkarni如何将Mithril.js添加到您的投票中？

@pdfernhout ：👍

做完了我已经将MithrilJS添加到列表中。

• [x] VueJS
• [x]角度
• [x]预先
• [x]灰烬
• [x]马可
• [x]地狱
• [x]奥雷利亚
• [x] Mitrhil

让我们看看人们的决定。
PS。 @ahmadawais也进行了推特投票。

你好我是Drupal的核心维护者。 正如@ivanjaros在先前的评论中提到的那样，我们还在评估Drupal的管理UI的一些细节，Preact，Vue或其他。 我们可能会选择与您选择的东西不同的东西，但是您选择的东西肯定是我们选择时至少要考虑的一个因素。

到目前为止，我已经打开了这两个Drupal问题，并且还会有更多问题。 如果这些问题/讨论对您有用，请在这里交叉引用它们。

• 返回多个根节点的组件
• 插槽与vnode道具

请注意，尽管有这两个问题，我仍然非常喜欢Vue。 为了获得Vue的所有其他好处，这些可能是我们可以接受的。

作为Vue的作者，由于明显有偏见，我将避免就此处选择哪种框架发表评论。 但是当我看到“ Marko比Vue快10倍”的说法出现了好几次时，我感到值得澄清。 我也不想将讨论拖入技术性辩论中，因此，我已经在本要点中为感兴趣的人写下了一些想法。

有关财务问题的@ michaelbdavidson7 ：我已经全职从事Vue的工作了1.5年以上，Patreon的支持一直非常稳定。 您可以检查Vue的提交活动来自行判断，而不必猜测Patreon的承诺波动。 此外：开放的财务捐款渠道意味着WP / Automattic可以通过成为主要赞助商（马特本人已经是个人赞助商）轻松确保Vue的可持续性-实际上符合两个项目的利益。

我投票Vuejs

@ tungbt94为什么？

绝对是VueJS

更大的问题是，为什么在此专利发布之前选择了反应。 如果没有专利，您还会使用react吗？ 关于不选择行为的许多观点与不选择反应的观点相同。

我的投票是Preact

由于除了React之外我没有太多经验，因此我不会重点介绍选择哪种框架。
但是，我认为“大社区”这一论点不太重要。 为什么？ 因为当Automattic决定一个框架时，该农场将吸引成千上万的新用户。 如果我知道WP社区是正确的，他们中的许多人也将开始为该框架做出贡献，并且受欢迎程度将上升。

考虑到古腾堡和卡里普索目前所处的位置，我仍然认为Preact是最佳的工程选择。

但是，如果您仍然对刻录类似于React的桥梁感到坚决，或者必须从头开始，那么我仍然相信MarkoJs是最佳选择。 我认为社区支持可能仍然是一个问题。

假设Github的星星与社区有某种联系，那么Vue仍然是MarkoJ的10倍，

Vue呈线性增长：

但是MarkoJs似乎正处于指数​​增长的拐点：

@帕特里克-斯蒂尔-同上，主要作者MarkoJs ，一直是超级敏感的https://gitter.im/marko-js/marko

当人们最终选择MarkoJs时，但实际上选择了任何类型的社区，我

我个人要祝贺@ahmadawais创建了一个问题，该问题引起了许多使用并支持相关JS库选项的JS开发人员的广泛参与。

我怀疑这个问题已经帮助更多的JS开发人员了解到WordPress通过Gutenberg进行的基于JavaScript的开发要比到目前为止的任何其他Gutenberg通信都要多。

我使用AngularJS，但我不希望每次都进行主要更新，因此我将使用VueJS。

+1为Marko。 我们的团队使用并且一直很满意的出色图书馆。 异步渲染，超快（在服务器中使用字符串并在浏览器中使用vdom），单个或多个文件组件以及IMO最好的模板语法。

请考虑@WebReflection的hyperHTML 。

我喜欢Angular

我投票角

我选择角度

只是角

我选择角度

角度的

我投票角

我投票角

如果您愿意为框架投票，那么知道确切的原因及其对古腾堡的帮助将非常高兴。

对于来这里的偷窥者只说“我投票X”，请给我们一些为什么我们也应该投票X的理由。 “我投票X”除了告诉您您喜欢X之外，什么都没有告诉我们。

我选择有角度的。 自版本2起，Angular发生了一些重大变化。 现在，它是一个完全，良好，强大而广泛使用的框架。

垃圾邮件太多，“我投票了框架”，github在为我尖叫。

我敦促开发人员在https://vinayakkulkarni.github.io/poll/ https://vinayakkulkarni.github.io/poll/上投票赞成您选择的框架，而不是仅仅发布“我投票……”；

另外，另一个建议是锁定此对话。 大多数主要开发人员已经对此发表了意见。

2017年9月18日晚上8：01，Mingyue [email protected]写道：

我选择有角度的。 自版本2起，Angular发生了一些重大变化。 现在，它是一个完全，良好，强大而广泛使用的框架。

-
您收到此邮件是因为有人提到您。
直接回复此电子邮件，在GitHub https://github.com/WordPress/gutenberg/issues/2733#issuecomment-330241898上查看，或忽略线程https://github.com/notifications/unsubscribe-auth/AS3FbT23DvVwTLGL61tmK7KtuwZeg- ucks5sjn7SgaJpZM4PYie9 。

感谢@kidwm提到_hyperHTML_，但我认为最好遵循他们的方向：

不只是分享您喜欢的JS框架，还分享为什么

所以让我尝试这样做...

：zap： hyperHTML ：

• PRO ：对P / React用户友好且熟悉初学者（而不是JSX，而是编写模板文字）
• PRO ：无需VDOM即可快速燃烧； 更少的内存消耗（新兴市场的手机友好型）
• PRO ：不需要任何工具（仅针对IE <11才需要转译的模板文字）
• PRO ：完全基于JS / DOM / HTML标准，但也兼容TypeScript
• PRO ：小于5K（最小压缩），不需要额外的polyfill或浏览器补丁
• 专业版：100％的代码覆盖率低至IE9怪癖
• PRO ：与NodeJS共享
• PRO ：它可以采用现有的DOM，而不会破坏SSR布局/节点
• PRO ：与P / React相比
• PRO ：它可以执行React ， Vue.js ， Polymer ， Angular或Marko的操作，并且在大小，带宽/性能方面都胜出

现在，根据此线程到目前为止使用的度量， CONS

• 缺点：即使经过了战斗测试，完全测试并使用了冻结的API，它还是一个相对较年轻的项目（2017年3月），因此就普及度，采用率或贡献者数量而言，它无法竞争
• 缺点：社区正在提供很多帮助，项目正在不断发展，但是到目前为止，主要的技术贡献者是我。 不过，我100％致力于这个项目，并愿意尽我所能，此外，我正在与一些“ _bigs_”讨论在他们的下一个大型项目中使用_hyperHTML_的问题（我不会再作进一步的推测了）尽管可以随意忽略后面的部分）

：dart：我真的相信Web的未来是尽可能多地使用该平台，它肯定比10年前更好，而且由于有了现代ECMAScript规范，使编写，阅读和维护变得更容易。 _hyperHTML_代表了潜力的“ _Web art_state的当前状态”，而该列表中的所有其他竞争者都诞生于完全ES6时代。

我了解社区的规模，贡献者和GitHub明星很重要，但我认为还应考虑测试，跨浏览器的代码覆盖率以及漏洞数量，并且我正在尽最大努力使_hyperHTML_和朋友的数量接近零（除了不是bug的讨论，现在实际上为零）。

最后但并非最不重要的一点是，如果没有人提供新解决方案的机会，仅凭星级和炒作来判断，新解决方案将花费比他们更受欢迎的时间更长的时间。

当然，我已经谈论过我的最新解决方案，我的考虑可能被认为是主观的，但是特别是我后面的关于给予新解决方案机会的句子非常笼统，而不仅仅是关于我的库：smiley：

最好的祝福

我喜欢棱角分明

必须是angular和google。

我爱棱角分明

Angular才是真正的框架！

我选择Angular，而不是AngularJs。

只有棱角才是真正的框架！

我开始怀疑，这些评论是由机器人做出的。

@OP ：请锁定此线程。

我投票支持Angular（NOT AngularJS）。

Angular是一个平台，Google团队做了很多出色的工作来简化开发进度，包括组件，模块，路由器，以及依赖项注入，您可以节省很多工作来安排所有依赖项，在angular-cli中，您可以节省很多工作来启动一个全新的项目，只需打开包装盒，您的应用程序就会通过aot，摇树和许多其他优化进行很好的编译。

TypeScript是另一个出色的角度工具，由MicroSoft提供，也就是整个角度平台都由ts构建。 您也使用ts构建应用程序！ 这是一个很棒的工具，当代码量越来越大时，使生活变得更轻松，您只需单击一下即可在IDE中进行重构（例如vscode）。 静态类型检查使您可以尽早发现错误。 TS还提供了OOP的良好实现，您可以以更好的方式安排和重用代码。

还有很多基于角度构建的组件，例如“材料设计2”，“ priming”，我想向您推荐由我们团队创建的Jigsaw 。 被中兴通讯中国大数据产品采用。 它现在支持中兴通讯的所有应用程序。

Anglar是一个不错的选择！

对于所有机器人：🖕

可能有人在AngularJs社区发布了。 我认为人们如果不想再收到任何消息，可以将其静音。

我认为，最终在这个只有WordPress贡献者的地方必须进行类似的话题讨论。

我想分享一些我在EmberJS松弛社区小组中已经表达过的关于这个问题的一些想法，如果您有10分钟的时间阅读那里的讨论，我会推荐它： https :

我在讨论中的要点如下：

• 比较在Ember框架和其他任何库中实现2-4周的峰值时间后，其他图书馆往往会在短期内获胜，但Ember对于任何长期项目都会胜出
• 在考虑使用哪个库或框架时，不仅要考虑技术实施，而且还要考虑“软技能”方面（社区规模，支持LTS的承诺，社区参与项目核心决策）非常重要。
• Ember拥有对使用ember-cli“幕后”构建的应用程序进行重大改进的记录，即无需升级任何应用程序代码。 在某些情况下，还可以对应用程序代码进行较小的升级（包括使用ember-watson之类的代码

我不想在此评论中过分详细，因为我可以很高兴就上述几点写一篇10,000字的文章。 但是，我想向愿意与“ Ember心态”的人讨论此问题的任何人提供时间。

如果任何决策者想与我进行一个小时的通话，询问关于更广泛的Ember生态系统的更明确的问题，我将很乐意这样做。 您可以在我的Twitter上与

我在eBay为“我的eBay”工作。 我们刚刚发布了第一个单页应用程序。 我们喜欢使用MarkoJS进行开发的每个阶段。 和我一样，如果您喜欢节点的流编程范例，那么MarkoJS支持流和异步渲染。 我喜欢MarkoJS的其他事实：

• 它有效地绑定了呈现在服务器和浏览器中的UI组件的行为。

• 高效的事件委托

• 从服务器到浏览器的状态快速序列化

@vinayakkulkarni我认为您的想法很好，但是问题是，通过更改浏览器，我可以留下超过1票的票数（我没有尝试使用同一浏览器）。

您可能应该使用推特投票（但已经有一个）或实现登录系统以使投票唯一。

服务器渲染与此处的对话无关。 Node不会成为必需的WordPress堆栈的一部分，因此这些框架在Node中呈现的速度与决策无关。

Vue.js！ 期待这个项目https://github.com/bstavroulakis/vue-wordpress-pwa

我选择了Angular （不是AngularJS），它具有最大的社区，稳定而完整的生态系统。

Angular非常慢，而v4则基于打字稿，因此对wordpress开发毫无用处。

我根据平台的成熟度选择Angular

我之所以投票赞成Vue，是因为它更易于学习，并且因为我最喜欢的框架Ember Js太大了而无法工作，而Glimmer Js仍然太新。 :-)

服务器渲染与此处的对话无关。

就我而言，我刚刚提到了其他人认为与之相关的功能

节点不会成为必需的WordPress堆栈的一部分

_hyperHTML_可以选择任何服务器端呈现的内容，包括PHP。 我是Zend认证的工程师，并且我已经与使用WordPress的记者/发布者一起工作，我的暗示并不只是突然的。

因此，这些框架在Node中渲染的速度与决策无关。

框架也可以在后端工作的事实，可以获取服务器端渲染的内容，并且甚至可以与NativeScript兼容，这在今天已经不重要了，但是一个开放的项目可能会考虑到将来兼容的特性。

@webreflection我并不是要特别提及您的评论。 它更多是为了回应我上面的评论，其中强调了Marko的“流式范例”，但它旨在涵盖有关BE渲染性能的所有评论。

视图

来自https://ma.tt/2017/09/on-react-and-wordpress/的@mAAdhaTTah ：

那篇文章不会发表，而我在这里要说的是，古腾堡团队将退后一步，并使用其他库重写古腾堡。 这可能会将Gutenberg推迟至少几周，并可能将其发布推迟到明年。

更重要的是：

Automattic还将使用我们为Gutenberg选择的任何内容重写Calypso

Calypso已经在使用服务器端渲染。 参见： https :

所以我的理解是SSR的表现是相关的。

我也喜欢棱角分明！
AngularJS js真实框架！

我投票给Angular

@chriscinelli这是Automattic，而不是WordPress。 WordPress本身不使用节点进行服务器渲染，因此在这些条件下的性能与项目无关。

很显然，Angular是最佳选择

我投票给Angular

我投票给Angular

我投票支持Vue.js。
它节省了大多数时间，尤其是在处理视图层时。

我必须投票支持Vue ！！！

投一波angular

@trotyl该评论是不可接受的。 我已经编辑了您的评论以将其删除。

哦，请不要AngularJS
现在是Angular。

@mAAdhaTTah来自维基百科：

WordPress由其创始人Matt Mullenweg和Mike Little于2003年5月27日发布，是b2 / cafelog的分支

尽管WordPress很大程度上是由周围的社区开发的，但它与由Matt Mullenweg创立的Automattic紧密相关。

这是Calypso： https ：

正如我在之前的评论中所写，从博客文章中删除了Matt的

我认为这足以使SSR绩效与此决定相关。

但是，在遥远的未来，一旦Wordpress开发人员习惯了Preact（或Vue或Marko或其他框架），可能会出现一个新的疯狂项目，他们决定通过节点为Wordpress的更多部分提供服务。 这将使SSR更加重要。 因此，SSR的性能可能更为重要。

在讨论SSR的对话中，我认为应该谨慎地说，这对Ember来说是非常重要的，并且随着Ember-Fastboot的到来而被广泛考虑

虽然我确实在一些客户端应用程序上使用了Fastboot（效果非常好），因为这是高级技术讨论，但我建议与@tomdale联系，因为他是Fastboot工作的拥护者👍

@chriscinelli WordPress社区项目和Automattic公司仍然是单独的实体。 如果Automattic由于SSR主张彼此赞成，那么他们可以，但是仍然没有改变我们WordPress社区应如何考虑WordPress核心的选择框架，该框架没有，实际上也没有，要求节点运行。

无论如何，我已经退订了该线程。 如果您想离线继续讨论，请在我的个人资料中找到我的电子邮件。

并实际上并不需要节点运行。

请不要将SSR功能作为区分点。 具备节点SSR功能的框架可以完全不使用任何节点SSR：这只是一项额外功能，而不是要求或依赖性。

我会投票给Vue.js

我是去麻省理工学院（MIT）的高级拱门，理应相当聪明。 我已经做了很多年了，并且在这里和那里采访了一些开发人员。 我知道网络上到处都是聪明人，但是任何认为V​​ue的简单性与Angular的复杂性都可以相提并论的人都对构成“复杂”的东西失去了认识。 正如Google所设想的那样，基于组件的Javascript绝对是不平凡的。 这太荒谬了。 Vue不是。 Vue和PHP一样容易。 我说的很明显，因为“ Vue更容易学习”甚至无法描述Vue比Angular容易得多。 这就是要抓住的地方-我认为它比React还容易得多。

对于普通人来说，React处于e-peasy和google级之间。 对于小型商店，我想说React足以挑战小型团队。 React比PHP / Wordpress更复杂。 通过选择React，Wordpress / Automattic提出了开发人员进入Wordpress开发人员世界的要求。 我敢肯定，数百名人们会大声疾呼：“反应容易”和“网络变得更加智能”，但最终复杂的还是复杂的。

我谦虚地认为，退回到Vue将更接近WP的根源，并且对整个WP社区的技术负担较小。 除了网络范式-有时候，简单就好。

Angular和Vue是两件事

Vue，React，MarkoJS，Inferno，Preact等是仅覆盖视图层的库。 所有这些（包括Angular）都有一种创建HTML并以声明方式对DOM进行变异的方法。 Angular希望为前端开发提供一个完整的框架，并且在视图层之外还有更多的东西。

React的语法是此示例中最古老的。 Facebook很好地绑定了一个非常复杂的库，该库在非常有限的协议范围内完成了很多工作（可能太多）。 您无需知道React内的任何复杂性即可知道如何使用它并提高生产率。 您可以实际学习基础知识，并在半天后开始使用。

此列表中的所有其他库都从React学习。 他们试图简化语法，提高React的性能，减小执行相同操作所需的Javascript代码的大小并在其之上添加一些功能。
Preact在将接口与React仅保持3Kb非常相似方面做得很好。
Inferno和Marko极大地优化了渲染性能。
Marko和Vue大大简化了语法，以减少样板代码。
Marko还添加了可选的Jade / Pug之类的语法，以使代码保持更干燥，并具有创建异步模板的能力，从而使所有内容对用户而言都简单直观。

但是，除了Angular之外，所有这些库都要求工程师提出一种策略和机制来获取数据，路由等。Redux及其中间件是Gutemberg用来管理数据层的一种流行方式。

在从React迁移时，古腾堡不需要“仅仅改变另一件事”。 即使Angular努力保持对用户的不可知论，尽管开发并支持了https://github.com/angular-redux/ng-redux之类的库，但将Redux和Javascript（与Typescript）结合使用并不是一个自然的选择。适用于Javascript。 再看到目前为止的票数，似乎古腾堡的社区强烈反对谷歌的框架。 因此，很可能不会选择Angular。

PHP和任何这些Javascript框架都是完全不同的野兽

您可以有一个PHP后端和一个单页应用程序前端，但是没有协同作用，几乎没有相似之处。

任何Javascript应用程序的复杂度至少比编写一些jQuery的普通PHP代码要复杂得多。 所有现代Javascript应用程序都必须处理两个巨大的复杂性怪物：有状态性和异步流。 这些年来，不变性和async / await缓解了这些问题。 随着应用程序的增长，开发人员的流程会变慢。 更改某些代码后，需要重新编译，重新启动，并且该应用程序必须再次进行初始化。 已经构建了大量工具来实现热重装，即使这些工具很棒，它们仍然远非完美。
无论为视图层选择哪种库，都将不得不应对额外的复杂性。

在PHP中，您可以更改代码，保存文件，并且可以立即重新加载页面，而无需进行构建或重新加载。 一切正常。 更重要的是PHP完全是无状态的。 每次重新加载页面时，都有空白。 甚至全局变量在每个请求中都有一个干净的状态（但是使用它们= P并不是一个很好的借口）。 几年来我都没有写PHP代码，但是我仍然想念它的简单性和开发经验。 如果您使用CakePHP，Symphony或Laravel之类的现代框架，那么与其他语言和框架相比，您不会错过很多，而其他语言和框架更受高级工程师的欢迎。 例外是速度。 PHP通过运行时性能来实现其简单性。 每次重新加载页面时，都需要再次执行所有代码。 HHVM和PHP7的性能提高了很多，但总的来说，它们与使用node.js所能达到的水平相去甚远。

结论

您最近使用哪个库无关紧要。 即使您喜欢它，也不意味着它是古腾堡的最佳选择。
但是，古腾堡大多数核心贡献者可能喜欢一个特定的库这一事实很重要。

到底：

一个坚信自己意志的人仍然持相同观点

我认为有关该线程的优缺点，关于不同可行库的信息很多。

古腾堡（Jutenberg）和Wordpress（诺富特）的贡献者应该被抛在脑后，可能在“封闭的大门”中相遇，远离前端粉丝。
现在可能是时候阐明您的价值观，目标和制约因素，并根据最大的成果来选择框架。

再次祝您好运😃

我对Vue投了赞成票。 初学者友好且健壮。 当我第一次开始使用Vue时，我有一种感觉，就像我刚开始使用WordPress开发时一样。 +💯

仅对初学者友好的@ colorful-tones不够好！ 每个项目都有一个生命周期，大部分工作都在维护过程中。

@ChrisCinelli一些澄清和意见：

Angular希望为前端开发提供一个完整的框架，并且在视图层之外还有更多的东西。

Vue拥有用于路由，状态管理，测试，整理等的官方库，以及一个官方的cli工具。 所有这些都在vuejs组织之下，由核心成员维护并与Vue本身保持同步，但是最好的部分是您不需要学习或使用它们（因此称为“ Progressive Framework”哲学）。 与React不同，这实际上使其成为正式形式的框架。 双关语：所有这些仍然比Angular更容易学习，更快，更轻便。 ：微笑：

Marko还添加了可选的Jade / Pug之类的语法

.vue文件可以为模板，脚本或样式使用任何预处理器（例如，pug，打字稿，coffescript，sass，手写笔...）。 使用最适合您的项目的东西！

要求工程师提出获取数据的策略和机制

这只是一个例子，但是获取数据并不需要过度设计：

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

从那里您可以创建一个非常简单的Vue插件，以使代码更加简洁。

Vue本身不应该是适合此工作的库，因为总会有更好的专用库（这也是为什么默认情况下我们不提供日期过滤器的原因，因为无论如何您最终都会使用moment或另一个很棒的库） 。 我们还正在编写一本食谱，其中包含针对多个业务和用例的推荐路径和实践。

更改某些代码后，需要重新编译，重新启动，并且该应用程序必须再次进行初始化。

唯一真正的区别是构建步骤，该步骤现在很容易使用官方的vue-cli或poi之类的工具进行设置。 当您保存文件时，该应用程序几乎可以立即进行刷新（对于大型项目，构建时间也非常好，并且从使用Symfony之类的框架开发大型PHP应用程序的经验中会更加痛苦）。 另外，Hot Module Remplacement功能是PHP世界中不存在的一大优点（据我所知），即使在大型项目中，新代码也可用于在浏览器中进行即时测试（除非您拥有像编译Sass这样的昂贵操作-但使用PHP时也会遇到相同的问题）。 顺便说一下，Vue很好地支持webpack HMR。

您将不得不处理额外的复杂性。

恕我直言，与Vue这样的前端库/框架相比，一些非常流行的PHP框架似乎更复杂且更难学习。 （相反也很正确。）

根据我2年以上构建类似于Gutenberg的基于块的编辑器的经验，我认为在选择正确的框架时需要解决几个令人担忧的问题，例如

• VueJS / Marko / Angular如何与拖放集成？ 拖放古腾堡如何工作？ 拖动时，您是克隆幽灵元素还是使用现有元素？ 放置时，可以在哪里插入占位符以放置块？

• VueJS / Marko / Angular（及其虚拟DOM）如何与Content Editables和DOM Range＆Selection API一起使用？ 跨浏览器与此范围和选择的不一致在这里很难确定。

• 在Gutenberg编辑器中，复制/剪切/粘贴将在多大程度上起作用？ 我可以在多个块之间进行文本选择并执行剪切/复制/粘贴吗？ 内容可编辑内容是否存在于每个单独的块中或全部包含在主内容可编辑内容中？

• 如果存在包含iframe可嵌入内容的古腾堡块，例如在博客文章中嵌入youtube播放器或twitter提要，则将该块从一个DOM位置移动到另一位置会导致iframe重新加载。 其他警告包括无法将事件从iframe传播回编辑器（想象一下，如果您在编辑器上拖动块元素，而光标现在悬停在跨站点iframe上，则一切停止工作）。

所有框架都非常适合使用虚拟DOM，但是很多所见即所得的用法都存在于虚拟DOM之外。 我认为，在评估适用于Gutenberg的正确框架时，重点关注的领域是该框架如何处理DOM事件处理，以及对于无法使用框架构建的最新需求，在框架之外构建它的可管理性并重新插入。

视图

对于新开发人员来说，Wordpress很容易学习，如果您看起来更深一点，它也很强大，对于Vue来说也是如此。
如果WP使用此框架，我将感到高兴！

我的投票是VUE！

在构建自定义Web组件方面，我认为这非常重要，此站点将为每个列出的框架提供分数，并提供测试参数和分数。 这是有启发性的，因此鼓励所有人再做一次：

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

我对VueJS的投票。 很棒的框架，我认为Laravel证明了这一点。

WP + Sage 9（roots.io）+ VueJS =>完美堆栈

Preact也可能有问题。

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

使用Preact可能会使您比使用react更糟。 即使您未提起诉讼，Facebook也将被禁止使用您的反应或言辞。 这位律师似乎认为Preact无法在法庭上维持其版权，因此会被视为侵犯反应。

告诉我我是否错。 我对法律了解不多，但想提供帮助。

我读了此书，它类似于我们决定采取的法律建议
在我们的项目中放弃React。 不是说风险巨大。 而是我们
希望将对下游客户的风险降至最低。 这位律师只是添加了一个
意见一致。 我们改用Polymer和Vue，两者都很棒
针对特定的用例。

在2017年9月20日晚上11:04，“编码朋友” [email protected]写道：

Preact也可能有问题。

https://blog.cloudboost.io/3-points-to-consider-before-
由于facebook-bsd而从反应中迁移
专利许可-b4a32562d268

使用Preact可能会使您比使用react更糟。 Facebook会是
即使您没有启动，也可以阻止您使用react或preact
起诉。 这位律师似乎认为Preact无法忍受
它在法庭上的版权，将被视为侵犯了反应。

告诉我我是否错。 我对法律了解不多，但想提供帮助。

-
您收到此邮件是因为您发表了评论。
直接回复此电子邮件，在GitHub上查看
https://github.com/WordPress/gutenberg/issues/2733#issuecomment-331045326 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AH2_iHc8Rg54IDHqe8GIyVTdSbcJbZ9Iks5skeBngaJpZM4PYie9
。

我发誓说，看到可怕的代码后，我再也不会碰WP，但是如果您使用VueJS，我可能会再用一点Valium重新考虑它。

免责声明：我不是律师。 严格来说，以下是我的看法。

@ codingfriend1那篇文章没有什么实际价值。

做出三个假设：

1. Facebook拥有足以涵盖法规的专利。
2. 如果一家使用ABC的法令的公司起诉FB侵犯专利，那么FB将使用反应专利来起诉ABC。
3. Facebook的专利是值得的。

让我们仔细查看所有假设：

1. Facebook拥有足以涵盖法规的专利。

迄今为止尚无证据。 请记住，所有专利都是公开的。 预先的源代码是公共知识。
而且，杰森·米勒（Jason Miller，作者）声称：“ Preact均未获得专利，这太明显了。”

因此，我想这个假设不太可能成立。 可能，但不太可能。

1. 如果一家使用ABC之类的法令的公司起诉FB侵犯专利，那么FB将使用反应专利来起诉ABC。

这将破坏Facebook的声誉。 虽然我希望FB发挥作用，但是使用React的专利将FB标记为“专利巨魔”。

同时，FB有足够的资源通过法律手段进行战斗。 因此，我认为这种假设也不大可能。

1. Facebook的专利是值得的。

是的，这只是一个假设，不是事实。

碰巧的是，“拥有专利”和“拥有有效专利​​”是两件不同的事情。
我读了这篇很棒的文章，法院裁定专利无效。

FB的专利总有可能太宽泛而没有优点。
现在人们会认为，如果facebook拥有专利，它将具有某些优点。 但是，从逻辑上讲，如果涵盖了先例，那么它就太广泛了，因此毫无价值。 所以这是假设与假设1直接冲突。

考虑到Facebook正在使用专利来捍卫自己，Facebook的专利更有可能是广泛的和无根据的，而不是可执行的。

结论：

请记住，这三个假设均未经检验。 如果所有这些都证明是对的-从技术上讲这是可能的，那么，“是的，使用技巧很危险。”

但是实际上，这三个假设均成立的机会太小，尤其是假设1和3在一起的时候。

因此，除非法院另有规定，否则直到并且除非法院另有规定，否则我会说使用预设（和其他vdom库）非常安全。

关于第1点，Facebook在浏览器脚本中拥有一项名为“live()函数（后来成为jQuery API中on()一部分）！

但是，不管这些假设是否有效，WordPress离开React的原因都不是WordPress对Facebook有担忧。 我引用上面问题中链接的公告帖子（突出显示我的）：

我认为， Facebook的条款实际上比公司可以采用的更为明确，而且Facebook一直是那里更好的开源贡献者之一。 但是我们有很多问题要解决，让世界相信Facebook的专利条款是行不通的。

基于此，专利带来的是感知，困惑和问题，使WordPress望尘莫及。 我认为同样的顾虑也适用于Preact，正如我之前的评论中所述。

关于第1点，Facebook在浏览器脚本中拥有一项名为“有效事件委托”的专利。 这基本上就是jQuery的live（）函数（后来成为jQuery API中on（）的一部分）！

这是否意味着他们完全发明了事件委托思想？ 我看到那里的一些引用可以追溯到1995年，那是什么意思？

@ChrisCinelli，关于在Marko案中您所谓的“似乎是指数增长的拐点”。

我相信这只是规模问题。 当一个项目有5k甚至10k Github星时，像Hackernews首页上的链接这样的单个事件一天可以带来1k星，如果是Marko，则是最近数量的20％。

Vue拥有的65k星的规模并不那么明显。 您甚至可以看到，由于明星历史记录脚本的工作原理，在某些时候它完全停止显示波动，并且直到最后都是一条直线。

这种情况并非Marko所独有，它发生在Inferno或最近出现在MoonJS上，后者是受Vue启发的微框架。 您甚至可以说，Preact似乎处于类似的位置，因为由于整个React专利戏，它最近获得了多少颗星。

您可以在下图上从与您相同的来源观察我在说什么：

时间会证明这些人是否会在开发中实际尝试该框架，在生产中使用它并在以后继续使用它。 我希望Marko以及其他所有开源库一样顺利。

至于Vue，是的，它是一个稳定的增长，没有很大的波动。 以目前的速度，它应该在圣诞节之前超越React。 至少在Github上。 :)

@aurelia呢？
网址： aurelia.io
@EisenbergEffect创建了这个。

对我来说，这是一个很棒的框架！

1. 简单约定（可以定制）
2. 纯HTML
3. 香草JS
4. 没有框架干预！

您甚至可以插入想要使用的库（jQuery，Vue.js，Preact，Ember，HyperHTML等）的插件，并教Aurelia如何使用它！

它是如此简单且基于标准，您甚至不需要社区支持，如果您真的认为社区支持很重要，那么他们也能为您提供帮助（拥有超过1万颗星）。

@aurelia的资源：

1. 介绍Aurelia
2. Aurelia博客
3. 奥雷利亚文件

看起来React已在MIT下获得了许可： https :

我想现在应该推翻决定。

我的妈呀！ React又回到了业务中。 WordPress做到了吗？ 不确定！ 现在是凌晨3点，对此我感到非常兴奋！ 你呢！

重新许可React，Jest，Flow和Immutable.js

下周，我们将在MIT许可下重新许可我们的开源项目React，Jest，Flow和Immutable.js。 我们之所以要重新授权这些项目，是因为React是网络上广泛的开源软件生态系统的基础，并且我们不希望出于非技术原因而推迟进展。

这个决定是在我们社区几周失望和不确定之后做出的。 尽管我们仍然相信BSD +专利许可可以为我们项目的用户带来一些好处，但是我们承认我们未能果断地说服这个社区。

在我们的许可证存在不确定性之后，我们知道许多团队都在经历选择React替代库的过程。 我们为流失感到抱歉。 我们不希望通过做出这种改变来赢回这些团队，但我们确实希望敞开大门。 在这一领域的友好合作与竞争推动我们前进，我们希望充分参与。

这种转变自然会引起人们对Facebook其余开源项目的质疑。 我们许多受欢迎的项目现在都将保留BSD +专利许可。 我们也在评估这些项目的许可，但是每个项目都是不同的，替代许可选项将取决于多种因素。

下周我们将在React 16的发布中包括许可证更新。 我们已经在React 16上工作了一年多，并且已经完全重写了它的内部结构，以便解锁强大的功能，这些功能将有益于每个大规模构建用户界面的人。 我们将在不久的将来分享更多关于我们如何重写React的信息，我们希望我们的工作会激发各地的开发人员，无论他们是否使用React。 我们期待将有关许可的讨论抛之脑后，回到我们最关心的方面：运送优质的产品。

我认为，有了MIT许可证以及其背后最活跃，最大的开源JS社区，React是一个绝对的选择。

我的投票现在返回React 。 -恢复了人类的信仰。

用👍投票，而不是类似的评论。

我想表达我对Wordpress的巨大感谢，感谢他参与了导致React适应变化的工作。

我仍然认为Vue将是更好的解决方案。 Vue的许多优势仍然适用，但是我想指出，我认为，初学者的友好性而不必使用构建步骤是wordpress环境中的杀手级功能。

对于质量
当然
用于vueJS

我还选择了Angular2.0 +（不是AngularJS），它拥有最大的社区，强大的开发团队，稳定而完整的生态系统。

@CrazyBBer在哪里可以找到有关最大社区Angular 2/4的一些数据？ 这将对我的博客文章有所帮助。

无论如何，结束了，React在这里停留在WordPress上，甚至作为Vue爱好者，我发现鉴于React已经编写的代码量，这种情况可能会以最好的方式转变。

@ahmadawais @gustojs的人们在Reddit上提出了一个担忧，即MIT仅涵盖版权，因此开发人员在使用React时将不会获​​得专利授权，我认为这仍然是一个问题。

同样，这句话确实让我感到烦恼：

我们承认我们未能果断地说服这个社区。

有效地说“我们没错-您的开发人员只是不了解我们”。

@ahmadawais ：我仍然认为与Vue一起使用会是一个更好的选择，因为您已经看到了一个完美的示例，说明React许可的变化无常，首先他们现在有BSD + Patents license ，然后转到MIT。 谁知道在不久的将来他们可能会切换回FB拥有的某些许可证/专利，然后所有人都会被晾干。 从一开始，Vue就已经成为MIT的一员，它比社区主导的公司要多。

加上@ atanas-angelov-dev所说的话。

那就没有必要立即切换了。
我认为Vue提供了更好的视角，但这意味着重写所有内容

啊！ 来吧人，给Aurelia一个机会吧！
它是由Angularjs团队的一位主要开发人员创建的。
您可以像Vue.js一样，从少量采用过渡到完整框架

甚至@azure门户团队都说，如果他们现在就开始，他们会选择Aurelia而不是淘汰赛！
谁知道呢？ 他们现在可能会一点一点地迁移到Aurelia。

从头开始，我知道你会喜欢的！

Nirmal4G，
您的论文听起来太卖力了，太荒谬了。
实际上，我相信整个框架都具有与您直接在您的帖子中直接链接的404页面相同的缺陷。
http://aurelia.io/get-started.html

@ bovas85没有销售能力，我甚至都不属于那个团队。 他们甚至不知道我在使用他们的框架。

@ cr101 / cc

不要凭封面判断这本书

在我不了解Aurelia之前，我已经使用了许多流行的框架。 如果必须通过平衡所有条件来堆叠它们，那么对于我的应用程序（相信我是一个大型应用程序），Aurelia排名第一，其次是Vue。

我相信整个框架都存在与您直接在帖子中直接链接到的404页面相同的缺陷。

我发布的每个链接都永远不会进入404页面。 将http重定向到https站点是github的错。 现在已修复。 看，一个bug。 告诉我任何没有错误的框架，我敢。

仅仅是在其他框架上，您就有了许多冗余的（至今仍然有用的）抽象。 W3C社区从未在其API中采用公共框架设计，因此您可以拥有很多抽象。

每个框架都非常注重向后兼容性，因此它们失去了向前兼容性，但是Aurelia不会这样做，只要您坚持HTML的W3C和ECMAScript规范，JS的代码就可以正常工作。

_如果没有Aurelia，那么我不介意坚持使用Vue。 接下来是最好的东西。

_这只是接受标准的问题，而不是创建重新发明它的新方法。

@ Nirmal4G请提供您的索赔证明或避免使用姓名。 我几乎不相信，特别是在LOC方面，Vue比hyperHTML要少。 与用vue相比，我用布局和逻辑放在一起。 尽管我什至不相信LOC是与任何事物相关的指标，但阅读未经证实的FUD对我而言似乎并不公平。

@WebReflection抱住你的马，我不是说你比Vue差。 对不起，如果我冒犯了你。

我的应用程序使用了您可以使用的所有内容。 我尝试了具有许多框架的原型，我曾经拥有的标准之一是LOC，但从视觉角度来看，这并不是出于您的原因，任何框架的性能都可以提高，但这是设计选择的名称。

我对HyperHTML进行了评估，性能令人印象深刻，没有polyfills很棒，但可悲的是，由于我的要求，它并没有取得成功。

每个框架都有一个更好的东西，我的愿望是，如果有人可以用更好的设计将所有框架中最好的框架结合在一起，那将是神圣的，但那不会发生。 因此，我必须找到一个平衡点，即框架将来可以改进自己的地方，而在将来不能改进的地方。

听到React现在将成为MIT真是太好了。
让我对此项目感到非常兴奋，很期待很长一段时间后再次开始使用WordPress，一旦React和WP API得到完全支持。 :)

让我们拭目以待，看看实际的React许可是什么。 MIT还是MIT +专利..？ ;）

我个人比较喜欢React，但发现Vue更具生产力。 我会很满意的，但是...

...考虑到社区对Vue的大力支持，我建议除了许可之外，还要考虑到这一点。

Vue似乎只是适用于WordPress的更合适的选择。

Facebook已从其诉讼陷阱中删除了4个项目。 这些现在都获得了MIT的许可：

• 反应
• 笑话
• 流
• Immutable.js

同时，Facebook的X类许可证仍然适用于：

• 反应本机
• GraphQL
• 纱
• 中继
• Atom IDE
• 以及他们制作的其他任何东西以及“公开”来源

我还是说和Vue一起去。 从长远来看，这是值得的。 无论如何，React从未对我来说对Wordpress有意义。 它是如此紧密地嵌入在PHP社区中，Vue似乎一直是最明智的选择（而且使用起来像React也不痛苦）。

同时，Facebook的X类许可证仍然适用于：

反应本机
GraphQL
纱
中继
Atom IDE
以及他们制作的其他任何东西以及“公开”来源

@TheJaredWilcurt对不起，但您可能想要从该列表中删除纱线https://github.com/yarnpkg/yarn

@ atanas-angelov-dev

Reddit上的人们提出了一个担忧，即MIT仅涵盖版权，因此开发人员在使用React时将不会获​​得专利授权，我认为这仍然是一个问题。

麻省理工学院是一个很好的许可证。 jQuery也是MIT许可的。 我希望你知道。

@vinayakkulkarni我仍然认为与Vue一起使用会是一个更好的选择，因为您已经看到了一个完美的示例，说明React许可的变化无常，首先他们现在拥有BSD +专利许可，然后切换到MIT。 谁知道在不久的将来他们可能会切换回FB拥有的某些许可证/专利，然后所有人都会被晾干。 从一开始，Vue就已经成为MIT的一员，它比社区主导的公司要多。

那不是它的工作原理。 我在Facebook上阅读了塞缪尔对类似问题的评论。 麻省理工学院获得许可后，您就可以派遣它来更改许可，或者不能。 我不是律师。

此外，我个人认为Facebook这样做是出于真诚的姿态，而不是欺骗他人。 这对我来说意味着什么。

此外，我个人认为Facebook这样做是出于真诚的姿态，而不是欺骗他人。 这对我来说意味着什么。

那不是很合乎逻辑的声明。 您之所以要奖励一个团队，是因为他们停止做负面的事情，而不是奖励那些从来没有做过负面事情的团队。 另外，如上所述，他们在其他类似项目中仍在使用X类许可，这对我而言不是真诚的标志。

Vue有很多更温柔的学习和采用曲线。
从一开始，这就是WordPress的主要基础思想。

@ahmadawais我知道

为了保持话题，我不得不说，我也看到了很多使WordPress在Vue中出色的地方-以我的拙见，没有其他合适的库像Vue一样容易学习和使用。

Facebook显然拥有React的专利

您认为React的哪一部分获得了专利？ （React的任何内容都没有专利权，请首先尝试进行研究）显示链接，而不仅仅是“明显地” ..，这种评论根本没有帮助。 如果您想推荐自己喜欢的库，请以正确的方式进行操作，展示其优点，而不仅仅是散布FUD。

如果React没有背后的专利，为什么为什么要最初转向BSD +专利呢？ Facebook没有说出他们是什么，或者不是。

为什么要搞乱两年的许可，而只对他们的部分投资组合进行更改，一贯表示他们不会更改许可，并说“只要处理它，我们不在乎您是否使用它”。

为什么要从“新”许可中排除React Native，GraphQL等？ React的未来版本将切换到什么？ 当您拥有Facebook的两层许可时，这并不能保证，这取决于谁抱怨它。

如果部分React Native代码被卷入React怎么办？ 如果GraphQL实现进入代码库，您将站在哪里？

Facebook的这一举动提出的问题多于其答案，仍然意味着对React的每次单独使用都可能对真正的开源项目构成潜在风险。

只需采用PHP世界中已经建立的没有任何负担的库-Vue。

@bjrmatos https://www.google.com/patents/US20170221242我想！

Vue又有+1。 Facebook在整个项目中仍然使用两个许可证。 这不好。

@PericlesSouza您显然只是忽略了像facebook这样的公司为改善事物和推动网络发展所做的巨大努力，如果您只是阅读有关MIT变更的帖子，那么您的所有问题都可以得到解答。 我真的不知道您为什么仍然对MIT许可证提出这种非理性的关注，随着更改，React处于与其他任何“ True Open Source”项目相同的位置（我不知道您所说的True True Source项目顺便说一句）。

@Raymonf好吧，基本上任何现代框架都已经侵犯了该专利（包括Vue），因此无论您使用React，Vue还是实现了链接中描述的概念的其他框架，任何人都处于同一位置（基本上是任何Web如果该项目已经侵犯了其他公司拥有的两到三项专利，您会惊讶地知道当前公司已对哪种事物进行了专利授权）。 如果您真的对此感到担心，那意味着您不能使用任何以这种方式更新UI的框架。因此，在这种法律背景下，没有更好或更坏的选择。

我不想再次参与这类对话，因为不可能达成协议，所以我将停止发表评论。 React社区对MIT的变更感到高兴（甚至更倾向于原始许可证的反对者）

决定给Wordpress团队带来好运，解决有关React BSD + Patents许可的主要问题，现在是他们的工作。

因此，Facebook最近更改了对React的许可。 这是否意味着WordPress将继续使用React或仍然更改默认的前端框架？

@bjrmatos这根本不是真的

基本上任何现代框架都已经侵犯了该专利

例如，hyperHTML不使用虚拟DOM，而是通过常规回调调用（不可以专利）直接使用DOM API（不可以专利）和唯一的区分算法来将c hildNodes：after节点列表中的数据基于Levenshtein距离（不可专利）和最少的剪接操作（不可专利，我写的是ISC ）。

尽管目前我认为该线程已过时且毫无意义，但我不理解继续散布FUD的必要性。 如果您做出选择并且喜欢它，则没有理由告诉其他所有人他们做错了事或遇到了同样的麻烦。 我希望我们可以就此达成共识。

@noncototient这是一百万美元的问题，不是吗？ 💯

我只是在这里退订，因为讨论变得毫无意义。
我认为许多优点已经向前发展，对于每个认真阅读此问题的人来说，这都是一次学习的经历。

我同意，这是毫无意义的。 我建议锁定此线程（或仅供贡献者使用）。 关于这个问题已经有足够的反馈，现在已经到了只能引起非建设性论点的地步。

这个问题会解决吗？
似乎@WordPress现在不希望迁移到新的JavaScript框架。 🤔

对我来说，我个人喜欢@vuejs。 但现在看来，这并不重要。 😅

就个人而言，无论如何我都会更喜欢Vue。

对我来说，我相信还有许多其他人，这与许可无关。 这只是远离React的借口。

Marko强大而简单。 我们目前正在完成对具有50,000种产品的动态网上商店的完全重写，并且它的功能非常强大且功能非常强大。 走这条路，不要回头。

Marko很好，但是Prarko的大小要小100字节（压缩），在自优化测试中速度要快0.01％，因此，即使没有其他人这样做，我们也必须使用它。 尽管明天Plarko将发布，并添加了Fibre，这使_everything_变得多余。

抱歉，但这就是该线程其余部分的处理方式。

让我们拭目以待，看看实际颁发的许可是什么，Facebook的两层许可的含义是什么，以及一旦对问题进行彻底调查后，WordPress团队将做出什么样的决定。

我的意思是，最初它是在征求社区喜欢的引擎方面的意见。 这似乎是人们在发布的内容，但是有些人只是跳过了所有人，以发送与要求的内容一致的评论。 有点奇怪

这里提到的所有库/框架都很棒。 有些比其他方案更适合某些方案。 每个人都有自己的拥护者，根据他们的开发周期，每个人都会在性能/功能方面超越其他人。

就像我在大多数项目中所做的那样，也许从一个简单的问题开始：

1. 我们需要SPA框架吗？

如果答案是肯定的，请详细说明原因。 这为您提供了一套评估潜在候选人所依据的标准； 也许用于服务器端渲染，也许用于路由等。

如果不是，请问下一个问题：

1. 我们真的需要模板引擎吗？

VanillaJS拥有地球上最大的社区，并且没有许可问题。 它也符合标准；），以及ES6模块，可能会为核心开发提供合适的基础，并具有插件支持功能，以使用_template_引擎（例如React，Vue，Preact，Aurelia等），无论将在以下哪个版本中发布未来几年，根据开发人员的要求。

Matt Mullenweg发表了他的回应...

看到Facebook即将放弃我上周写的专利条款的消息，我感到非常惊讶和兴奋。 他们已经宣布，使用React 16的许可将只是普通的MIT，而无需增加专利。 我为Facebook采取这一举措表示赞赏，并希望在其所有开源项目中重新审查专利条款的使用。

基于他们以前的立场，我们决定退出React的决定引发了WordPress世界中许多有趣的讨论。 特别是对于Gutenberg，可能有一种方法允许开发人员在他们选择的库中编写Gutenberg块（Gutenblocks），包括Preact，Polymer或Vue，现在React也可以成为官方支持的选项。

我想对到目前为止参加讨论的每个人表示感谢，我非常感谢。 此处以及关于Hacker News和Reddit的评论中的激烈辩论和讨论非常有利于人们带来的热情和了解许多不同观点的机会。 Facebook更好地倾听。

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

@ahmadawais @m

基于他们以前的立场，我们决定退出React的决定引发了WordPress世界中许多有趣的讨论。 特别是对于Gutenberg，可能有一种方法允许开发人员在他们选择的库中编写Gutenberg块（Gutenblocks），包括Preact，Polymer或Vue，现在React也可以成为官方支持的选项。

这种情况似乎对每个人都是胜利。 让我们拭目以待吧。

正好接近这个问题现在..它只是去看看这个世界是如何善变是..悲伤地看到人们没有他们的话住。

[编辑：由于令人反感的言论而被删除]

祝所有需要使用古腾堡（Gutenberg）以及学习React的沉重学习曲线的人都好运。

和平。

👋我认为我们在这里进行了很多讨论。 我要感谢所有关心这个话题的人。 恕我直言，看来我们现在拥有的所有选项都是不错的选择。

如果我们最终得到了一个更好的框架不可知API，那么人们将能够在其应用程序中使用他们想要的任何JS框架。 有了MIT许可证，React在拥有良好（读取兼容）开源许可证的任何其他库中的核心地位都很高。

🎯如果您正在扎根某个特定的JavaScript框架，或者已经建立了一个（核心团队），我建议您为WordPress开发人员构建实际示例，以便人们可以开始尝试在他们基于WordPress的应用程序中使用首选JavaScript框架的想法。建立。

我现在要关闭这张票。 并希望为WordPress作为平台和社区的成功做出更多贡献。 期望这里的每个人都如此。 我真的相信，对于使用WordPress软件的人来说，这将是一次过山车冒险。

从现在开始的某个时候，我们可能会像几年前那样，最终对软件进行改进，以使其用户（约占互联网站点的30％）更容易使用。 我和所有人一样都在这里扎根WordPress！

干杯!

Matts的评论并不清楚，是否决定退出React。

首先，Facebook将使用的实际许可证尚未发布，因此，假装将其全部销毁并不是明智的举动。

其次，它没有解决Facebook遵循的两层许可：React可能是MIT，但是React Native将是+（未公开）专利。

那么..两者共享的组件又如何呢？

那React中使用的React Native代码又如何呢？ Fiber是否将在两个不同的许可证之间共享？ 还是GraphQL代码进入了React？

如果WordPress沿React路线走下去，而所有这些相关的Facebook项目均以不同的许可证发布，那么WordPress会发生什么，然后Facebook决定React的某些方面实际上受到了React Native专利授予或Fiber的约束。专利授予？

认真地，对此要非常仔细地考虑。 当有大多数人更喜欢使用的替代品却没有这个问题时，为什么还要冒险？Vue。

我不会相信随风而变的许可协议，而不是经过深思熟虑。 Facebook的律师可以一时兴起。

坚持使用真正的开源。

@PericlesSouza许可证将正是人们从博客文章的描述中所想象的：标准的MIT许可证，仅此而已。 React不依赖于React Native。 两者共享的片段都存在于React项目中，而不是存在于React Native中。 一旦我们的团队有时间提交更改，React及其FB拥有的依赖项将在MIT下可用。 我们没有计划任何有趣的事情。

@sophiebits

您在Facebook工作。 如果您不是获得授权代表Facebook发言的律师，则您的主张无关紧要。 甚至编写什么代码都没有关系。 抱歉。

“想象中”的许可证不会在法庭上站出来。

例如，您能否明确说明Facebook为什么采用专利授权，专利是（或没有），或者为什么他们说现在在更改专利而没有说“ IANAL”（我不是律师）？

两者共享的片段都存在于React项目中，而不是存在于React Native中

但是，您可以凭法律保证说吗？ 没有？

一旦我们的团队有时间提交更改，React及其FB拥有的依赖项将在MIT下可用

删除了哪些部分以允许React在MIT下发布？ 您已经使用了哪些可能与MIT不兼容的_non-FB拥有的依赖项？ Facebook的律师会保证所有内容都确实符合MIT吗？ Apache Software Foundation认证需要多长时间？
。

似乎我正确地强调了代码在两个显然具有两层许可的项目之间共享。

你在扭曲我的话。 在React和React Native之间共享的代码将在MIT下获得许可。 您认为的所有Fiber都将获得MIT的许可。 React不会包含或依赖BSD +专利或您如此鄙视的任何其他专利授权许可的任何代码。 我们不会从React移除零件。 我知道，React唯一的非FB拥有的依赖项是MIT之下的对象分配。

我不建议您将我的话作为法律保证。 我们俩都知道，我在这里的评论本身不会更改React的许可证。 您可以选择持怀疑态度，而不必现在相信我，但是在一两天内，您会发现我在说的是真的。

@sophiebits

我不会歪曲您的话-我尊重您所做的工作以及您准备在这里工作的意愿。

我只是在说，除非并且直到我们得到Facebook的法律承诺，公司的授权人员，外部开放源代码机构的验证，否则我们仍然处于起步的状态-没有人可以确定实际的法律情况是，正如您同意的那样：

我不建议您将我的话作为法律保证。 我们俩都知道，我在这里的评论本身不会更改React的许可证。

和：

您认为的所有Fiber都将获得MIT的许可。

我认为Fiber没关系，这完全取决于Facebook律师和申请专利对Fiber的定义。

当与React共享代码时，为什么为什么React Native目前打算获得与React不同的许可？ 这不会使MIT许可证无效吗？

我还注意到您没有提到GraphQL。 我还错过了什么吗？

React许可崩溃的全部要点是缺乏法律确定性。

@sophiebits

我注意到您对我的观点所做的修改：

React不会包含或依赖BSD +专利或您如此鄙视的任何其他专利授权许可的任何代码。 我们不会从React移除零件。 我知道，React唯一的非FB拥有的依赖项是MIT之下的对象分配。

但是您说过要从React中删除部分，并将在“未来几天内”检查代码。

一旦我们的团队有时间提交更改，React及其FB拥有的依赖项将在MIT下可用

然后您忘记了IANAL ... :-)

哦，实际上您说的很长：

我不建议您将我的话作为法律保证。 我们俩都知道，我在这里的评论本身不会更改React的许可证。

再来一次：

React许可崩溃的全部要点是缺乏法律确定性。

我同意仍然没有法律确定性的观点。 但我个人认为，该线程已运行完毕； 最好仅将其标记为贡献者，并等到实际许可发布后，团队才能进行评估。

现在取消订阅。

请不要转储React，Facebook做出了他们的决定https://thenextweb.com/dd/2017/09/25/facebook-re-licenses-react-mit-license-developer-backlash/

@vinayakkulkarni虽然我了解对某件事充满热情，但这并不是像您一样发表评论的理由。 公共空间（GitHub评论是）对任何人来说都是安全的地方。 您的类比令人反感，因此已被编辑。 将来，请认为所有性别，所有类型的人都在使用此空间，以及您的言论可能会冒犯他们。

@sophiebits只是一个小提示，感谢您加入此线程，非常感谢。

这可能是一个新线程的主题，但不幸的是，MIT许可证（甚至是标准许可证）并未解决专利的“不确定性”问题，这导致了WordPress较早做出决定。

MIT许可证是否授予您使用专利IP的权利？ 阅读律师对此有何评论： MIT许可证，逐行

— Frans Bouma（@FransBouma） 2017年9月23日

麻省理工学院显然没有授予您专利许可。 Facebook在React中拥有专利，据称它已授予您当前的许可。 使用当前的许可证，至少您知道您被授予了任何许可证，并且知道什么条件吊销了它们。 使用麻省理工学院，您甚至都不会获得许可授权。

专利授权意味着尽管有相关的专利（或授权了什么？）。 除非没人知道专利是什么。 Facebook没有透露，甚至没有透露何时授予他们，也没有透露宣布取消授予的时间。

无论我个人还是WordPress团队可能认为这意味着什么，似乎仍然存在着它在React上拥有（至今未公开的）Facebook专利的法律状况的困惑，任何使用它的人[[或-可能不需要]]在今天起诉Facebook时或仅在获得新许可证后使用React时就不必担心违反。

再有，可能有也可能没有，问题是不确定性，这就是我的建议没有解决。

提醒一下，大多数对此线程发表意见的人都希望基于Vue的解决方案。

造成这种情况的原因有很多，但不仅限于Vue没有许可混乱的事实（Facebook的两层许可政策仍然存在）：

1. Vue是从头开始设计的，具有功能孤岛，可以进行增量添加，从而可以逐步增强代码库。

2. 另外，并且可选地，它提供了官方支持的状态管理和路由解决方案。

3. 它支持用于HTML的多个处理器，从而使开发人员可以选择模板语言-HTML，JSX，Pug等或呈现功能。

4. 单一文件组件和作用域CSS（手写笔，SASS，SCSS，PostCSS，CSS组件）-以最简单的方式。 从字面上看，只需将scoped属性添加到组件的Style声明中，然后完成。

5. 支持内置的计算属性（带有备注）（即没有依赖项，例如MobX）。

   6+。 比React更出色的性能，更低的学习曲线，在PHP社区中的更高采用率，例如，请查看https://unpkg.com/vue包含Vue并开始编码。

Vue更适合WordPress。

反应：

76,364 Github星
571未解决的问题（！）
4325已解决的问题
178个开放拉取请求（！）
5,644个关闭拉取请求

Vue ：

68、246个Github星星（轨迹将在圣诞节之前超过React）
62个未解决的问题（对错误修复的响应更快，添加了所请求的功能）
5,629已解决的问题
17个打开请求
863已关闭的请求

@Meligy

麻省理工学院显然没有授予您专利许可。 Facebook在React中拥有专利，据称它已授予您当前的许可。 使用当前的许可证，至少您知道您被授予了任何许可证，并且知道什么条件吊销了它们。 使用麻省理工学院，您甚至都不会获得许可授权。

专利授权意味着尽管有相关的专利（或授权了什么？）。 Facebook没有透露，甚至没有透露何时授予他们，也没有透露宣布取消授予的时间。

这就存在着大公司不完全开放源代码的问题。 最终，无论现在还是将来，无论开发团队的意图如何，他们的律师都会推翻一切。

Facebook将其+专利许可构架为对“某物或任何东西”的积极防御，现在我们被要求相信，React实际上并不存在完全相同的“某物或任何东西”，但是，对于React Native和GraphQL来说_still还是_。

当Facebook再次更改其对React的许可和意见时，Automattic能否保证自己会自己承担责任并承担React，fork，自行开发它？

对我来说，Facebook似乎为WordPress设置了陷阱。 全球所有网站中有25％是热门网站。

请将此线程标记为_contributor only_ ASAP，不但无需完全取消订阅，还可以阅读任何贡献者的结果，而不仅仅是FUD和推测。 谢谢。

@WebReflection Wordpress的利益相关者不仅是其核心开发人员，而且是扩展社区。

@PericlesSouza引用了Github的星星并不代表什么。 而且这个问题被人们抛出荒谬的说法所推倒，并不意味着我们应该忽略以下事实： https ://npmcharts.com/compare/react，angular，@ angular / core ，ember-cli，vue

Vue只是雷达上的亮点而已。 绝大多数人使用React，并且肯定也不会同意您的要点。

@PericlesSouza引用了Github的星星并不代表什么。 而且这个问题被人们抛出荒谬的说法所推倒，并不意味着我们应该忽略以下事实： https ://npmcharts.com/compare/react，angular，@ angular / core ，ember-cli，vue

Vue只是雷达上的亮点而已。 绝大多数人使用React，并且肯定也不会同意您的要点。

NPM统计信息？ 您的意思是说，他们接受的统计数据完全相同，因此每一个请求都将检查您是否使用最新版本或通过每个依赖项作为下载请求？ （当人们嘲笑他们“每月数十亿个包裹”的说法时，他们在博客上承认了这一点）。

如果您想走这条路，那么每个人都在使用jQuery。

对于不具有依赖关系失真字段的软件包，请尝试使用数字：

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

与您选择呈现的图片完全不同。

或如何使用网站：

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

由BuiltWith统计支持：

哦，我将把这张照片留在这里-从团队本身问社区开始。 您应该听他们的话，而不是轻视他们。

@PericlesSouza比较vue-cli和create-react-app没有意义，因为还有其他非常流行的React构建工具，例如Next.js和GatsbyJS 。
许多React开发人员甚至没有使用CLI，而是像Gutenberg和Calypso一样使用他们自己的自定义Webpack构建脚本。

现实情况是，React生态系统比Vue的生态系统大得多。 以Vue.js的Material UI为4339星，而React的Material UI为29078星。

一个本机选择框组件，提供与Select2类似的功能，而没有jQuery的开销： Vue select具有1,348星，而React select具有8,493星。

@PericlesSouza ， @drcmda ，所有这些数据都可以通过很多方式进行争用，即使是带有cli的npm统计数据，如果添加AngularCLI和EmberCLI，您将看到完全不同的数据，这并不意味着什么：

资料来源： https ://npmcharts.com/compare/vue-cli，create-react-app，@ angular / cli ，ember-cli

来源： https ：//w3techs.com/technologies/comparison/js-angularjs，js-react，js-vuejs

资料来源： https: //insights.stackoverflow.com/survey/2017#technology -frameworks-libraries-and-other-technologies

但是，这次对话不应该是关于使用最广泛的框架，而是对整个Wordpress环境更好。

@PericlesSouza @willgm规则适用于两者。 两者都以完全相同的方式计算，声称这是不公平的，这很不明智。 紧扣可选的CLI或暗示性网站，将“喜欢”和“星级”计​​数为无效。 甚至stackoverflow都是高度主观的，直到今天我还没有听说过“ builtwith ...”站点，并且CLI统计信息很好地反映了使用CLI的人数（大多数人没有）。

来自最明显和最重要来源的数据，反映了在相同确切环境下的实际生产环境，是您不希望我得到的一个统计信息，不会改变其方式。

但是，这次对话不应该是关于使用最广泛的框架，而是对整个Wordpress环境更好。

我认为您知道哪一个更适合。 您认为每天有400.000个人从npm脱颖而出，这都是错误的。 Vue可以自己竞争，实际上不需要暴民冲入问题跟踪器。

@PericlesSouza @willgm规则适用于两者。 两者都以完全相同的方式计算，声称这是不公平的，这很不明智。 紧扣可选的CLI或暗示性网站，将“喜欢”和“星级”计​​数为无效。

不。 React有16,800个依赖软件包，它们使数字出现了偏差。 NPM承认，由于依赖关系检查，漫游器，镜像或其他任何原因，调用URL时，它们算作下载的全部是200结果代码。 顺便说一句，他们还说，在中国，大多数Vue受欢迎的下载都是从镜像下载的，没有计算在内。

从您对“紧贴”，“建议性网站”，“无用”等语言的使用来判断，您对此主题没有任何实质性的争论，但是，根据团队的要求，我已经发布了使用Vue的正面信息（请参阅上方）。

数星-其他人在指出React的成功时也这样做，但是您是否谴责它们用来表示Vue受欢迎程度的价值？ 您也没有提到太多未解决的问题（ 571 ），以及仍待处理的相当数量的未完成的拉取请求（ 178 ），与Vue社区在错误修复和修复方面的更高响应能力相比在建议使用React时，添加功能是一个值得关注的正当理由。

这使我想到：

盘点喜欢-好吧，这是整个话题的重点，正如团队开始并向社区提出的那样-我猜您根本不喜欢结果。 这又是一个非常确定的结论：

不。 React有16,800个依赖软件包，它们使数字出现了偏差。

@PericlesSouza您如何得出这个结论。 这意味着它的含义：16.800个软件包在package.json中声明了React作为其依赖项。 不是机器人，不是中国，...软件包。 Vue大约有2580个，这意味着它的生态系统和用户群要小得多。 我们为什么还要争论这个？ 它直接由使用情况统计信息反映出来。 更新，真人或机器人，它适用于两个软件包。 除非您认为机器人出于某种原因故意跳过Vue。

在跟踪器中选择一个对待每个程序包相同的程序包意味着零意义。 另一方面，点赞次数意味着XY社区知道在哪里投票。

@dcrmda

我认为他的意思是，每次您安装一个对React有依赖关系的软件包时，都会打NPM来检查版本和依赖关系，NPM会将其计为该软件包的download ，即使不是已下载。

如果那是他的意思，那么他是正确的。 NPM明确表示他们这样做； 他们将自己的“方法”描述为“故意天真”（他们还提到，由于它们没有确定请求内容的机制，机器人和镜像程序可能会使数字产生偏差，他们只是计算在内）。 而且React具有更多的依赖包，因此这种效果更加明显。

至于很多依赖包-是的，React是一个较旧的框架，它拥有更多功能，并且需要它们。 我使用React和Vue进行开发，并且使用Vue时，由于核心已经相当完善，因此您通常需要较少的附加软件包，并且官方的Router和Vuex也遵循低依赖性的理念。 Vue本身不依赖于任何软件包，React依赖于一些软件包。 他们在这方面有不同的方法。

另一个例子是人们倾向于在Bootstrap和React之间使用集成包，或者使用样式组件，类名之类的库。使用Vue通常不需要，尽管这样的项目也确实存在。 我发现使用Vue更加容易，因为我可以直接使用组件范围的CSS，而无需其他库或配置，并且可以根据需要编写自己的与CSS框架的简单集成，而不是导入整个集成库然后尝试树-淘汰我不需要的75％。

@PericlesSouza，您错过了“ Pros of Vue”帖子中的一些非常相关的项目：

命名为Slot以允许可重用​​的模板组件，例如标准Forms，Inputs，Layouts等，这比Reacts对子代的使用更为灵活。

具有可选功能的条件组件，可以保持本地状态，而不会破坏非活动组件。

HTML元素“是”字符串模板的Vue组件语法，可防止提升呈现的HTML元素而导致无效的HTML。

一种使用道具的数据流方式，但是添加了一个大大简化的“发射”和“事件总线”流，用于通知或更新同级或父级。 这对于以下之间的互通很有用：

一个页面上有多个Vue实例，用于控制特定区域。 此技术对于动态仪表板或可插入窗口小部件以及内存管理很有用。

全局和本地组件以及自定义指令注册。

除计算属性外，还可以链接的过滤器。

以上所有内容都是核心Vue库的一部分。

React是一个很棒的框架，我很喜欢使用它，但是我个人认为Vue更适合于此建议的用例。

@mcquiggd

是的，我很着急，没有时间完整列出Vue的优势。

有趣的是，您提到React具有依赖项，因为我注意到它依赖于fbjs 。 我特别强调了一些部分，如果人们正在考虑使用React，那应该引起警惕，它采用Facebook的两层许可策略，同时在不同许可项目之间共享代码。 提示有关它的一切令人担忧，尤其是当您看到依赖于它但具有不同许可证的项目列表时。

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

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

目的

为了使Facebook更容易共享和使用我们自己的JavaScript。

注意：_如果您在这里使用代码并且您也不是Facebook项目，请做好准备准备不好的时间_。 _此库是在考虑我们的用例的情况下发布的，并不一定意味着要由广大公众使用。 除非它们符合我们的需求，否则我们可能不会接受您的功能请求。

571未解决的问题（！）

现在是338。 （我花了几天的时间清理它们。）

在过去的几个月中，React团队忙于准备一个新的，向后兼容的React 16版本。 这是我们有史以来最大的发行版，因此我们没有在问题跟踪器上得到答复，所以对此我感到抱歉。 事实证明，React 16还解决了许多此类问题。 :-)

我想指出的是，在这338个问题中，大部分都是功能请求和讨论。 搜索错误标签会给我约60个问题。 鉴于目前React生态系统比Vue更大，人们遇到更多的极端情况和不一致之处，并展开更多讨论也就不足为奇了。 他们还期望React可以填补浏览器的更多不一致性，因此许多错误都与缺少这些错误有关。 此外，我们将文档保留在同一存储库中，因此其中许多问题都与文档有关。

我希望这能使您了解为什么我们的发行数量往往比Vue高。

有趣的是，您提到React具有依赖项，因为我注意到它依赖于fbjs。 我特别强调了一些部分，如果人们正在考虑使用React，那应该引起警惕，它采用Facebook的两层许可策略，同时在不同许可项目之间共享代码。 提示有关它的一切令人担忧，尤其是当您看到依赖于它但具有不同许可证的项目列表时。

不幸的是，这是毫无根据的FUD，是句号。 我不确定您传播它的动机是什么，但是React已被许可为MIT，其中包括React依赖的任何代码（例如fbjs）。 这里没有偷偷摸摸的计划。

您可以在发表评论的五天前在https://github.com/facebook/fbjs/commit/c69904a511b900266935168223063dd8772dfc40中亲眼看到fbjs许可证也已更改为MIT。 几天前发布的React 16版本不包含单个非MIT字节。

其他项目依赖fbjs但拥有不同的许可证这一事实是完全不相关的，就像您的应用程序代码可能不是MIT而是取决于Vue无关紧要。

PS：我认为Vue很棒，而且我不想将React推向任何人。 但我想确保我们以事实为基础进行讨论。 :-)我们总是乐于接受批评，我敢肯定Vue和React都有相互学习的地方。

所有这些都是令人兴奋的话题。

我不得不问-为什么要一个框架/库？ 如前所述，Web组件标准似乎提供了ReactJS，Vue和其他组件所提供的内容（因为该标准不存在）。

您可以将Redux之类的状态库与Web组件配合使用。 与路由库相似。 SSR并不是像Web组件那样开发的，但是那里也有人在工作。 React的最大价值部分在于它周围的各种支持库-使用平台不一定会丢失它们。

XXX框架通过平台Web组件为您提供了什么？

确实令人兴奋...

到目前为止，React的第四次许可。

1. 最初是Apache 2.0。 应该没事吧？ 怎么了
2. 然后是BSD +专利。 在不公开专利权存在或不存在的情况下。
3. 然后稍作修改，据称是为了取悦Google。 没有任何关于为什么的细节。
4. 现在的MIT，具有未指定的React重构功能，但不适用于直接相关的项目，例如React Native，GraphQL等...，以及带有公共描述的共享依赖项：“使Facebook可以更轻松地共享和使用我们自己的JavaScript。首先，这将使我们能够发布代码，而不必过多担心代码的位置”

显然，这完全不用担心。

[编辑被塔米·李斯特（Tammie Lister）删除：这样的个人标注是不可接受的]

@PericlesSouza您可以说我们不应该被信任，因为以前的许可证令人困惑。 如果这是您的观点，那是有效的。 但是许可证现在不应该引起混淆。

React是麻省理工学院。
它的依赖项fbjs是MIT。
React和React Native共享的代码（已经并继续存在于React回购中）是MIT。
包括其所有依赖项在内的React是MIT。
使用React不一定需要创建React App，但是MIT也是如此。
中继和graphql-js不需要使用React，但它们也是MIT。

我们发布了具有新许可证的React 16.0。 验证这一点很容易。
我们还发布了带有MIT许可证15.6.2的React 15.x的新版本。
我们也计划在MIT许可下发布所有将来的React版本。

此外，该线程中的另一位Facebook员工承认，React（MIT为16？什么为<16？17+？最好仔细观察该package.json）和React Native共享代码，因此需要重构（然后编辑她/他的评论）在引用后删除该语句）。

我是那个工程师。 （她）

您评论了https://github.com/WordPress/gutenberg/issues/2733#issuecomment -331737418，然后我回答了https://github.com/WordPress/gutenberg/issues/2733#issuecomment -331738521。

这是我的电子邮件客户端中记录的两个评论的原始内容：

这是目前的内容：

在我发表评论后，您将评论编辑了更长的时间，包括其他问题：

删除了哪些部分以允许React在MIT下发布？

这不在您的原始评论中。 因此，为了回应您的修改，我编辑了我的评论以添加：

我们不会从React移除零件。 我知道，React唯一的非FB拥有的依赖项是MIT之下的对象分配。

然后，您认为适合在以下评论中给我打电话。 我敢于编辑评论以解决您在编辑中添加的问题。 我没有删除或编辑有关React和React Native共享代码的任何声明。

-

请停止给我加油。 好累

@youknowriad您是否愿意锁定此线程？ 我无法想象这里会发生更多富有成效的讨论。

如果这里的任何人仍然合法地关注许可证，请随时与我联系，我将尽力澄清。

然后，您认为适合在以下评论中给我打电话。 我敢于编辑评论以解决您在编辑中添加的问题。 我没有删除或编辑有关React和React Native共享代码的任何声明。

显然，我回答了您的编辑，是您的问题吗？

无需费力，只需Facebook，React开发团队和许可的开放性和一致性，而且由于Reacts中的四种许可模型的寿命相对较短，因此很遗憾，您的（当前）职位也很缺乏。

暂时搁置许可：再次，React今天提供了Web组件以外的东西吗？ 假设您仍将在两个版本中都使用支持库（即Redux）。

借助Web组件，WordPress可以创建比跨各种前端框架/库使用的元素更多的元素。 这将允许最终用户使用React，Vue，Angular或他们用来“插入” WordPress组件的任何前端。

@sophiebits不确定现在要回复哪个版本的帖子，所以我将等待，看看它最终变成什么样。 实际上，这与React非常相似。

@布莱恩·麦克布莱德

您的观点很不错，我认为它是在线程的较早版本中提出的-“为什么不使用普通javascript”，基于标准，完全兼容。

嗯

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

就像我说过的人一样，如果您使用React，请非常注意您的版本控制。

是的，我们从许可证更改之前打开的拉取请求中意外提交了三个文件头错误的文件。 没有一个是已发布的版本（也不能是-一个是单元测试，两个是网站的一部分）。

发生错误。 发现问题后，我们对其进行了修复，并向CI添加了一个脚本，以在将来验证是否不再添加任何意外引用。 您可以在该提交中看到它。

我认为自由软件项目应该考虑的另一件事-Facebook从使用React中受益。

但是，Facebook的价值观通常与自由软件运动的价值观不符-从不道德的用户操纵到对网络中立性的攻击（“自由基础”），无法删除数据，无法阻止数据收集，审查制度，围墙花园，回音室等。

[Facebook]就像当我的兄弟曾经让我拳打脚踢并问：“你为什么要拳打脚踢？” 然后他会告诉我妈妈那不是他的错。

正如我多年来一直在关注Facebook一样，我越来越接近得出这样的结论：我不再希望以任何方式支持该公司，因此我个人不使用FB软件。

我读过一本关于React的书，从编程的角度看，它看起来很棒-但是替代方案也很棒，而且它们并没有带来支持Facebook的负担。

我认为自由软件项目应始终首选独立的自由软件库。 WordPress的替代品很多，包括Vue，Web组件，Ember和Mithril。 Vue在PHP社区中拥有强大的支持，并且没有任何道德上的问题，因此看起来很合适。 如果仅用于仪表板，可能值得一看比JavaScript更有趣的东西： Elm 。

它不应该与当前流行或时尚的事物有关，而应与直接或间接为下一代提供最大技术自由的事物有关。

只是要考虑的另一个想法...

感谢所有在进行尊重的交谈时发表意见的人。 我也想补充一个特别感谢@sophiebits，@gaearon，@布雷克-纽曼和其他人代表谁好心花时间回答问题的项目。 非常感谢您的知识，我们将永远欢迎您的知识。

此后，对话已进入＃core-js Slack频道中的JavaScript会议，这里有一个不错的摘要。 如果您有兴趣参加这些讨论，我们邀请您加入我们。 另外，我们有两种互操作性方法可以使用贡献，测试和反馈：＃2463和＃2791。

这样一来，该线程即可正常运行。 我们已锁定问题，但我们鼓励您在上述场所继续进行对话。

该主题引起了一些不错的讨论，但是其中一些表现出不可接受的行为并已被编辑。 重要的是要记住， https：//wordpress.org/about/etiquette/适用于任何WordPress项目，我们不会容忍违规行为或实施违规行为。 谢谢大家，我们以体贴和尊重的方式为对话做出了贡献。