【Swyx Wang】React”发行版”与前端“元框架”——前端框架进入“部署时代”

转载自 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。当咱们有把握说部署阶段的各类基础已经趋于稳定时，咱们就能够开始造轮子来帮助咱们造轮子了。