没有人因选择React而被解雇

如果您花大量时间在Hacker News上，那么很容易被无框架的网络应用所吸引。有很多潜在的优势（不要膨胀！请定制您的项目！），并且能够说您以最小的依赖关系构建了一些东西，从而获得了工程师积分。

我最近开始了一个新的附带项目。这是一个基于网络的图形编辑器，因此它必须是一个单页应用程序。我花了很多时间对SongRender进行性能分析，这让我对React感到有些警惕，因为它无法以每秒60帧的速度更新界面，因此我决定避免使用它。我会（主要是）香草味，看看我走了多远。

我安装了lit-html并开始工作。 “组件”只是返回lit-html模板结果的函数。树顶部的大单例保持所有应用程序状态，并作为全局变量存储在该模块中。

当组件需要本地状态时，第一个障碍就来了。我本可以将其提升为单例，但这会破坏组件的封装。我注意到lit-html指令可以保持状态，因此我决定使用它们来构建一个很小的组件库-忽略了lit-html开发人员的警告，即这不是受支持的用例。

我的自制库运行良好……直到当组件出现在屏幕上时我需要运行一些代码。我开始仔细阅读lit-html文档和问题，以寻找一种方法来检测指令的生命周期，但是对我来说，很显然，走这条路会很痛苦。

我从许多开发人员那里听说，他们接受了这样的论点：香草JavaScript或微库可以使他们编写更精简，更快捷的应用程序。但是，在一两年后，他们发现自己是一个速度较慢，规模更大，文件较少且内部维护得很少且没有社区的内部框架。随着应用程序的增长，您倾向于需要框架提供的抽象。您或社区都可以编写代码。

很公平。让我们避免这种陷阱。小框架呢？我听说过有关Svelte的很多好处，尽管我对Svelte社区的规模有些担心，但我认为这会很好。

当我希望父组件将某些样式应用于子组件时，我的迁移尝试迅速停止。在React中，我将从父级传入一个类名作为className道具。在Svelte中，这被认为是一种解决方法，而实际功能是RFC的主题。 1个

也许这是一个琐碎的功能示例。但这是一项非常基本的功能，令我惊讶的是，斯维尔特（Svelte）的第三版没有正式的实现方法。创建第二个组件时遇到了这个限制。在我尝试任何能使Svelte赢得嗡嗡声的酷反应性之前，请务必先尝试一下。

所以我改变了主意，选择了React。一个小时左右后，我完成了所有工作，而我的焦虑感消失了。我不再担心拥有最高效的组件系统，而是一开始就着手开发我想构建的东西。

不，React并不完美。它针对发出网络请求然后显示事物列表的应用程序（即大多数应用程序）进行了优化，这并不是我在这里真正要做的。2.现在的性能不错，尽管我希望我必须在项目中进行优化变得更加复杂。

但是React让我停止考虑框架。 React妨碍了我。 React很无聊。 React是积极开发的。 React具有庞大的生态系统和庞大的社区。 React在世界上一些访问量最大的网站上经过了实战测试。

我敢肯定，从技术上讲，有更好的方法可以在网络上建立高度交互的界面，但是生命太短了，我无法花几个小时来尝试找出它们。有一些我想创建的东西，而实际上可以创建它们的唯一方法就是停止在工具上花费大量时间。

他们似乎采用的解决方案-让孩子将CSS自定义属性公开为道具-实际上很酷，尽管我不喜欢Svelte会用额外的div默默地包装您的组件。 ↩︎

尽管Dan，如果您读过这篇文章，那么您提到的“动画通过”模式听起来很有意义！ ↩︎