作者 | Dusty Phillips
译者 | Sambodhi
策划 | Tina
导读：在软件开发的大潮中，重写项目常常被视为一项既常见又充满挑战的任务。本文作者结合自身多年的实战经验，深入剖析了前端与后端重写之间的异同，并特别分享了从 React 向 Svelte 迁移的历程，其中遇到的种种难题与收获均一一呈现。通过对比 Svelte 与 React 在性能、开发速度及开发者满意度等方面的表现，作者认为 Svelte 具有成为新项目首选框架的潜力，并分享了自己对 Svelte 的独特见解与热切期待。此外，文章还着重强调了项目重写的必要性及其所面临的挑战，同时列举了一些成功的重写案例与失败的教训。若你对软件重写、前端框架的选择以及 Svelte 的优势抱有浓厚兴趣，那么本文定能为你带来深刻的见解与启发。
我和妻子一起倾注心血于 Fablehenge，这款专为小说作家打造的写作应用已经陪伴我们好几个年头了。最初，这不过是个业余爱好，我们会用几个周末的时间全力以赴，然后让它暂时休息几个月，偶尔在晚上的空闲时间里稍作调整。
今年年初，我本打算好好休个长假，去开辟新的徒步小径、做做木工活。虽然这些活动确实进行了，但我发现自己还是基本上把主要时间都投入到了 Fablehenge 的工作中。
Fablehenge 是用 React 编写的，我和 Jen 都对 React 了如指掌。我早在它还未开源时就断断续续地开始使用，而 Jen 则多年来一直只用它一个。
一月份，我大部分时间都在努力让一个相对（但并不算特别）复杂的拖放系统正常运作。接着，Jen 又在二月份花了三周时间来微调和改进我的实现。
我们的代码是基于 dndkit 构建的，就像我找到的每一个 React 拖放库一样（我为此花了几个小时搜索），它最近都鲜有维护更新。尽管我很喜欢这个库，但经过我们共同花费大约六个星期的调整后，我们发现应用存在性能问题，而自己却束手无策。
在探索解决方案的道路上，我意外地发现了 svelte-dnd-action 这个库。当时，它最新的提交竟然就在 18 小时前！天哪，我真是羡慕不已！
虽然之前听说过很多人对 Svelte 的热爱，但我总觉得那更多是炒作而非实质。毕竟，Javascript 社区向来以追求 “新奇特” 而著称。
然而，为了从 React 的挫败感中解脱出来，我还是决定花一天时间学习 Svelte 的教程，并尝试创建了一些简单的应用。当我测试 svelte-dnd-action 时，真的被它深深吸引了。我立马给 Jen 分享了教程链接，没过多久她就告诉我：“我觉得我再也不想回到 React 了。”
于是，抱着玩玩看的心态，我开始将几年的工作成果迁移到 Svelte 上。这个过程竟然异常顺利，我原本还担心会出现什么问题。在我的职业生涯中，遇到过许多看似很好的库，但最后却带来了更多麻烦而非解决方案。抽象层总是会出问题，这是难免的。但随着对 Svelte 的深入了解，我渐渐意识到它真的很特别。
我记得不知道什么时候曾听人说过，新技术要想克服用户社区转换的惰性，必须比现有技术好上 10 倍才行。React 出现时，其开发体验显然比当时的竞争对手（如 jQuery 和早期的 Angular，当时的 Angular 与今天的 Angular 不同）要好得多，远远超过了 10 倍的标准。因此，整个社区几乎一夜之间都转向了 React。
虽然之前我对 Svelte 的炒作持保留态度，认为它不太可能成为改变整个社区的 10 倍改进技术。但现在我的想法已经变了。
1 迁移之旅：React 到 Svelte 的开发速度革新
我估计我们在 React 应用上投入了大约一年的总人时。我们的代码库写得既规范又易于维护，规模适中，不存在任何未知问题让我们担忧。因此，相较于最初的投入，从头开始重写它花费的时间肯定会少很多。我们深知复杂性的根源所在，于是优先解决这一问题。同时，我们也对应用程序进行了结构化调整，以便能够复制粘贴大约百分之二十的与查询和修改数据相关的代码，只需稍作修改即可。
整个重写过程仅花了三个星期的时间。这里所说的 “重写”，并非指 “大部分重写”，而是指 “完全重写”。2 月 26 日完成了初始提交，到 3 月 15 日，Svelte 应用已经部署并投入生产。我们已经开始开发新功能，并且进展迅速。
请回想一下，之前 Jen 和我在 React 中耗费了三周时间才勉强搞定拖放系统。鉴于这是当时面临的主要问题，我们自然在 Svelte 中也优先解决这一问题。而我在 不到一天 的时间内就彻底解决了它。虽然我在 svelte-dnd-action中发现了一个错误或缺失的功能，但维护者在我发布了可靠的重现后两天内就迅速修复了。
若将每六周的 React 开发时间与一天的 Svelte 开发时间相对应，那么我们将在半天内就赚回重写应用程序所花费的时间。当然，这种说法可能稍显（更为）乐观！但不可否认的是，我们的 Svelte 开发速度确实比 React 开发快两倍以上。
2 轻装上阵：Svelte 带来的代码精简与效率提升
虽然 React 相比很多前辈技术有所进步，但它仍然需要编写相当多的样板代码（哪怕是不使用 Redux 的情况下，我们也知道要避开它）。我们已经使用 React 很长时间了，以至于对样板代码已经习以为常；在编写 React 代码时，往往会忽略每个组件中重复的部分。
我们的 Svelte 应用程序只用了 React 应用程序所需代码的 60%。这里我要再次强调，我们的 React 应用程序编写得非常规范，没有多余的代码或未使用的功能。我们几乎把所有东西都迁移到了 Svelte 上。当然，在迁移过程中我们也对一些功能进行了重新设计，但这只是因为这样做起来很容易。要说的话，我怀疑我们的 Svelte 代码是写多了，不是写少了。
我应该承认，代码量减少的部分原因是我们现在使用了 tailwind CSS，而之前我们使用的是 Chakra。tailwind 在减少代码行数方面确实非常出色。关于 tailwind 的更多细节，我会稍后详细介绍（提前透露一下：我们其实不太喜欢它）。
3 愉悦探索：感受 Svelte 的独特魅力
Fablehenge 是一个业余项目，我们的初衷是享受在上面的工作时光（当然也希望作家们能喜欢使用它）。我们本以为自己很喜欢 React，但事实是，Jen 和我经常在午餐时抱怨 React 生态系统的各个方面。并不是说 React 不好，它真的很棒！只是相较于它的潜力，使用它的乐趣似乎没有那么大。
相比 React，Svelte 有趣得多，而且我认为等到 Svelte 5 发布（即将）时，它会更有趣。当然，享受编码的感觉是非常主观的，但 Svelte 完全符合我们对它的所有期待。
我们是一个两人团队，可以完全掌控项目。因此，我无法断言 Svelte 是否能像 React 那样，扩展到拥有数千名开发人员和数百万行代码的公司规模。但直觉告诉我，它是可以的。Svelte 与 React 鼓励的组件模型和分隔样式保持了一致。然而，为了效率，它也为开发者提供了很多强大的功能，但滥用这些功能可能会导致维护困难。
最值得一提的是，Svelte 强调单向绑定，但在适当的情况下也允许双向绑定（通常是在表单元素中）。遗憾的是，关于 “适当” 的情况并没有硬性规定。我完全能想象到，大公司的实习生可能会觉得双向绑定更简单，但这实际上可能会给未来的维护带来噩梦。但任何有经验的开发者都会告诉你，审查实习生的代码比自己编写代码需要花费更多的时间和精力，所以我并不认为这些不良习惯会真正合并到项目中，对吧？
