选择和学习框架

docs.scrimba.com

前两章讲了框架是什么和有哪些框架。这一章是最实际的部分：要不要用框架、用哪个、怎么学。顺序很重要，因为第一个问题恰恰是最常被跳过的。

你到底需不需要框架？

想象两个项目。第一个是带账户系统、表单，各个页面都对共享数据做出反应的应用。手写这一切，等于把框架早已打磨好的那套底层机制重新造一遍，最后你自己攒出来的这套"原生版框架"东拼西凑、几乎没测试过，没人愿意接手维护。这种情况下选择 Django 或 React，其实是在选一个部件更少的方案，而不是更多。

第二种情况是一个落地页、一个内容站点、一个小脚本，或者一个提交到某处的表单。用纯 HTML、CSS 和一点 JavaScript 就能搞定，不需要构建步骤、不需要更新依赖、明年也没什么要迁移的。给这种页面套上一整套框架，只会给工具链本身带来好处，别的都是负担。很多有经验的开发者会有意选择用原生方式来做，这是一种专业的判断，绝不是新手才会做的妥协。

工程领域有条直白的老规矩，恰好能覆盖这两种情况：KISS，"keep it simple, stupid"（保持简单，别整复杂了）。这话是冲着设计本身说的，不是冲着设计者，意思是最好的方案是用最少的机制就能把活干完的那个。上面两个项目都遵循了这条规矩，只是得出了相反的答案。

所以真正的判断标准就一个问题，每个项目都要重新问一次：选那个让你维护起来负担更小的方案。如果底层机制的复杂度远远超过了产品本身，那就该用框架。如果产品几乎就是全部内容，那就该用原生方式。

有几个信号能让这个判断更具体。偏向框架的信号：很多页面共享实时数据、有用户账户和权限系统、表单需要校验和保存、好几个人要在同一个代码库上合作维护很多年。偏向原生的信号：主要是内容、交互很少、生命周期只有几个月、只有一两个维护者，或者一个页面的核心卖点就是加载速度。而且项目规模会随时间往两个方向改变答案，所以有用的习惯是：项目形态一变，就重新问一次这个问题。

这个决策会以两种可辨认的方式失败，而这两种失败都源于跳过了这个问题。第一种失败是"框架架子的落地页"：为四页内容配上了构建流水线、依赖树，以后还得迁移升级，每一小时花在工具链上的时间，都是产品本不需要的时间。第二种是"意外长出来的框架"：一个原生代码库慢慢长出了自己的路由系统、自己的状态存储、自己的组件系统，每一个都只写了一遍、从没测试过、只有一个人懂。第二种项目付出了框架级别的成本，却没得到框架级别的好处。这两种失败从当事人的角度看都像是坚持了正确的判断；而两者的解法是同一件不太光彩的事——根据项目现在变成了什么样子，重新做一次决定。

Juno你需要框架吗？ 每个项目只问一个问题：哪个选项需要你搭建和维护的东西更少？对于一个有账户系统、共享数据的交互式应用，框架通常更划算。对于一个内容页面或小脚本，纯代码通常更划算。这两种答案都值得尊重，选纯代码从来不是降级！

Juno你需要框架吗？ 共享的实时状态、账户系统、表单、以及长期多人协作，这些信号指向框架；内容为主、生命周期短、或者对速度极度敏感的页面，指向原生方式。项目形态变了就重新问一遍，而不是死守当初的判断，每个项目都要单独判断一次。

Juno你需要框架吗？ 留意这两种典型的失败：一种是"框架架子的落地页"，白白付出了工具链的成本；另一种是原生应用悄悄长出了自己那套没人维护的框架。两者都源于把这个选择当成一次性决定。我每到项目的关键节点就会重新判断一次，这个习惯不止一次把我从这两个坑里拉出来。

怎么选框架

如果答案是"要用"，那就用一些不那么光鲜但很实际的标准去选。跑分和功能对比表其实是最没用的参考，因为在同一类框架里，那几个流行的选项速度都够快、功能都够全。真正影响你日常开发体验的是：

生态和社区：文档是否成熟，问题是否有人解答，遇到的问题是否有现成的包能解决。你要加入的团队和代码库：最好的框架往往就是你项目已经在用的那个，团队内部的一致性比新鲜感更重要。就业市场，如果你是为了工作而学：使用量本身就很重要，这也是为什么 React 对很多人来说是理性的第一选择。还有你已经会的语言：Python 开发者上手 Django 会比上手 Rails 快得多，这和质量高低没什么关系，纯粹是语言的问题。

把"不用框架"这个选项留到最后再考虑。如果对比表填满了，而候选框架里没有一个在简洁性这一项上能打过"什么都不用"，那这本身就是答案。

要更深入地评估一个候选框架，花一小时亲自体验，比读一周的他人评价更有用：翻一遍官方教程，看文档是在讲清楚问题还是只是比划一下；查一下发布历史，看节奏是否稳定、不慌不忙；搜一下"从版本 X 迁移到版本 Y"，看这些指南读起来像一个下午的活还是一整个季度的活；再看看你想问的问题是不是已经有靠谱的答案。选框架是一段长期关系，这些就是相当于"合不合适"的考察。

