一个经典的来回式博客，我最喜欢的互联网讨论形式。
Paul Lewis 对不同框架的性能进行了一些研究，将它们各自的 TodoMVC 版本相互比较。
对我来说，结果很明显：在移动设备上使用框架似乎要付出相当大的代价，尤其是在与编写原生 JavaScript 相比时。
大多数批评者都忽略了 [使用框架的关键价值]：**框架可以让您在应用程序及其构建团队随着时间的推移而增长时管理应用程序的复杂性。** 所有其他内容只是锦上添花。
还有
… 我的假设是，对于任何复杂度的应用程序，那些从“原生”开始的应用程序会逐渐积累自己的 Frankenframework，其性能与现成的框架类似，甚至更差。
… 从 Tom 的帖子中可以进行的有趣讨论是：我们是在尝试制作快速工作的轻量级网站还是可维护的网站工作多年？
我的看法是：是的，**最大性能** 和 **最大开发人员舒适度** 确实有些矛盾。这是一个由来已久的问题。当你筑坝时，河流流速会变慢，但你可以获得一些电力。好了，不要再用比喻了。
来自 Zach Leatherman 的更多“金发姑娘”的解决方案，以及对推动基准测试竞争的希望。
如果您决定在框架上花费宝贵的千字节，幸运的是有许多框架可供选择。就像 DOM 库曾经在选择器引擎性能上竞争一样，框架作者的责任是相互竞争，以提高初始渲染性能。
我还想补充一点：这种未缓存的首次渲染时间是一个不错的指标；也许是最重要的指标。但测量之后的性能也非常重要。谁在“点击和执行操作”的性能竞赛中获胜？
有趣的是，我使用 JavaScript 框架的经验是，大多数情况下它们会降低性能和可维护性。
当框架强制开发人员滥用最佳实践时，例如使用私有变量来支持不适合 JavaScript 的继承模型 (ExtJS)，或者强制开发人员将业务逻辑泄漏到 DOM (AngularJS) 或反之 (ExtJS 再次出现)，事情往往会变得混乱、臃肿和难以理解。
现成的框架只有在用于其特定领域时才能脱颖而出。在其他任何地方，它们带来的麻烦都超过了它们的价值。由于这个原因，在选择框架时必须非常谨慎；框架很少能得到应有的审查。
我认为这将随着预编译器的出现而得到改善；允许代码的一部分使用一种方法，该方法编译成还算不错的 JavaScript，这意味着更少的范式切换和更多关注点的分离。
您能对此进行扩展吗？我很想知道您为什么会这么说。
@Agop（我想我不能直接回复回复？）
Angular（以及 Ember 和 Polymer）鼓励将应用程序逻辑放在 DOM 中。
当 DOM 交互很简单时，这是一种节省时间的方法，但我认为（说实话，我不能从经验中说；我对 Angular 还是个新手）当多个 DOM 元素依赖于某个属性或更改某个属性时，这可能会变得更难管理；我个人希望我的应用程序模型位于 JavaScript 接口后面，而不是 DOM 状态。
我阅读了类似的讨论，并想知道为什么我认识的所有优秀开发人员都如此教条主义。还有其他人记得 VI 和 eMacs 之战吗？
我认为 Dave 说对了。
框架的存在是有原因的。对于那些拥有大型且使用寿命长的网站，以及由技能水平差异很大的开发人员组成的庞大团队的人来说，框架是救星。它们促进了代码库的一致性，并允许低级开发人员创建响应式页面，这些页面可以在大多数平台上可靠地运行。
如果我在一个由少数才华横溢的编码人员组成的商店工作，他们构建的是小型、花哨的网站，这些网站的使用寿命很短，我的需求将完全不同，框架不会那么有用。
我们这个领域中的许多“专家”都是自由职业者，或者为小型代理机构工作，这些机构做的是前沿的工作——我认为他们的观点有点偏颇。
绝大多数程序员都在中大型组织工作，他们已经厌倦了组织的政治和惰性，以至于在工作日结束时，我们最不想做的事情就是写博客记录我们的经历。尤其是在大多数博客都是由那些瞧不起我们的人写的，因为我们没有从头开始编写所有代码。
我同意你写的大部分内容，但我认为你不能把开发人员归类。到处都有偏颇的观点。
除了其他原因之外，那些知道如何做好这些事情的人往往会写下他们的经验并分享他们学到的解决方案。了解程度较低的开发人员会阅读这些博客和文章，并假设他们正在做的事情一定是现状。
或者就像你提到的，盲人领着盲人走：一些博主会写下他们使用大型框架进行小型项目的经验，只是作为试探性的气球。结果是，大型框架被那些不知道更好的人用在了小型项目上。如此反复。
最糟糕的情况是… 互联网多年来也一直保持着一种复制粘贴的心态。有些人想要快速解决方案。用例无关紧要。给妈妈和爸爸一个企业框架，管它呢… 如果它对 Oracle 有效，它在这里也应该有效。因此，如果开发人员 X 需要做某件事，某个人的 Stack Exchange Angular 解决方案只有几行，也许我应该使用它。无论它是否过度使用或“刚刚好”，它都起作用了。这种情况很多。（例如：WordPress 很受欢迎，因为它具有复制粘贴的心态，尽管它是一个非常糟糕的开发环境。）
我编写了 Angular 应用程序来替换（然后扩展）原生 JS 应用程序，我的天，事情已经从数千行代码变成了仅仅几百行。如果你的 Angular 应用程序不可维护，那么你就是做错了——用原生 JS 做并不会让事情变得更好。
当你构建一个原生 JS 应用程序时，你仍然在使用一个框架！只是，你不是使用数千人使用的框架，而是使用几个人（在某些情况下，只是一个你）使用的框架。
即使在这个虚构的 TodoMVC 示例中，看看原生 JS 实现。没错，它看起来像一个框架！在这个特定情况下它更快吗？当然！但它在一个更复杂的应用程序中会更快吗？祝你好运，因为你必须先编写那个乱七八糟的应用程序才能测试它！
我在这里不是为了反对或支持使用框架，但根据我的经验，它们确实会带来很大的成本。
我们有一个非常数据密集的页面，它在约 20 毫秒内加载、处理和渲染。在页面中添加一个 Kendo UI 下拉菜单增加了 40 毫秒（两个增加 80 毫秒），而自定义的基于 CSS 的下拉菜单没有影响。20 毫秒足够快，您可以重新渲染整个页面，而用户甚至不会注意到。
我们的页面最初使用 Knockout，渲染时间约为 800-1000 毫秒。我们尝试了不同的框架，但没有一个能够将时间缩短到 200 毫秒以下。
使用简单的 JS 模板和手工编写的逻辑并不适合胆小的人，但它确实有回报。如果应用程序或网站最需要的是性能，我认为别无选择。
虽然框架的技术性能很有趣，但我发现框架的其他方面更有趣，比如它的生命周期和可用的知识库。
Angular 很酷，是的，如果你做对了，它可以帮助你在某种程度上以可控的方式构建一个复杂的应用程序。但是，三年后，没有人再使用 Angular 了，它将成为新的遗产。
别误会我的意思，我知道任何框架都会遇到同样的问题，或者不使用框架时也会遇到同样的问题。我只是在回应人们认为框架可以帮助创建使用寿命长的应用程序。也许吧，但框架本身不会长寿，关于它的知识也不会长寿。
我对此没有解决方案，只是发现了问题。我工作的一部分包括继续为使用曾经被认为是未来可期的框架构建的应用程序提供支持。你找不到一个人来支持它们，即使他们有知识，他们也更喜欢新的项目，这很正常。
我认为放弃框架的主要问题之一是团队。我不认为有人会不同意你的观点，框架确实存在性能问题。但大多数从事长期项目的团队都会面临人员流动。因此，在引入新团队成员时，拥有一个可以依靠的框架至关重要。还记得你第一次使用 Ember/React/Angular 的感受吗？想象一下，在没有文档的情况下经历同样的体验。这并非不可能，只是提高了难度，以至于大多数团队无法承受。正如其他人所说，这真的取决于你团队中开发人员的专业知识。如果你有一个三层级团队（初级、中级和高级），那么在没有大量挫败感的情况下，几乎不可能培训新的初级开发人员使用你的自定义构建。
这个话题（观点）总是引发激烈的争论，我认为需要牢记的是，没有一个万能的答案，双方都没有“正确”或“错误”。
我的观点是，这完全取决于项目、业务需求以及（在某些方面）团队。这些因素之间的平衡取决于你作为技术专业人员，以确保每个因素都能获得最大的利益……这就是问题所在。
关于这个话题，我想提到的最后一点是，框架和库之间的界线往往难以区分；它们经常被互换使用。框架是把你束缚在特定工作方式的东西，而一系列库可以组合在一起，创建你想要的框架，这将最有效地用于你正在进行的项目。
我完全同意这一点，一旦你达到一定的复杂程度，你最终会创建自己的“弗兰肯框架”。在这种情况下，使用一个成熟的框架是有意义的，因为这些框架已经为你考虑了这些问题。
我看到最大的问题是开发人员希望从不同的框架中获得特定的功能，并将它们混合搭配，例如使用 Angular，但使用 jQuery 进行 Ajax 和动画。这会严重影响加载时间。
绝对的。混合使用不同的框架（即，更多或更少地定义代码如何编写整体的代码，而不是提供功能但不规定编码风格的库函数）会比不使用任何外部框架更混乱。