转载自 Swyx Wang. React Distros and The Deployment Age of JavaScript Frameworks. Feb 19 2020
为什么我们不再有前端框架之争，以及对React元框架（meta framework）今昔状况的思考#React——题记
James K Nelson最近提出了一个有趣的观点。
Abramov 先生一直告诉我们 #reactjs 是一个UI运行时。
在我看来，这听起来像是React是一个内核。Webpack/Create React App是引导加载器。Next.js和Gatsby是我们最接近发行版的东西。
那我认为我们需要更多的发行版。
如果你和我一样，不确定什么是bootloader，谷歌说 "bootloader是在任何操作系统运行之前运行的一段代码。Bootloader是用来引导其他操作系统的，通常每个操作系统都有一套特定的bootloader"。我想Webpack的运行时就是这样，但它也是一种编译机制，嗯，从/src到/dist。
总之，这个比喻是对的。我想对这个问题做一些解释。
目次
- 卡洛塔-佩雷斯框架 (The Carlota Perez Framework)
- JavaScript框架的“部署时代”
- React“发行版”（Distros）
- 还有哪些React发行版应该存在？
- 给造轮子的人的React发行版
卡洛塔-佩雷斯框架 The Carlota Perez Framework
风投界现在特别迷恋Carlota Perez框架。Fred Wilson和Marc Andreesen都很喜欢它，Ben Thompson、Benedict Evans和Tuur Demeester最近也把这个概念延伸到了大科技、智能手机和加密货币领域。
人们喜欢diss技术大佬，认为他们每隔10年就会重新发明一些东西，这是一个无休止的、没有意义的循环。但实际上，真正的大趋势往往会呈现出不同的形态。
X轴是20-50年的时间，Y轴是人口渗透率的百分比。在过去的一个世纪里，这种情况反复出现，随着我们在发行方面的改进，新技术被接纳的速度也在加快。
基本模式是：先经历一个初创阶段，然后是一个大规模增长的、技术竞争的 "狂热"阶段，之后一个转折点到来，技术达到协同和成熟（经常被比作埃弗雷特-罗杰斯的 "迟到的大多数 "和 "落伍者 "群体）。
“安装时代（Istallation Age）”的关注点是增长和创新，往往导致创造性的破坏（读作：大规模的用户流失）。“部署时代（Deployment Age）”的关注点是稳定和解决后来者，而这往往是更大的市场群体的需求。在前者，爱好者和投机者主导一切，事情往往比较简单。在后一种情况下，西装革履的商人占据了主导地位，很多时间都会花在琐碎的细节上。
JavaScript框架的部署时代
我认为JS框架的转折点是从一两年前开始的。我们不再每个月都有一个新的前端框架。React已经在Hacker News Job Board上占据了31个月的榜首。但不仅仅是React，Vue和Angular都在规模较大的公司中找到了非常稳定的应用，而这些公司在短期内不会轻易迁移技术栈。
部署时代带来了 “元框架” --围绕框架建立的框架的兴起，元框架的出现意在解决原来框架没有设计好的部署问题。React有Next.js和Gatsby，Vue有Nuxt.js和Gridsome，Svelte有Sapper，Angular最近甚至有了Scully。在大多数情况下，这些框架都是为了控制单个DOM元素并管理其中的动态元素树而设计的，他们的元框架将其扩展到覆盖整个网站/应用，包括路由和静态/服务器端渲染。
我是个漫威死忠粉，所以我喜欢把元框架比作包裹在钢铁侠套装上的反浩克装甲——它们更重、但更强大。
React“发行版”
现在我们来谈谈React“发行版”。
很显然，这个比喻是很恰当的。打个比方，React是Linux，Vue是MacOS，Angular是Windows。只是前端框架的世界里Linux的数量最多。有几十个Linux发行版为不同类型的用户打造，都共享相同的底层技术。就React在浏览器之上执行操作系统的许多功能而言，这简直是贴切的真实比喻。
这就是我在去年观察到的：
React拒绝在样式和路由等方面发表意见，是用户最大的挫败感来源，却也是其成功的最大原因。 没有一个叫React的框架，而是一千多个匠心制作的框架。React能得到所有这些框架带来的好处。
这既是React最好的特点，也是其最糟的特点--它的体积小，而且对很多基本的东西都没有指导意见。这意味着你不仅可以选择与它搭配的东西，你还必须做出选择。
我不同意James的观点，CRA是一个bootloader--我认为它也是一个React发行版，对于单页应用来说是一个不错的发行版，但还不能说是一个完美的发行版。
这里是一个不完整的React发行版列表。
- React Native - 一个为iOS和Android应用构建的发行版。少有的几个React发行版之一，实际上包含了很好的默认组件（因为目标生态系统有）。
- React Boilerplate--可能是最早的React发行版，只是一个可以克隆的boilerplate。
- Electron React Boilerplate--适用于桌面应用。
- React 360 - React for VR吗，当然。
- React Ink - React for CLI's吗，为什么不。
- Next.js - 混合服务器、无服务器和静态渲染。插件的故事出奇的萌。页面拉数据。
- Gatsby.js - Static Rendering with GraphQL data layer。插件丰富。你可以将数据推送和拉入/拉出页面。
- React Static - 带有简单数据层的静态渲染。您可以将数据推送到页面。
- Create React App - 没有数据层的单页App启动器。
- Ionic React - 100多个优秀的React组件，具有跨平台的目标和React Router内置在引擎盖下。
- Docusaurus - 以文档为中心的静态渲染。从markdown到预设模板的锁定式工作流程。
- Storybook - Component Library游乐场，可以做文档和显示非React组件。
- Meteor.js - 一个全栈框架，后来采用了React。
- Redwood - Tom Preston-Werner即将推出的全栈框架，包括一个后端GraphQL层。
- Blitz.js--Brandon Bayer的新Rails+React元框架。
甚至还有元框架之上的元框架。
- Navi和CURA是James的项目，在CRA的基础上增加了一些路由和SSR的功能。
- Docz - 在Gatsby的基础上，使用默认的TypeScript和MDX设置对文档进行静态渲染。
- Expo--一个注重开发者体验的优秀React Native发行版。
- React Native Web--一个网络的RN发行版。请看我关于RN奇点的文章
- React XP - 微软的RN发行版，包括向Windows本地应用程序构建。
而Parcel和可能的Rome遵循Collapsing Layers论文，将元框架折叠到构建工具中（而不是让元框架包围构建工具）。当然，React Native有Metro这个专门的捆绑器，Hermes有专门的JS引擎。
还应该有哪些 React发行版
不过我同意James的观点，认为应该有更多的React Distros，尤其是当我们开始解决社区内明确定义的用例时。他写道:
但无论如何，这是我理想中的React发行版。
开箱即用的SSR
简单的CSS-in-JS，只要你想要。
Sane默认的路由和数据获取/缓存，以及...
不需要GraphQL也能工作 像CRA一样构建，但...
允许Webpack配置
和到基于fs的路由
除了我喜欢基于fs的路由外，大部分我都同意😂。
我觉得有一堆的toggles，你可以一边体验一下他们，一边想想自己的需求、推出自己的React发行版，或者使用现成的发行版。我们在/r/Reactjs 现状调查中涉及到了其中一些内容。
- build target（doc 静态页面 SPA 等）
- 状态管理
- 数据层
- styling
- 支持TypeScript
- 测试
请注意，由于React Router的事实主导地位，所以缺少了Routing，当然Gatsby、Next.js、React-Static和Navi由于需要整合数据层，也包含了自己的路由器。React Native曾经在路由方面有更多的争夺，但现在React Navigation似乎是事实上的。
我恰好认为STAR应用是一套维护良好的应用的意见。我也特别喜欢尾风和React模型的classNames的搭配，这也是为什么我做了Rincewind作为一个基本的概念验证。
在编写格式方面，我也认为我们还有一段路要走。JSX文件几乎肯定不是事情的最终状态。我在Vue的启发下对React SFC提案进行了初步尝试，但我认为Storybook实际上用Component Story Format做对了，我认为React SFC看起来会更接近标准化的ESM文件格式，而不是自定义模板（The Formats over Functions论文）。当然，MDX也是作为React短码的内容格式而存在的，但我认为它有潜力作为一个成熟的单文件组件格式--来自Svelte生态系统的MDSvex正在向这个方向发展。
React创作格式将需要一个专门的编译器，在宏观层面上，当你设计它来解决像Facebook那样的样式解决方案和支持Suspense的渲染即获取解决方案时，这就变得特别有趣。但即使是在微观层面，我们也经常谈论一个足够高级的编译器，用于React的低级钩子让我们做的所有模板优化。我确实认为我们可以设计更多的语法来让这一切更加符合人体工程学。当然，如果我们要做一个编译器，我们也可以做一个优化的编译器! 如果我们不真正依赖React的细微行为和事件系统，那么就利用Preact？我打赌这听起来比实际情况要简单得多）。
正如Tom Dale在2017年观察到的那样，编译器是新的框架。但React会走Svelte、Vue和Angular的路，并打破自己的运行时吗？不会，它还有其他的顾虑。
给造轮子的人的 React发行版
为什么只有App开发者才能有React Distros？（造轮子的人就不配拥有姓名React Distros吗）
我在探索 creat-react-library 的过程中第一次和Travis Fischer 结交。我还帮助维护TSDX，这是一个用于构建React + TypeScript库的工具链，比如Formik。当我们有把握说部署阶段的各种基础已经趋于稳定时，我们就可以开始造轮子来帮助我们造轮子了。