还有两个更资深的习惯值得补充。第一，优先选被广泛验证过的技术：一个被大量使用多年的技术，它的失败模式、招聘人才池、以及各种问题的答案都是已知的，"经过验证但不那么时髦"往往比"新鲜炫酷"活得更久，反过来的情况反而少见。技术更替本身是一种复利式的成本，而那些活过十年的框架早已把这份成本付清了。第二，在组件这个层级上，把"自己造 vs. 直接用现成的"当作一个真实的选项：有时候最合适的"框架用量"就是引入一个路由库，别的什么都不加，只为解决那一个难点，其余部分保持原生。用不用框架从来不是全有或全无的选择，用最小的依赖解决真正难的那部分，本身就是一种值得尊重的架构。

Juno怎么选 用实际的标准来选：团队已经在用什么、文档和社区好不好、就业市场需要什么、以及你已经会哪种语言。在同一类框架里，每个流行的选项都不差，所以这个选择的风险其实比看起来的要小。不管你选哪个方向，学到的技能都会跟着你。

Juno怎么选 给候选框架一个小时专注体验：读它的教程、看它的发布节奏、读一份版本迁移指南——因为那就是你将要面对的未来。社区、团队适配度、招聘需求，永远比跑分更重要。而且要有意识地把"不用框架"留到候选名单的最后再排除。

Juno怎么选 优先选被广泛验证过的技术：能活过十年，是一个框架能拿出的最有说服力的成绩单。也要记住，是否采用框架不是非黑即白的；有时候为一个难点引入一个小库，就是恰到好处的"框架用量"。目标是做出能上线、并且能持续上线的产品。

怎么学任何一个框架

先学好语言。框架处处都以它的语言为前提：React 代码从头到尾都是 JavaScript，Django 应用里每一行看起来让人费解的代码，底层其实都是 Python。跳过语言直接学框架的人，最后会同时在破解两个谜团——框架的行为和语言的语法——而且根本分不清到底哪个是哪个。如果你的目标是 React，JavaScript 课程才是真正的第一步；如果目标是 Django 或 pytest，Python 课程扮演的是同样的角色。先学语言是这里最大的一条捷径，因为语言这部分知识能用在任何地方。

然后动手做一个小而真实的东西。找一个你真心想做的小项目，一边参考官方教程一边动手，这比看多少视频、读多少文章都更有用，因为框架的样子只有在你自己动手的时候才会真正说得通。刻意让第一个项目保持简单：它唯一的任务就是带你入门框架的思路，杰作可以以后再做。

在这个过程中，一直要问自己：框架到底在替你做什么。每一个方便的功能背后都对应着某个真实的东西：一个路由代表着 URL 解析，一个组件代表着 DOM 更新，一个模型代表着 SQL。你不需要一开始就精通这些底层，但知道它们存在，大致知道框架在用它们做什么，正是"会用框架"和"盲目依赖框架"的区别所在。

这个阶段常见的陷阱是"教程循环"：一门接一门地刷完课程，却始终没开始一个没人带着做的项目，因为教程让人觉得有产出，而空白文件让人觉得有风险。要有意识地打破这个循环。学完一个官方教程之后，就开始那个小而真实的项目，让项目遇到的问题来决定你接下来该查什么；带着实际问题去读文档，记忆效果和把文档当作业来读完全不一样。在自己的项目上卡住、再自己想办法解决，才是真正在训练的那项本领。

有两个习惯能让你对框架的理解更持久。早点学会"逃生舱口"：每个框架都有官方认可的、能跳出其抽象层的方式（比如绕过 ORM 直接写 SQL，绕过渲染器直接操作 DOM），知道它们在哪里，能让你摸清这台机器的边界，即便你很少真正用到。另外，持续给框架底下的那个平台——HTTP、DOM、SQL、语言运行时——投入一点点持续的学习。框架只是当下承载这个平台的方式，平台才是真正长久留存的东西。过去二十年里，那些真正了解平台的开发者，安然穿过了每一次框架更替，这个记录值得效仿。

Juno学一个框架 永远先学语言，再学框架：先学 JavaScript 再学 React，先学 Python 再学 Django。然后做一个小而真实的项目，官方教程就开在旁边随时参考。小而完整，胜过大而半途放弃，而且你学到的语言知识永远不会贬值！

Juno学一个框架 有意识地跳出"教程循环"：学完一个官方教程后，就去做一个没人带的小项目，让它遇到的问题来决定你接下来读什么。带着实际问题去查文档，才真正能记住。在自己的项目里卡住又解决问题，才是你真正在训练的本领。

Juno学一个框架 早点找到"逃生舱口"，它们标出了这台机器真正的边界。同时持续积累对底层平台——HTTP、DOM、SQL——的了解，因为框架会不断更替，而平台会一直留在那里。懂平台的人能穿过每一次框架更替存活下来；我见过好几轮，这个规律从没失灵过。

到这里，你该知道的都有了

这就是全部要点：用简洁性做判断标准，用不光鲜但实际的标准去选框架，学框架之前先学语言。以后遇到某个具体框架，无论是在这份文档里还是在真实世界中，框架的种类就是帮你给它定位的地图，什么是框架则是这张地图背后的那套定义。