最近，Qwintry团队开始在我们所有新旧项目中积极迁移到Vue.js：- 在基于Drupal的旧系统上（qwintry.com）
- 在我们全新的，完全重写的qwintry.com线程中（Yii2 / Node.js上的后端）
- 在我们的B2B系统中（由Yii2提供支持）（logistics.qwintry.com）
- 在我们所有的小型内部和公共项目中（主要在后端使用PHP和Node.js）
为什么我们的程序员选择了Vue.js，开发部门的负责人说Qwintry LLC。安东·西达辛（Anton Sidashin）➔关于我们的简要介绍：Qwintry项目在全球有500万客户使用，我们有两个使用我们自己的云软件的仓库（在美国和德国），就访问者和出发者的流量而言，我们是美国最大的邮件转发器之一。我们帮助人们在美国的在线商店购买商品并通过我们的个人帐户管理包裹，并且可以大大节省国际运输费用。我们使用自己的IT平台和供应链以优惠的价格提供优质的国际交付。
我们在客户家门口提供的包裹-来自客户的评论Qwintry具有相当大的代码库，主要由PHP和JS（用于移动应用程序的Swift和Java）组成。我们在React，Vue.js和Angular2上构建了具有相同功能的测试应用程序（即我们的计算器）后，决定使用Vue.js。 React.js
在过去的一两年中，React的受欢迎程度急剧上升，现在，对于那些想要在前端编写比三行代码段更复杂的东西的JS开发人员而言，它也许是默认选择。我们在React上看到了几个SPA和动态小部件，我们测试了React Native（用于iOS）和Redux。我认为，就状态感知而言，React是JS世界的一大进步，它向许多人展示了以一种实用，实用的方式实现真正的函数式编程。我还认为React Native很棒-从字面上改变了移动开发的整体格局。对我不利的缺点：
通常，清洁，免疫和意识形态主导着务实的方法。
不要误会我的意思。我欣赏render（）方法的纯净和简单-毫无疑问，这是一个在实际开发中有效的好主意。我在谈论其他事情。我认为，当您的公司中有1,000名开发人员时，这种级别的严格性和整洁度很有用-大约在同一时间，您决定开发自己的语法以将所有PHP代码转换为静态类型。或者，当您是决定理解JS的Haskell开发人员时。但是大多数公司的开发人员更少，预算和目标也与Facebook目标不同。我将对此进行更详细的介绍。JSX很烂
等一下 我知道 这是“只是带有特殊语法的纯Javascript”。我们的人在素描和Photoshop中绘制设计，然后将其转换为HTML，他们的截止日期很艰苦，现在他们正在制作这种表格，将其包装在多个div中-现在-鼓是干净且“简单”的ES6。将某些设计应用于React组件并不是一个源泉，因为JSX缺乏可读性。无法将好的旧IF放入HTML代码块中是不好的，请不要信任React爱好者说“ if（）是上个世纪，现在所有普通程序员都使用三元运算符”。让我向您保证：在您阅读和编辑JSX的那一刻，JSX仍然是一堆HTML和JS，即使后来被编译成纯JS。<ul>
{items.map(item =>
<li key={item.id}>{item.name}</li>
)}
</ul>
许多开发人员认为（并且我同意他们一段时间），这样的语法限制将使它们更强大，并帮助他们编写更多的模块化代码，因为JSX（开箱即用）的限制迫使您将代码片段放入小型辅助函数中并在内部使用它们render（）函数，正如其他人建议的那样：stackoverflow.com/a/38231866/1132016JSX还会迫使您将15行HTML组件分为3个组件，即5行HTML组件。不要以为这种方法可以使您成为更好的开发人员。这是东西：当您编写相对复杂的组件时-明天您可能不会在GitHub的公共代表中发布该组件，以在HackerNews上进行演示-这种由于JSX限制而将组件分解为超级笨拙的组件的方法总是使您脱离流程，您可以解决一个真正的业务问题。不，我并不是说小数部分的想法不好或无效。您应该清楚地知道，需要将功能分为其各个组成部分，以使代码保持受控状态。但是，只有在您认为代码中的此特定逻辑实体最好是具有自己的支持的独立组件时才应该这样做-而不是对于使用三元运算符编写的每两个或三个条件！每次在这里和那里创建一个新组件时，都会花费您非常具体的精力并中断您的流程。，因为您需要从架构师的思想（当您已经记住组件模型的当前状态并且只需要在此处和此处添加HTML以使功能正常工作）时转变为经理的思想：您需要为组件创建一个单独的文件，请考虑该新组件的功能它们如何映射状态，如何转发回调等。结果，降低了编写代码的速度，因为如果JSX语法更灵活，您就不得不花费精力在可能不需要的组件过早模块化上。在我看来，过早的模块化与过早的优化非常相似。对于我和我们的团队来说，代码的可读性很重要，但是享受编写代码仍然非常重要。不酷当一个简单形式的计算器需要创建6个组件时，每个组件都有自己的道具。从维护，修改或应用新设计的角度来看，这种超模块化通常也很糟糕，因为要更新小部件中的html，您需要跳过多个文件/函数并分别检查每个小段HTML。同样，我不建议编写整体著作。我建议在日常编程中使用组件而不是微型组件。这是关于平衡和常识的。使用表格和Redux将使您整天打印
反应-关于清洁和单向流动，还记得吗？这就是为什么LinkedStateMixin成为不受欢迎的角色的原因。，现在您必须编写10个函数才能从10个表单字段中获取输入。不，您当然可以编写一个将检查e.target的函数，但是最后会有这样的条件树，其中来自您想哭泣的表单的数据归一化；因此没有人这样做。这些功能的80％将包含带有this.setState（）的一行或对Redux操作的调用。 （然后，您可能必须再创建10个常量-每个动作一个）。我认为，如果您仅考虑一下就可以生成所有这些代码，那么这种方法是可以接受的。但是我不知道任何可以大大简化这种样板的IDE编辑器。为什么要打印这么多？因为大公司认为双向绑定在大型企业应用程序中很危险。我可以确认双向绑定有时不是那么简单且难以理解，但是大多数担心与Angular第一版中人们的普遍痛苦有关，双向绑定可能不是最好的。但是...即使在Angular中，这可能也不是最大的错误估计。看一下我的快速编辑器，最近我为我们的Drupal平台厌倦了Vue.js（我为设计预先表示歉意，这是我们操作员的UI后端，设计人员正忙于为客户创建界面，因此这部分功能正在等待小时才能变得美丽）：即使在Angular中也可能不是最大的错误估计。看一下我的快速编辑器，最近我为我们的Drupal平台厌倦了Vue.js（我为设计预先致歉，这是我们操作员的UI后端，设计人员正忙于为客户创建接口，因此这部分功能正在等待小时才能变得美丽）：即使在Angular中也可能不是最大的错误估计。看一下我的快速编辑器，最近我为我们的Drupal平台厌倦了Vue.js（我为设计预先致歉，这是我们操作员的UI后端，设计人员正忙于为客户创建接口，因此这部分功能正在等待小时才能变得美丽）：
由于明显的原因，我无法显示代码，但是用Vue编写代码非常好，并且代码可读性强。而且我肯定知道，如果像React中那样为表单的每个字段编写一个单独的函数，我当然不会从幸福中跳出来的。Redux也很冗长，需要大量的写作。在Internet上，很容易找到开发人员的陈述，他们指责Mobx仅仅因为Mobx使用双向数据绑定（请参阅“清洁度”第1条）而将React转换为Angular。似乎许多聪明人比快速解决的业务任务更重视代码的“清洁”（原则上，如果没有截止日期，这是正常的）。同时，我认为Flux / Redux概念本身非常酷。Redux很简单，并且提供了对应用程序状态的令人难以置信的控制水平，并将状态与纯接口部分分离开来–这立即使编写测试变得更加容易。但是，不幸的是，所有这些都是通过大量的涂鸦来实现的。是的，时间旅行调试是一个很好的副作用。但就我个人而言，我准备为高速代码编写而牺牲它，并考虑是否需要时间旅行（如果需要为此形式的每个字段提供一个常量）。工具过多
React在Babel上具有原始范围。从ES5编译器开始，如果没有大量的npm软件包，您将不会创建真正的React应用程序。一个基于负载中正式开始构建的简单应用程序在node_modules中接收约75 MB的JS代码。这不是关键的事情，它与整个JS世界有关，而不是与React有关，但仍然增加了挫败感和烦恼。我的React判决-允许您编写出色的可读代码，但是写很多不好玩。好吧，对于那些不拥有HTML且不希望在HTML内部拥有ES6的布局设计人员来说，这些问题不会消失。角度1：太多的自由也很糟糕
Angular 1是一个很好的框架，它位于想象中的JS干净度和代码可读性地图的对角（与React相对）。 Angular可以让您快速入门，让您享受编写前1k行代码的乐趣，然后实际上使您编写的代码工作得不太好。您可能会迷失在贯穿应用程序所有层的指令，作用域和双向数据流中，这将是代码中``swan song''的最后一部分，刚入职的开发人员甚至都不想接触，因为有些东西会中断。为什么会这样呢？Angular.js创建于2009年，当时前端开发的世界看起来非常简单，甚至没有人想到对应用程序状态的良好控制。您不应该责怪作者-他们只是用一些新芯片使Backbone成为竞争对手，并且想要减少打印量（他们做到了，这是另一个问题，但要花多少钱）。角度2
只需构建一个hello-world应用程序，然后查看萝卜中最终包含的文件数。我将不得不使用Typescript（并且我不是100％地确定我每天想要做什么- 不，伙计们，JS中的静态键入不是万灵药，但我必须再次打印，来自Eric Eliott的关于此主题的好想法）和编译器上手。这足以让我们将Angular2推迟到更好的时期。我很懒，对我而言，在开始编写真实代码之前，这太繁琐了。在我看来，Angular 2的作者正在尝试为将击败React的企业构建理想的系统，而不是尝试构建为普通普通用户解决业务问题的框架。也许我错了，我的看法可能会改变-我对Angular2没有太多的经验，最后我们只是构建了一个测试计算器应用程序。Vue.js上一个很棒的比较页面称Angular2是一个很好的系统，它与Vue.js有很多共同点。Vue.js
Vue.js是我等待了很长时间的事情（在下文中，我将讨论Vue.js 2，与第一个Vue版本相比，该版本已得到许多改进，这是系统的当前稳定版本）。对我而言，就优雅和简洁而言，以及着眼于解决实际问题，Vue.js是自2007年受到Jquery袭击以来的JS最大的突破。请注意，今年他不仅让我高兴：在Vue Github上- 2016年排名前1的JS项目（包括带有源代码的萝卜）。根据Google趋势中的流行程度，Vue.js在2016年的表现大大超过了React（当然，这是一家大型医院的平均温度，并且在很大程度上取决于提出的要求-这是非常间接的流行迹象）。https://www.google.com/trends/explore?q=vue.js,react.js,angular.jsVue.js增长最快（就社区而言，或者至少是github中的点赞数而言） ，以及2016年使用Vue Dev Tools的chrome）JS解决方案的用户，我相信这不仅是赶时髦的人的时尚库，他们每3个月就要改用新的JS框架，或者PR部门的工作量很大公司。Laravel已将Vue.js添加到内核，这是一个严肃的主张。Vue.js的优点
Vue.js在可读性，代码的可维护性与代码（编写此代码）的乐趣之间保持了很好的平衡。这种平衡位于React和Angular 1之间的等距距离处，如果您查看vue.js指南，您会立即注意到他从这些系统中借鉴了多少有用的想法。从React Vue.js中，我采用了组件方法，道具，用于组件层次结构，性能，在后端进行渲染的能力以及适当状态管理的重要性的单向数据流。Vue.js取自Angular1相似的模板，具有良好的语法和双向绑定，但仅在您真正需要的地方使用，并且不允许您立即开枪（在一个组件内）。在Vue.js下开始编写代码非常容易-我在我们的团队中看到了这一点。Vue.js不需要任何默认编译器，因此将Vue.js添加到旧代码库并开始将jQuery哈希复制到可读代码非常容易。适量的魔术
Vue.js在以HTML为中心的方法方面以及从JS开发人员的角度来看都很容易工作：您可以创建相当复杂的模板而不会将精力放在业务任务上，并且即使在以下情况下，生成的HTML模板也通常可以很好地阅读：他已经很大了。通常，到这时，您已经在解决业务问题方面取得了良好的进展，并且您可能希望重新组织模板并将它们分为较小的组件-此时，您看到的应用程序的整体“画面”比开始时要好得多。我的经验表明，这与React程序员通常使用的方法有很大不同，并且这种差异为使用Vue.js的程序员节省了大量时间和精力。在React中，您被迫在编写代码的初始“草稿”版本时，将组件分解为微组件和微功能，否则您将被字面地扎在大括号和它们之间的HTML中。在React中，我花费了大量时间反复完善道具和重构超小组件（当然这些组件永远不会被重用），因为当我突然需要在过程中更改代码的逻辑时，我并不清楚。表格
在Vue.js中使用HTML表单很高兴。这是双面装订真正有用的地方。即使在困难的情况下，也没有问题，尽管观察者乍一看可能类似于Angular1。拆分组件时，单向数据流始终在您的服务中。技术领域
如果您要编译，则linting，PostCSS和ES6 都不成问题。单文件组件似乎已成为在Vue.js 2中编写公共组件的主要方式。顺便说一下，作用域CSS可以直接在单文件组件中工作的想法看起来非常不错，并且可以减少对严格的CSS命名规则的需求BEM等类和技术。国家管理
Vue.js通过data（）和props（）方法具有相当简单和有用的状态管理-在实际开发中可以很好地工作。如果灵魂要求对状态管理更多的东西，那就有Vuex（在我看来，它类似于React中的Mobx-状态在这里是可变的）。我认为相当一部分的Vue.js应用程序不需要通过Vuex进行状态管理，但是很高兴有另一种选择。性能表现
主题是整体的，总的来说，react和vue.js都很快。但是，显然，平均而言，vue.js明显更快。来自TodoMVC的注释中的精彩链接带有测量结果：eigenmethod.imtqy.com/mol/app/bench/#bench=%2Ftodomvc%2Fbenchmark%2F#sample=angular2~angularjs~mol~react~vue~vanillajs#sort=fill#这里有更详细的说明（不过来自感兴趣的人）。另一个详细且可理解的基准比较：stefankrause.net/js-frameworks-benchmark4/webdriver-ts/table.html缺点VueJS
运行时模板错误
最大：模板中令人不愉快的运行时错误。受害者为编写代码提供了便利。这与Angular 1非常相似。Vue.js设法为JS代码生成许多有用的警告：例如，当您尝试更改道具或错误使用data（）方法时会出现警告，React的积极影响在此处非常明显。但是运行时模板错误仍然是Vue.js的弱点。异常堆栈跟踪通常是无用的，并导致使用Vue.js内部方法。在这种情况下，在此类错误和调试中，JSX通常更令人愉悦：由于编译是“从JS到JS”，因此在浏览器控制台中单击错误通常会导致该错误在代码中的确切位置。图书馆
Vue.js基础设施还很年轻。实际上，社区中稳定的组件可以用手指指望，其中许多组件是为Vue.js 1构建的，对于初学者来说，要弄清楚为特定版本库构建的Vue.js版本通常并不那么容易。您可以在Vue.js中做一些很酷的事情而无需太多使用第三方库的事实，从而缓解了此问题。您可能只需要一个库来处理Ajax请求（如果您不关心同构应用程序，那么vue-resource是一个不错的选择，否则您可以选择Axios），可能还有Vue-router，它被认为是Vue.js的良好支持的库。非英语社区
大多数公共存储库的代码中都有中文注释，这并不奇怪：Vue.js在中国正成为一种非常流行的解决方案（Vue.js讲中文）一个人的项目。
相反，这是一个潜在的问题，而不是真正的问题，但有时您想放心一点。Evan You是在Google和Meteor上工作之后创建Vue的人。当然，Laravel还是一个单人项目，但是他仍然非常成功，对吗？Drupal中的Vue.js
免责声明：由于我们正朝着更现代，更快，更简单的PHP和Node.js框架迁移，因此我们不打算在Qwintry中立即使用Drupal 8，但是我们的遗留代码是Drupal。由于主要站点qwintry.com在Drupal上运行，因此对于我们在此处检查Vue.js的战斗非常重要。老实说，我对这个存储库中的代码的许多部分并不感到骄傲，尽管它至少以某种方式工作，但我们尽量不进入一些显眼的地方，但是这个具有悠久历史的老项目运转得很好，并产生了我们的收入，因此我们尊重它，改进它，许多新功能就在这里出现。以下是我在Drupal中基于Vue构建的内容的列表：一种快速的实体编辑器表单，其中包括生成客户发票以及快速编辑产品清单。在这里，有必要构建一个简单的JSON API来加载和保存实体-没什么特别的，只有几个回调。两个仪表板，通过我们用于支持团队的产品的Saas REST API，使操作员无需浏览各个网站的管理页面即可检查与特定客户端有关的信息。现在，所有这些都内置在我们网站上的客户资料中。我知道许多后端开发人员仍然停留在2010年的Ajax Drupal内核系统中。我很清楚，当您尝试使用内核中的Ajax功能构建某种复杂的多阶段表单时，Drupal代码会变得多么复杂-以后几乎无法维护此类代码。是的，我在谈论您ctools_wizard_multistep_form（），而您，通过我们用于支持团队的产品的Saas REST API，从而使操作员不必浏览各个网站的管理页面即可检查与特定客户有关的信息。现在，所有这些都内置在我们网站上的客户资料中。我知道许多后端开发人员仍然停留在2010年的Ajax Drupal内核系统中。我很清楚，当您尝试使用内核中的Ajax功能构建某种复杂的多阶段表单时，Drupal代码会变得多么复杂-以后几乎无法维护此类代码。是的，我在谈论您ctools_wizard_multistep_form（），而您，通过我们用于支持团队的产品的Saas REST API，从而使操作员不必浏览各个网站的管理页面即可检查与特定客户有关的信息。现在，所有这些都内置在我们网站上的客户资料中。我知道许多后端开发人员仍然停留在2010年的Ajax Drupal内核系统中。我很清楚，当您尝试使用内核中的Ajax功能构建某种复杂的多阶段表单时，Drupal代码会变得多么复杂-以后几乎无法维护此类代码。是的，我在谈论您ctools_wizard_multistep_form（），而您，现在，所有这些都内置在我们网站上的客户资料中。我知道许多后端开发人员仍然停留在2010年的Ajax Drupal内核系统中。我很清楚，当您尝试使用内核中的Ajax功能构建某种复杂的多阶段表单时，Drupal代码会变得多么复杂-以后再维护此类代码几乎是不可能的。是的，我在谈论您ctools_wizard_multistep_form（），而您，现在，所有这些都内置在我们网站上的客户资料中。我知道许多后端开发人员仍然停留在2010年的Ajax Drupal内核系统中。我很清楚，当您尝试使用内核中的Ajax功能构建某种复杂的多阶段表单时，Drupal代码会变得多么复杂-以后再维护此类代码几乎是不可能的。是的，我在谈论您ctools_wizard_multistep_form（），而您，ajax_render！同时，这些开发人员因对现代接口的要求而不断前进，但是现代JS基础结构的复杂性使他们陷入困境。是的，我在一年前认识自己。各位，听我说！您不会比现在将Vue.js放入站点/ all /库中，并使用drupal_add_js（）将它添加到模板中并开始编写代码来改善界面的时间和方法更好。当维护一个系统，其中Drupal仅负责由Vue.js完全支持所有客户端代码（包括表单）的JSON时，您会感到震惊。Yii2中的Vue.js
有趣的事实：Yii由中文开发商强学创建。因此，可以将Yii + Vue.js称为堆栈，不仅是堆栈，其名称在首次尝试时几乎是不可能发音的，而且可以是具有中国传统的堆栈（以一种很好的方式）。对于新版本的Qwintry.com（尚未发布），我们选择了Yii2，在我看来，它是最好，最快的PHP框架之一。它绝对不像Laravel那样流行，Laravel在PHP世界中处于领先地位，但是Yii2堆栈对我们来说很好。（尽管我们不时查看Laravel，但那里的开发人员正在利用这些资源，当然，那里的库在基础设施方面也更加成熟）。我们将逐步减少Yii2和PHP生成的HTML数量，更多地关注REST API，该API在Vue.js / Swift / Java上运行，为客户端生成JSON。该项目中的大多数Active Record模型都使用API-first方法。在这里，我们已经认真考虑了API，这就是为什么即使此API不是公开的，我们也花大量时间在良好的API文档上。在PHP级别生成HTML部分的代码部分中，我们使用我们自己的解决方案和Webpack捆绑和方便地部署Yii2小部件，而Yii2小部件又使用Vue单文件组件。使用PHP7和最新的MySQL，我们的Yii2 JSON后端的响应时间与Node没有太大区别。js后端（我说的是15-20ms左右的响应速度），坦率地说，这些不是宇宙数字，但这足以满足我们的需求，最重要的是，它比给出的速度快10-20倍我们旧的Drupal网站。同时，这是一个很好的旧的（可能很无聊）PHP，具有作曲者库的所有功能和稳定的代码库。基于Yii2＆Vue.js构建的接口的响应能力是可以接受的，并且从代码可读性的角度来看，这里的一切也都井井有条。基于Yii2＆Vue.js构建的接口的响应能力是可以接受的，并且从代码可读性的角度来看，这里的一切也都井井有条。基于Yii2＆Vue.js构建的接口的响应能力是可以接受的，并且从代码可读性的角度来看，这里的一切也都井井有条。我们还在许多内部和外部项目中使用Vue.js，这些后端在Node.js上运行-我不会在上面添加任何新内容，一切正常。结论
我们已经在各个项目中每天写Vue.js代码大约4个月，结果令人印象深刻。在后端世界中，4个月是没有时间的，但是对于JS世界来说，这是一个体面的时期，其中五个框架诞生并消亡了：）让我们看看接下来会发生什么。我认为，如果Evan You采取正确的措施，至少在后端和小型前端团队中，Vue.js将在未来16-24个月内成为JS的主要解决方案。 React堆栈将在2017年成为主流，特别是如果React Native继续以现在的速度增长和改进。UPD：本文打在上面HackerNews，还有随之而来了有益的探讨（250个+评论）：news.ycombinator.com/item?id=13151317在顶部reddit的Webdev的，我们还参观了，60岁以上的评论在这里。从那里对Angular2的有趣评论：所有Google文档都像阅读2000年代初的Microsoft文档一样。
“建立Angular项目简直是小菜一碟！只需确保无状态参考原型更改器继承自实现MODOK服务提供程序的基本内存加载器旧版对象即可（不是核心的一部分：请参见此处，以同样的方式阅读不明的细节）。然后，您将准备编译Angular内核，请小心使用Webpack 2.3.9（注意：不是随存储库提供的2.3.8）。这就是您开始进行出色的Angular项目所需的全部知识。Angular：再次使开发变得简单又有趣！”
读者的问题：
JSX很酷而且正确，但是您却不是！如果您确实需要条件，请对If组件进行编程，这是三行！选择一个框架，然后对他进行此类操作是令人不快的，每个进入该项目的新开发人员都会向您询问此类决策，而在其他人的组件中，您的视线总是会因呆板而绊倒。此外，如果将组件写为“ forehead”，则会出现内部组件始终执行的问题。但是还有更多有趣的解决方案：github.com/AlexGilleran/jsx-control-statements那么，亲爱的，您现在有什么建议呢？您需要紧急删除React并将所有内容重写为Vue.js吗？不，不！ React是一个出色的框架，它允许您编写可读和受支持的代码，并且已经为此编写了许多高质量的库（我在上面“打过分”的JSX的微型组件和局限性在这里起着积极的作用，对于公共库来说，这是（通常已经证明是合理的），但不适用于任何其他JS解决方案。如果您和您的团队对JSX中的所有功能都感到满意，并且您无需打扰太多，也许切换到Vue.js毫无意义，那么这款游戏绝对不值得。许多JS爱好者最近都喜欢从一个框架跳到另一个框架。我认为不要滥用它，最好将这段时间花在项目用户会注意到的更有趣的事情上。但是，如果由于庞大的工具和其他困难而使您无法开始使用React，并且您的代码遇到了jQuery或Backbone混乱的情况，那么Vue.js可能是一个不错的选择，而不是学术性的，简单而简洁的。我没有阅读整篇文章，但是在标题上您对免疫说了些负面的话，您可能不是正统的，因为您的经验不足和愚蠢，您不知道功能性方法有多棒！让我们将免疫力作为功能范式（我们非常尊重功能方法，免疫力的概念和功能的纯度）以及JS世界及其库的当前状态进行分离。如果开发人员在阅读了Facebook博客后高兴地抓取Immutable.js并将其投入生产，然后意识到他没有一个很好的坞站，Lodash和上一代开发人员编写的所有其他代码都无法与他合作（是的，我知道（关于围绕lodash的不可变包装器，谢谢），因此开发人员未能在截止日期前完成-这意味着开发人员未购买功能范式，而是针对特定库进行了宣传。不要以为如果Facebook存在使用Immutable.js可以解决的实际问题，那么这意味着您将在着陆页或SPA中遇到类似顺序的问题。很有可能不是，而是您的投资者将花光钱，您将需要尽快推出可运行的功能，并且代码正常且足以在不需要的地方进行更改就足够了，不需要为此使用Immutable.js（例如，在此处阅读有关Immutable.js的观点）。另外，我注意到，许多JS开发人员（其观点被视为Immutable.js的主要杀手功能）并不是所谓的结果代码的纯度和可靠性，而是-注意！ -提高生产率（我们正在谈论结构的快速比较）！如果人们为了提高性能而将这一级别的功能部件推入他们的项目中，那么这个世界上有些事情是错误的。似乎时尚再次介入...如果您想简化生活，只需停止改变您的状况，改用道具，这些简单的事情现在就可以改善您的生活。