扎稳阵脚，再进一步。
留神：原文发表于 2017-12-31，随着框架一直演进，局部内容可能已不实用。
给急不可待的小伙伴们的疾速入门：Sapper 文档 和疾速模板 starter template。
如果要列出完满的 Node.js Web 利用框架的特色，你可能会想到这些：
- 它应该反对服务端渲染（SSR），可能疾速初始化并加载内容，且对 SEO 敌对；
- 利用反对同构为更通用的服务端和客户端的代码，这是当下荒诞不经的趋势预期；
- 客户端利用反对与服务端渲染的 HTML 混写，绑定事件侦听到现有的元素上，而非从新渲染它们；
- 导航到其余页面快如闪电；
- 离线及其他渐进式 Web 利用个性，务必反对开箱即用；
- 首个展现的页面应该按需仅加载必要的 JavaScript 和 CSS，这意味着框架反对路由级别的主动代码宰割，及动静
import(...)以实现更细粒度的手动管制； - 性能毫不妥协；
- 绝佳的开发体验，应用热模块重载及其他辅助搭配工具；
- 生成的代码应该易于了解和保护；
- 框架应该是浅显易懂的，并且各个方面均可自定义，没有被 webpack 的配置锁死在某个框架中，以及少之又少会“暗藏玄机”；
- 一个小时内就能够将整个框架悉数习得，不论是久经沙场的新手，还是初入门径的新人。
Next.js 就非常靠近这个现实值。
如果你与 Next 还素未谋面，我强烈推荐你去看 learnnextjs.com 下面的教程学学。
Next 提出了一个绝妙的想法：你利用中所有的页面都是 your-project/pages 目录下的文件，每个文件都是一个 React 组件。
这是 Next 所有突破性设计的根基。
找到某个页面的代码轻而易举，只须要在文件系统中查看即可，而不必去猜想组件的名称是做什么的。
同时，对于用什么样的我的项目文件构造这类鸡毛蒜皮争论不休的事件便一去不再了。
而 SSR（服务器端渲染）及代码宰割的联合更是慌慌张张（不过 React 团队放弃了 Router，对那些尝试 SSR 和代码宰割的人说，“祝你好运！”）。
然而然而 —— 尽管 Next 这么美妙，恕我出言不逊，Next 依然美中不足：
- Next 应用“rout masking”的技术来创立更为好看的 URL（譬如
/blog/hello-world替换掉/post?slug=hello-world）。
这毁坏了应用程序构造与目录构造一一对应的保障，并迫使你保护这两种模式之间转换的配置。 - 你所有的路由都假设是“页面”。
但通常你须要一些服务端路由，比方 301 重定向，或者专门为页面提供数据的 API endpoint，而 Next 没有兼顾到这一点（注：Next 新版本曾经具备 API 路由能力）。
你能够将解决这类状况的逻辑写到server.js中，不过这样会让人感觉与页面申明的形式不太统一。 - 要应用客户端路由，链接不能是规范的
<a>标签。相同你必须应用框架指定的<Link>组件，譬如在这篇用 markdown 写的博客文章中的应用<Link>是不可能的了。
然而，真正的问题是，所有这些益处都是要付出代价的。
最简略的 Next 利用（仅展现一个“hello world”动态文本的页面），其 JavaScript 应用 gzip 压缩后是 66kb，解压后，它占用 204kb，对于挪动端来说这是一个十分宏大的代码量了，但这已是“最低生产”。此时，性能是决定你的用户是否会留下来的关键因素。
这事咱们能够做得更好！
编译器即框架的逆袭
Svelte 提出了一个激进的想法：如果你的 UI 框架压根就不是框架，而是一个编译器呢？如果它把你的组件编译成独立的 JavaScript 模块会怎么样呢？
咱们生成高度优化的一般的 JavaScript，而不是应用 React 或者 Vue 这些类库，其实它们对你的利用无所不知，因为框架必须提供一个通用的解决方案。
如果只生成利用所需的代码，便能够完全避免了基于虚构 DOM 计划的内存和性能开销。
JavaScript 畛域正在朝着这种趋势倒退。
Stencil 是一个来自 Ionic 团队的深受 Svelte 启发的轻量级框架，它反对编译为 Web Components。
Glimmer 虽说并没有编译为独立的 JavaScript（不深刻地讲了，要详尽叙述其优缺点的内容都能够独立成篇），然而团队正在围绕将模板编译为字节码做了一些乏味的钻研。
（React 当初也开始退出了这个营垒，只管他们目前钻研的重点是优化 JSX 的代码，这与近年来 Angular、Reactive 和 Vue 所做的预优化其实是殊途同归。）
试想一下，如果咱们破旧立新，尝试应用这种新的形式作为新的终点，其后果又将如何？
Sapper 简介
Sapper 或者能够答复这个问题（这个名字源于“工兵”，它也是“Svelte 应用程序制作器”的代名词）。
Sapper 是一个相似 Next.js 的框架，旨在满足前文提及的 11 个现实规范，同时极大缩小发送到浏览器的代码量。
它能够与 Express 的中间件兼容，这意味着它很容易了解和定制。
同样的“hello world”应用 React 和 Next 须要 204kb，而应用 Sapper，仅有 7kb。
随着咱们一直摸索其空间优化的可能性，这个数字将来会进一步降落，比方，除了解决客户端路由的微型 Sapper 运行时以外，其余状况压根不会为没有交互的页面发送任何 JavaScript。
有没有一个更实在的示例看看呢？
其实 RealWorld 就提供了这么一个开发中型我的项目的示例。
展现这个 RealWorld 示例的交互式首页，Sapper 的实现 仅需 39.6kb（压缩后 11.8kb）。
整个利用的尺寸是 132.7kb（压缩后为 39.9kb），远远小于用来参照的 React/Redux 327kb（85.7kb）的实现，即使 132.7kb 依然是挺大的，不过要害是，得益于代码宰割，它会使人感观上感觉跑起来十分疾速。
代码宰割当下早已蔚然成风了，不过如果你的利用应用了 React 或者 Vue 等传统的框架，代码宰割就有一个“最低生产”—— 框架自身，它可能占据整个应用程序总尺寸的很大一部分。
代码宰割也不是收费的 —— 譬如 React 等框架应用了代码宰割，它体积会更大。
不过如果应用的是 Svelte，状况就天壤之别。
当然，尺寸大小问题也不过是开发的关注点之一罢了。
Svelte 写的利用同时具备极高的性能和内存利用率，并且它蕴含了弱小的性能，而如果你抉择其余某个框架，搭配“小型”或者“繁难”的 UI 库的话，那么可能会就义掉这些货色。
衡量
对于许多开发者来说，Sapper 最大毛病是什么呢？
“我还是喜爱 React，而且用习用熟了。”—— 其实会这么感觉，也是无可非议。
如果你属于下面这个营垒的话，那我倡议你至多尝试一下其余框架，很可能你会叫苦不迭！
Sapper 的 RealWorld 实现，总共才 1,201 行代码，而其余框架须要 2,377 行，因为你能够应用十分简洁、易于表白的模板语法（只须要 5 分钟就能够上手）。
你还能享受到范畴受限的部分 CSS，内置了对未应用的款式主动删除和最小化能力，你也能够应用 Less 这样的预处理器。
这样你就不必再依赖 Babel 了。
而 SSR 也是十分地疾速，因为它只是字符串拼接而已。
咱们最近还退出了 svelte/store，这是一个小型的全局状态治理库，它能够零引入就能在组件层次结构之间同步状态。
就算是最蹩脚的状况下，你也会感觉本人的抉择是英明的！
尽管如此，咱们还是有值得衡量取舍之处。
你比方说，某些人对“模板语言”疾恶如仇，难道你就是其中之一？
JSX 的支持者会说“它其实就是 JavaScript”这样的话来刺激刺激你，React 最大的长处就是它这种写法有有限的灵活性。
对于这种灵活性，React 有其本人的一套衡量逻辑，总之一言难尽，咱们不在此开展过多探讨。
接着聊聊生态。
特地是 React 周边生态 —— 开发工具、编辑器集成、辅助类库、教程指南、StackOverflow 问答数量、框架本身的天坑以及工作机会等等……这些 React 几乎天下无敌。
诚然，如果你将“生态系统”视为选型的重要依据的话，阐明你已局限在集体技术的天花板了，势必成为你技能回升的枷锁。
但它仍旧是当下普惠开发者最重要的动作。
路线图
咱们还不会公布 v1.0.0 版本，因为还有很多变数在外面。不过置信不可企及了，想必届时会有许多令人兴奋的可能性。（注：事实上 v1.0 可能永远都不会公布，作者对技术有了一番新的思考）
我认为 Web 性能的下一个风口将会是“全应用程序优化”。
目前 Svelte 的编译器是作用在组件级别，编译器通过了解组件之间的边界，可能生成更无效的代码。
React 团队的 Prepack 钻研 也基于相似的想法，Glimmer 团队也在这一块做一些乏味的钻研。
Svelte 和 Sapper 能够很好地利用这些想法。
说起 Glimmer，咱们可能会在 2018 尝试借鉴他们“将组件编译为字节码”的想法。
试想一下，像 Sapper 这样的框架，能够依据利用的个性来决定应用哪种编译模式，它甚至能够为 JavaScript 的初始路由提供最快的启动工夫，而后为后续路由提供提早的字节码解释器，从而实现启动大小和应用程序总大小的最佳组合。
不过大多数状况下，咱们心愿 Sapper 的倒退方向由用户决定。
如果你乐于助咱们一臂之力，并心愿帮助咱们打造 Web 利用的将来，欢送退出 Github 和 Discord。
< The End >