为什么inferno.js这么快？ - 知乎904被浏览<strong class="NumberBoard-itemValue" title="4分享邀请回答34917 条评论分享收藏感谢收起Javascriptreport 近日发布了一篇文章来比较流行前端框架的走势。走势图是通过统计最新的数据，并与前一年的数据进行比较而生成。数据来源于 npm trends 的每日下载量。
前端框架三巨头 React、Angular 和 Vue ，虽然都很受欢迎，且保持着上升趋势，但 Vue 爆发力最强，但在使用率上，仍低于 React 和 Angular 。
如果按目前的趋势继续下去的话，Vue 或将会在 2018 年底或 2019 年初取代 Angular ，成为使用率第二大的框架。
另外三个老牌但较有影响力的框架，AngularJS、Backbone 和 Ember ，虽然如今在知名度上弱于前面的三巨头，但过去一年仍保持增长趋势。
有意思的是，你会发现 AngularJS 实际上比 Vue 的下载量更高。Vue 在去年年底超过了 AngularJS ，但在今年 1 月的最新数据中，AngularJS 出现了较大的波动。当然，这不会影响 Vue 的长期趋势。
下面同样是非常优秀的一组框架对比：Preact、Inferno、Aurelia、Polymer 和 Svelte 。
其中，Inferno、Preact 和 Svelte 的增长率仅低于 Vue 。Preact 是该梯队的领导者，有望成为最受欢迎的 React 替代品。
特别声明：本文为网易自媒体平台“网易号”作者上传并发布，仅代表该作者观点。网易仅提供信息发布平台。
一键安装官方客户端
重大事件及时推送 阅读更流畅
http://dingyue.nosdn.127.net/ZsOsOV&#x3D;uuNLdkMLxNPmGWuJgsy9bC42cuR28nu1R2OOUP0.jpeg没有更多推荐了，
不良信息举报
举报内容：
前端框架三巨头：React仍是老大，Vue 增长率最高
举报原因：
原文地址：
原因补充：
最多只允许输入30个字
加入CSDN，享受更精准的内容推荐，与500万程序员共同成长！前端工程师必知：2017 年崛起的JS项目阅读高新技术日新月异，近几年 JS 社区创新和演化的速度是有目共睹的，几个月前比较时髦的技术很可能现在已经过时了，哪些是目前JS社区的主流趋势。
从数量上来分析哪些项目 2016 年获得比较多的关注，具体的做法是比较各项目 2016 年在 Github 上新增 star 的数量。
1. 最受欢迎项目
仔细观察 2016 年排名前 10 的项目，你就能对 WEB 社区的演化方向有个直观的把握，概括如下：
3 个 UI 框架：Vue.JS,ReactandAngular 2
1 个新的 Node.js 包管理器：Yarn
创建桌面应用的首选：Electron
创建 react 新项目的首选：Create React App
1 个移动开发框架：React Native
最受欢迎的 CSS 工具箱：Bootstrap
函数式编程风格的状态管理库：Redux
强大兼具灵活的绘图库：D3
上面这些项目覆盖的领域，无疑证明了 JS 的通用性，印证了那句话：能被 JS 编写的，迟早都会被 JS 编写。
2016 年的最佳项目是...
Vue.JS2016 年新增超过 25000 个 star，意味着平均每天新增 72 个 star，超过了所有同类项目的流行速度，比如 React 和 Angular。 采用 Virtual DOM 来增强性能的Vue.JS v2于 2016 年 10 月发布。
　　2. 前端框架
前端框架的百花齐放也许是出现JS 疲劳的原因所在，新的框架、工具和库层出不穷，把创新的车轮推向前进。
概括来讲，前端框架可以分为两大类：
大而全的框架，包括创建现代 WEB 应用的所有功能特性，比如路由、数据获取、状态管理，典型项目有：Angular 1、Angular 2、Ember和Aurelia。
小而美、聚焦在 UI 层面的解决方案，典型项目有React、Vue.JS、Inferno...
3. Node.js 框架
2016 年创建和部署 Node.js 应用变得空前的容易，比如下面这些解决方案：
Webtask.io
类似于Gomix的项目则把 Node.js 的门槛降到不能再低，只要通过浏览器简单的点击拖拽就都能轻而易举的编写和分享Node.js 代码。
那么，如果想创建一个 WEB 应用，我们该选哪个框架呢？
Express已经成为开发 Node.js WEB 应用的标准框架，大多数工程师都很熟悉他的设计思想（极简的内核，但能让你用各种中间件来扩展他的功能）。
Koa，设计思想非常类似Express，区别在于它是使用 ES6 中的 generator 编写的，这种写法解决了大家所熟知的回调地狱问题。
Feathers，是用来实现面向服务架构的一种灵活的解决方案，非常适合创建 Node.js 微服务。
Nodal，用来创建基于 PostgreSQL 的无状态的、分布式的服务。
Keystone，是我所知的快速搭建基于 MongoDB 的管理后台的最佳解决方案，Keystone.js 基于数据模型的定义即可自动生成后台界面，支持常见的增删改查操作和灵活的数据过滤。
Sails，是一个全能的 MVC 框架，主要是受到 Ruby on Rails 启发，他已经存在很长时间，支持各种数据库，不管是 SQL 还是 No-SQL。
Loopback，内置了很多特性的成熟框架，支持基于 token 的认证，支持各种数据库。 Loopback 的“杀手锏”功能是 API 浏览器，该功能能让开发者用非常直观的方式查看所有的 API 接口，如果你需要创建 API 服务的话，它无疑是个很好的选择。
　　4. React 项目模板
React 是非常棒的 UI 库，但是基于现代 WEB 应用开发工作流创建 React 应用时仍然需要大量的配置才能把所有的部分拼凑到一起，如何创建一个“真实”的 React 应用呢？各种 React 项目模板（boilerplates）和启动工具箱（starter kits）就是来解决这个问题的，典型的有下面几个：
Create React App
Facebook 开源的，轻量级的解决方案，使用Create React App创建 React 应用非常的简单。Create React App的作者Dan Abramov(也是 Redux 的作者，目前供职于 Facebook) 在功能丰富和简单可靠之间取得了很好的平衡，没有酷炫的样式解决方案 (仅需纯粹的 CSS) ，没有服务端渲染，但是 React 应用开发的其他方面都浑然一体，开发者体验也非常棒。
相比于同类工具，如果你使用了Create React App，它会成为你项目的依赖，所有的黑科技都是不可见的，你只能看到你自己的应用代码，你可以随时更新这个依赖。
React boilerplate
React boilerplate则包含了 React 应用所需的一切，包括Redux以及基于 Web Worker 实现的离线功能。使用它可以创建“渐进式 Web 应用”（亦称“PWA”），如果想了解更多 PWA 的知识，可以阅读 Nicol&s Bevacqua 的这篇文章。
Next.js, 由来自Zeit的 busy folks 创建，支持服务端渲染，可以用来创建 universal 应用（或者“同构应用”），直白点说，这种应用的前后端可以运行相同的代码。
5. 移动开发
JS 的通用性是毋庸置疑的，现如今可以用 WEB 工程师非常熟悉的技术（HTML、JS、CSS）构建 Native 移动应用。
React Native
使用 React Native，可以用类似于 React 思路，用同一份代码构建出支持 iOS 和 Android 平台的、真正的 Native 应用；
Ionic是 “hybird” 应用开发领域的先锋，底层基于 Cordova 来访问移动设备的系统功能，社区和生态系统非常成熟。
Native和React Native的目标是相同的，即基于 WEB 技术构建 Native 应用，其核心分为两部分：Native 内核，Native + Angular 2。
展望未来...
Weex是 2017 年需要密切留意的项目，他是基于Vue.JS的、用来创建跨平台移动应用的框架。
6. 编译工具
我们这里讨论的是把其他语言或者 JS 变体编译（Compiler）或转换成（Transpiler）标准 JS 代码的工具，这些工具生产出来的代码可以在浏览器或者 Node.js 环境中执行。
最常见的场景是，这类编译工具能够让开发者使用 ES6 语法编写代码，而不用担心浏览器支持情况。
最具潜力的编译工具可能是Type了，它为 JS 带来了类似于 Java 和 C# 的静态类型，而Angular 2完全使用 Type 的事实让他看起来更诱人；
Babel+ webpack 已经成了 ES6 代码转换、React 模板编译的标准工具组合，Babel最初是用来编译 ES6 的，但得益于他的插件系统，如今俨然已经演化成一个用途广泛，几乎能实现各种代码转换的工具。
Flow并不是一个编译工具，它只是一个基于 JS 代码标记的静态类型检查工具，也就是说，使用 Flow 时需要在代码中添加各种注释来注明需要的数据类型。
Flow 在很多 Facebook 项目的源代码中都有使用，而 Facebook 已经成为开源社区的重要玩家，开源了React、React Native、Flux、Immutable、Jest等众多的项目，相信你明白这意味着什么。
Coffee的简洁语法大量借鉴了 Python 和 Ruby 的语言特性，过去几年曾经是最受欢迎的编译器，但 2016 年很多开发者从 Coffee 转向了 ES6 +Babel组合。
7. 构建工具
2016 年“构建过程”似乎成了 WEB 项目的标配，如果一个 WEB 应用没有构建过程则是难以想象的事情，在构建过程中通常你需要做编译模板、静态资源合并压缩之类的事情，已为生产环境做好准备。
Webpack是构建单页应用（SPA）的主要工具，它和 React 生态结合的非常好，最新发布的 Webpack 2 带来了不少非常有前景的改进，具体可以阅读这里。
Gulp是一个通用的任务运行工具，可以在任何和文件系统打交道的自动化流程中使用，可以认为它并不是Webpack和Browserify的直接竞争者。
和Grunt类似，Gulp 的主要角色是任务管理，你可以让它压缩合并代码，但是它不会帮你处理 JS 模块化问题，而Webpack和Browserify是可以的。
当然了，Gulp 可以和 Webpack 结合起来使用，即使开发者倾向于使用 npm 也是可以的，实际上很多开发者就是这么做的。
Browserify
Browserify因为非常简单，在 Node.js 工程师群体中比较受欢迎。简单来说，它把多个 Node.js 的包作为输入，然后输出单个编译后的文件。相比而言，Webpack在 WEB 应用打包方面考量更多，更适合现代的 WEB 开发工作流。
展望未来...
2017 年需要留意的模块打包工具是rollup，它强调的是性能，基于 ES6 的模块规范，并且支持 Tree Shaking 这种黑科技，构建产生的结果只包含实际业务逻辑用到的代码，而不是简单的文件合并。
8. 测试框架
相比于流行了很久的测试框架Jasmine和Mocha，2016 年出现了 2 个更新的、并有很多人使用的测试框架：AVA和Jest。
AVA由非常高产的Sindre Sorhus开发和维护，其标榜的重点是性能和 ES6，能够并行的运行测试。AVA 的语法非常类似Tape和Node-tap。
Jest，又一个 Facebook 开源项目，最近几个月引起了大量的开发者注意，在 React 社区更加流行，并且越来越多的人开始迁移到 Jest，2017 年 Jest 极有可能成为最受欢迎的测试框架。
Jest 内置了非常强大的 Mock 特性，而其他的测试框架通常需要依赖第三方的 Mock 包，比如Sinon.JS。
　　9. IDE
说到 IDE（集成开发环境，Integrated Development Environment），令人振奋的是最受欢迎的 2 款 IDE 都是用 WEB 技术开发的开源项目。
Visual Studio Code
微软的Visual Studio Code在 WEB 开发者群体中非常受欢迎，因为他提供了非常棒的Type和 Node.js 集成，部分开发者甚至特别提到Visual Studio Code的智能感知功能极大的提高了开发效率。现在把微软和开源放在一起，终于不那么违和了。
Atom由 Github 开源，使用Electron构建，在受欢迎程度上并没有落后Visual Studio Code太多，关于 Atom 的一个有趣事实是，他所使用的主要语言是 Coffee。
　　10. 静态网站生成器
静态网站生成器（SSG）是指能够生成一大坨 HTML、CSS、JS 文件方便你快速部署到简单的 WEB 服务器上而不用安装和配置数据库的工具。就像Gatsby所标榜的：
像 1995 年那样构建网站。
静态网站的特点是速度快、健壮性高、容易维护。
静态网站如此流行的重要原因是市面上有很多非常好用并且免费的静态网站托管解决方案，比如：
Github pages
Gitlab pages
Now static
2016 年最流行的静态网站生成工具是Hexo，他有点类似于 Workdpress 这样的 CMS 系统，可以用来方便的创建博客网站，他还有很多其他的特性，比如国际化插件。
新玩家Gatsby是一个比较有趣的解决方案，相比于竞争者优秀的地方在于：它使用 React 生态系统来生成静态文件，可以组合 React Component、Markdown 和服务端渲染来完成静态网站生成让他更强大。
总结和展望
虽然 2016 年出现了“JS 疲劳”，也发生了戏剧性的事件(如&leftpad 门&)，但总体来讲 2016 年对 JS 社区来说是非常重要的一年，部分项目在 2016 年崛起，如Vue.JS和React Native，还有些黑马项目 2016 年诞生，如Yarn和Create React App。
接下来该思考 2017 年了，哪些将会持续获得开发者的青睐？哪些会成为新星呢？下面是10 个2016 年比较欣赏并且 2017 年会继续保持增长的项目或创意：
Vue.JS：还在快速增长阶段
Create React App
React Native
Yarn：快速、可靠并且安全的依赖管理工具，可以直接替代 npm
PWA（Progressive Web Applications）渐进式 WEB 应用
Node.js 微服务的一站式部署和运行解决方案，比如Now
Node.js的进化：最新版本对 ES6 语法的支持已经非常好了
最后是GraphQL：这会是一个大的进步
更多资讯关注微信公众号：zmxyitJavaScript 启动性能瓶颈分析与解决方案 - WEB前端 - 伯乐在线
& JavaScript 启动性能瓶颈分析与解决方案
在 Web 开发中，随着需求的增加与代码库的扩张，我们最终发布的 Web 页面也逐渐膨胀。不过这种膨胀远不止意味着占据更多的传输带宽，其还意味着用户浏览网页时可能更差劲的性能体验。浏览器在下载完某个页面依赖的脚本之后，其还需要经过语法分析、解释与运行这些步骤。而本文则会深入分析浏览器对于 JavaScript 的这些处理流程，挖掘出那些影响你应用启动时间的罪魁祸首，并且根据我个人的经验提出相对应的解决方案。回顾过去，我们还没有专门地考虑过如何去优化 JavaScript 解析/编译这些步骤；我们预想中的是解析器在发现&script&标签后会瞬时完成解析操作，不过这很明显是痴人说梦。下图是对于 V8 引擎工作原理的概述：
下面我们深入其中的关键步骤进行分析。
在启动阶段，语法分析，编译与脚本执行占据了 JavaScript 引擎运行的绝大部分时间。换言之，这些过程造成的延迟会真实地反应到用户可交互时延上；譬如用户已经看到了某个按钮，但是要好几秒之后才能真正地去点击操作，这一点会大大影响用户体验。
上图是我们使用 Chrome Canary 内置的 V8 RunTime Call Stats 对于某个网站的分析结果；需要注意的是桌面浏览器中语法解析与编译占用的时间还是蛮长的，而在移动端中占用的时间则更长。实际上，对于 Facebook, Wikipedia, Reddit 这些大型网站中语法解析与编译所占的时间也不容忽视：
上图中的粉色区域表示花费在 V8 与 Blink&#8217;s C++ 中的时间，而橙色和黄色分别表示语法解析与编译的时间占比。Facebook 的 Sebastian Markbage 与 Google 的 Rob Wormald 也都在 Twitter 发文表示过 JavaScript 的语法解析时间过长已经成为了不可忽视的问题，后者还表示这也是 Angular 启动时主要的消耗之一。
随着移动端浪潮的涌来，我们不得不面对一个残酷的事实：移动端对于相同包体的解析与编译过程要花费相当于桌面浏览器2~5倍的时间。当然，对于高配的 iPhone 或者 Pixel 这样的手机相较于 Moto G4 这样的中配手机表现会好很多；这一点提醒我们在测试的时候不能仅用身边那些高配的手机，而应该中高低配兼顾：
上图是部分桌面浏览器与移动端浏览器对于 1MB 的 JavaScript 包体进行解析的时间对比，显而易见的可以发现不同配置的移动端手机之间的巨大差异。当我们应用包体已经非常巨大的时候，使用一些现代的打包技巧，譬如代码分割，TreeShaking，Service Workder 缓存等等会对启动时间有很大的影响。另一个角度来看，即使是小模块，你代码写的很糟或者使用了很糟的依赖库都会导致你的主线程花费大量的时间在编译或者冗余的函数调用中。我们必须要清醒地认识到全面评测以挖掘出真正性能瓶颈的重要性。
我曾不止一次听到有人说，我又不是 Facebook，你说的 JavaScript 语法解析与编译到
底会对其他网站造成什么样的影响呢？对于这个问题我也很好奇，于是我花费了两个月的时间对于超过 6000 个网站进行分析；这些网站囊括了 React，Angular，Ember，Vue 这些流行的框架或者库。大部分的测试是基于 WebPageTest 进行的，因此你可以很方便地重现这些测试结果。光纤接入的桌面浏览器大概需要 8 秒的时间才能允许用户交互，而 3G 环境下的 Moto G4 大概需要 16 秒 才能允许用户交互。
大部分应用在桌面浏览器中会耗费约 4 秒的时间进行 JavaScript 启动阶段（语法解析、编译、执行）：
而在移动端浏览器中，大概要花费额外 36% 的时间来进行语法解析：
另外，统计显示并不是所有的网站都甩给用户一个庞大的 JS 包体，用户下载的经过 Gzip 压缩的平均包体大小是 410KB，这一点与 HTTPArchive 之前发布的 420KB 的数据基本一致。不过最差劲的网站则是直接甩了 10MB 的脚本给用户，简直可怕。
通过上面的统计我们可以发现，包体体积固然重要，但是其并非唯一因素，语法解析与编译的耗时也不一定随着包体体积的增长而线性增长。总体而言小的 JavaScript 包体是会加载地更快（忽略浏览器、设备与网络连接的差异），但是同样 200KB 的大小，不同开发者的包体在语法解析、编译上的时间却是天差地别，不可同日而语。
打开 Timeline( Performance panel ) & Bottom-Up/Call Tree/Event Log 就会显示出当前网站在语法解析/编译上的时间占比。如果你希望得到更完整的信息，那么可以打开 V8 的 Runtime Call Stats。在 Canary 中，其位于 Timeline 的 Experims & V8 Runtime Call Stats 下。
打开 about:tracing 页面，Chrome 提供的底层的追踪工具允许我们使用disabled-by-default-v8.runtime_stats来深度了解 V8 的时间消耗情况。V8 也提供了来介绍如何使用这个功能。
WebPageTest 中 Processing Breakdown 页面在我们启用 Chrome & Capture Dev Tools Timeline 时会自动记录 V8 编译、EvaluateScript 以及 FunctionCall 的时间。我们同样可以通过指明disabled-by-default-v8.runtime_stats的方式来启用 Runtime Call Stats。
更多使用说明参考我的点击预览。
我们还可以使用 Nolan Lawson 推荐的来评估语法解析的时间。不过这种方式可能会受 V8 预解析过程的影响，我们可以借鉴 Nolan 在 optimize-js 评测中的方式，在脚本的尾部添加随机字符串来解决这个问题。我基于 Google Analytics 使用相似的方式来评估真实用户与设备访问网站时候的解析时间：
工具能够模拟某些受限环境来评估页面的语法解析与执行时间。其将本地脚本包裹在了某个仪表工具代码内从而使我们的页面能够模拟从不同的设备中访问。可以阅读 Daniel Espeset 的 一文来了解更详细的使用方式。
减少 JavaScript 包体体积。我们在上文中也提及，更小的包体往往意味着更少的解析工作量，也就能降低浏览器在解析与编译阶段的时间消耗。
使用代码分割工具来按需传递代码与懒加载剩余模块。这可能是最佳的方式了，类似于这样的模式鼓励基于路由的分组，目前被 Flipkart, Housing.com 与 Twitter 广泛使用。
Script streaming: 过去 V8 鼓励开发者使用async/defer来基于实现 10-20% 的性能提升。这个技术会允许 HTML 解析器将相应的脚本加载任务分配给专门的 script streaming 线程，从而避免阻塞文档解析。V8 推荐尽早加载较大的模块，毕竟我们只有一个 streamer 线程。
评估我们依赖的解析消耗。我们应该尽可能地选择具有相同功能但是加载地更快的依赖，譬如使用 Preact 或者 Inferno 来代替 React，二者相较于 React 体积更小具有更少的语法解析与编译时间。Paul Lewis 在最近的中也讨论了框架启动的代价，与 Sebastian Markbage 的不谋而合：最好地评测某个框架启动消耗的方式就是先渲染一个界面，然后删除，最后进行重新渲染。第一次渲染的过程会包含了分析与编译，通过对比就能发现该框架的启动消耗。
如果你的 JavaScript 框架支持 AOT（ahead-of-time）编译模式，那么能够有效地减少解析与编译的时间。Angular 应用就受益于这种模式：
不用灰心，你并不是唯一纠结于如何提升启动时间的人，我们 V8 团队也一直在努力。我们发现之前的某个评测工具 Octane 是个不错的对于真实场景的模拟，它在微型框架与冷启动方面很符合真实的用户习惯。而基于这些工具，V8 团队在过去的工作中也实现了大约 25% 的启动性能提升：
本部分我们就会对过去几年中我们使用的提升语法解析与编译时间的技巧进行阐述。
Chrome 42 开始引入了所谓的的概念，为我们提供了一种存放编译后的代码副本的机制，从而当用户二次访问该页面时可以避免脚本抓取、解析与编译这些步骤。除以之外，我们还发现在重复访问的时候这种机制还能避免 40% 左右的编译时间，这里我会深入介绍一些内容：
代码缓存会对于那些在 72 小时之内重复执行的脚本起作用。
对于 Service Worker 中的脚本，代码缓存同样对 72 小时之内的脚本起作用。
对于利用 Service Worker 缓存在 Cache Storage 中的脚本，代码缓存能在脚本首次执行的时候起作用。
总而言之，对于主动缓存的 JavaScript 代码，最多在第三次调用的时候其能够跳过语法分析与编译的步骤。我们可以通过chrome://flags/#v8-cache-strategies-for-cache-storage来查看其中的差异，也可以设置 js-flags=profile-deserialization运行 Chrome 来查看代码是否加载自代码缓存。不过需要注意的是，代码缓存机制仅会缓存那些经过编译的代码，主要是指那些顶层的往往用于设置全局变量的代码。而对于类似于函数定义这样懒编译的代码并不会被缓存，不过 IIFE 同样被包含在了 V8 中，因此这些函数也是可以被缓存的。
允许在后台线程中对异步脚本执行解析操作，可以对于页面加载时间有大概 10% 的提升。上文也提到过，这个机制同样会对同步脚本起作用。
这个特性倒是第一次提及，因此 V8 会允许所有的脚本，即使阻塞型的&script src=''&脚本也可以由后台线程进行解析。不过缺陷就是目前仅有一个 streaming 后台线程存在，因此我们建议首先解析大的、关键性的脚本。在实践中，我们建议将&script defer&添加到&head&块内，这样浏览器引擎就能够尽早地发现需要解析的脚本，然后将其分配给后台线程进行处理。我们也可以查看 DevTools Timeline 来确定脚本是否被后台解析，特别是当你存在某个关键性脚本需要解析的时候，更需要确定该脚本是由 streaming 线程解析的。
我们同样致力于打造更轻量级、更快的解析器，目前 V8 主线程中最大的瓶颈在于所谓的非线性解析消耗。譬如我们有如下的代码片：
JavaScript
(function (global, module) { … })(this, function module() { my functions })
(function (global, module) { … })(this, function module() { my functions })
V8 并不知道我们编译主脚本的时候是否需要module这个模块，因此我们会暂时放弃编译它。而当我们打算编译module时，我们需要重分析所有的内部函数。这也就是所谓的 V8 解析时间非线性的原因，任何一个处于 N 层深度的函数都有可能被重新分析 N 次。V8 已经能够在首次编译的时候搜集所有内部函数的信息，因此在未来的编译过程中 V8 会忽略所有的内部函数。对于上面这种module形式的函数会是很大的性能提升，建议阅读来获取更多内容。V8 同样在寻找合适的分流机制以保证启动时能在后台线程中执行 JavaScript 编译过程。
每隔几年就有人提出引擎应该提供一些处理预编译脚本的机制，换言之，开发者可以使用构建工具或者其他服务端工具将脚本转化为字节码，然后浏览器直接运行这些字节码即可。从我个人观点来看，直接传送字节码意味着更大的包体，势必会增加加载时间；并且我们需要去对代码进行签名以保证能够安全运行。目前我们对于 V8 的定位是尽可能地避免上文所说的内部重分析以提高启动时间，而预编译则会带来额外的风险。不过我们欢迎大家一起来讨论这个问题，虽然 V8 目前专注于提升编译效率以及推广利用 Service Worker 缓存脚本代码来提升启动效率。我们在 BlinkOn7 上与 Facebook 以及 Akamai 也讨论过点击预览。
类似于 V8 这样的 JavaScript 引擎在进行完整的解析之前会对脚本中的大部分函数进行预解析，这主要是考虑到大部分页面中包含的 JavaScript 函数并不会立刻被执行。
预编译能够通过只处理那些浏览器运行所需要的最小函数集合来提升启动时间，不过这种机制在 IIFE 面前却反而降低了效率。尽管引擎希望避免对这些函数进行预处理，但是远不如这样的库有作用。optimize-js 会在引擎之前对于脚本进行处理，对于那些立即执行的函数插入圆括号从而保证更快速地执行。这种预处理对于 Browserify, Webpack 生成包体这样包含了大量即刻执行的小模块起到了非常不错的优化效果。尽管这种小技巧并非 V8 所希望使用的，但是在当前阶段不得不引入相应的优化机制。
启动阶段的性能至关重要，缓慢的解析、编译与执行时间可能成为你网页性能的瓶颈所在。我们应该评估页面在这个阶段的时间占比并且选择合适的方式来优化。我们也会继续致力于提升 V8 的启动性能，尽我所能！
可能感兴趣的话题
o 138 回复
关于伯乐前端
伯乐前端分享Web前端开发，包括JavaScript，CSS和HTML5开发技术，前端相关的行业动态。
新浪微博：
推荐微信号
（加好友请注明来意）
&#8211; 好的话题、有启发的回复、值得信赖的圈子
&#8211; 分享和发现有价值的内容与观点
&#8211; 为IT单身男女服务的征婚传播平台
&#8211; 优秀的工具资源导航
&#8211; 翻译传播优秀的外文文章
&#8211; 国内外的精选文章
&#8211; UI,网页，交互和用户体验
&#8211; 专注iOS技术分享
&#8211; 专注Android技术分享
&#8211; JavaScript, HTML5, CSS
&#8211; 专注Java技术分享
&#8211; 专注Python技术分享
& 2018 伯乐在线