最近参加了IMWebConf2017前端开发者大会，领略了大神的风采，洞悉了的当下的技术，了解了未来的Web开发技术，还有极为重要的一点就是更加关注Web的安全与性能。收获满满的同时，也认识到自己与大神的差距，对未来努力的方向也更加清晰了，甚至在公司与个人成长的矛盾也有了一些思考！整场会议下来，我就在一旁瑟瑟发抖，任重而道远！

概要

大会干货满满，分为综合会场和分会场，分会场可以任意穿场听，共有16场，内容真的很多。在这里仅针对性的做些简要总结，更多内容还需要自己慢慢学习。总得来说分为如下类别：

安全篇

CSRF攻击
XSS攻击
SSRF攻击
HPP攻击

性能篇

tree-shaking
...

应用篇

WebIM通信技术
WebRTC未来直播技术

当下篇

PWA与AMP
TypeScript
Egg&Node.js
抓包技术(fiddler)
前端全栈修炼之道

未来篇

BuckleScript
WebAssembly

接下来就我参加的每个讲座记录一下最直观的感受。

英语的重要性

平时你可能觉得英语不是很重要，但是到了一些场合就觉得贼重要，比如这次会议的第一场就由一个W3C组织的一位总裁Philippe开始，简单介绍一下W3C就是前端标准的制定者和标准推广者。英语类型的演讲让我一愣一愣的，印象深刻的是现场一位腾讯的姐姐担当起了翻译，本以为他是一个全职翻译，后来才发现她仅仅是兼职，她也是一名coder！

在当今社会，学好英语真的很重要，能帮助开阔自己的道路，在国内，如果走在技术的前沿，那么看英语技术文档是很平常的事，如果有幸能去国外上班，赚外国人的钱，学好英语也就更重要了！

现在的我在一心一意补习英语，应该是比较难了，但是也给自己定一个小目标，那就是在看国外博客或文档时，不能选择逃避，而是坚持看完，相信就会越来越顺利！

TypeScript

TypeScript作为JavaScript超集，带来了可选的静态类型检查以及最新的ECMAScript特性。虽说JavaScript语言是弱类型动态语言，是不需要编译的，转换一下角度的话，其实我们可以把TypeScript理解成一种新的开发语言，只不过他是兼容JavaScript的语法的，同时有大量的工具可以将它编译(转换)成纯JavScript。

TypeScript可以在任何浏览器、任何计算机和任何操作系统上运行，在目前现有的任何情况下，都可以添加TypeScript来开发。

关于调试的问题，最终在浏览器运行的时候是编译之后的纯JavaScript，但是我只想调试我最初的代码？有没有办法呢？微软肯定没有这么傻，这个问题早就考虑到了，因此不用担心这个问题！

个人总结的话，这个东西其实就是建立在JavaScript上的语法壳，解决了JavaScript语言的一些痛点，但是特性是可选的，因此也保留了JavaScript语言的灵活性，对此完全没必要恐惧或担心是一门新的技术，如果之前有强类型和面向对象的编程思想，我觉得是完全可以平滑过渡的！

BuckleScript

这个语言就厉害了，可以说是国人的骄傲了，国人开发的并被外国人广泛使用的编译器，你说牛逼不牛逼，作为BuckleScript开发者张宏波来到现场分享经验。

首先需要纠正的第一点就是BuckleScript的后缀Script了，他和JavaScript没有一点关系，Script原意脚本的意思哈，他其实是一个编译器，理论上可以编译成任何语言，目前貌似支持编译成JavaScript和VB语言。我听到这个是很震撼的，这是有这是有着一统江湖的雄心壮志哇。

这个编译器不仅仅只是编译成你想要的语言，比如JavaScript，同时具备很多使用的功能如下：

代码错误排查
无用代码支持可选删除
代码自动优化
编译速度快
...

有人就要问了，他怎么书写呢？这就是他另外一个特点了，学习成本相对高，作为熟悉过Java，C#与JavaScript语言的我，看这个语法是有点难以接受的。BuckleScript目前在国内比较小众，处于推广阶段，但是个人是比较看好他的！

PWA与AMP

这个章节是有google的工程师大牛分享的，我联想到的就是，Ionic框架的首页貌似提到过PWA，原话如下Ionic is the beautiful, free and open source mobile SDK for developing native and progressive web apps with ease.，但是可惜的是听完大神的分享，说实话没咋理解，印象最深的就是Service Worker，但是去can i use，查了一下兼容性目前不是很乐观，尤其是Apple的Safari完全不支持。因此就百度学习了一下，下面是简单的总结。

AMP

全称Accelerated Mobile Pages。AMP 主要由 AMP HTML、AMP Runtime 以及 AMP Components 三部分组成。

AMP HTML：AMP HTML 是 HTML 的子集，在 AMP HTML 中只允许使用有限的标签。
AMP Runtime：HEAD 区域最后外链引入的 JS 就是 AMP Runtime。AMP Runtime 提供对自定义元素（Custom Elements）的支持，负责协调资源的加载时机和优先级，以及提供验证器等调试功能。
AMP Components：AMP Components 是使用浏览器自定义元素（Custom Elements）实现的组件，用来替换 HTML 中默认的 <img> 和 <video> 等标签，用来实现对资源的自定义加载策略；它也用于实现一些复杂的交互效果。AMP Components 分为两类：内置组件和扩展组件，在 AMP HTML 引入了 AMP Runtime 之后，这些内置组件就可以直接使用，要使用扩展组件，需要在 AMP HTML 中引入该组件对应的文件。

PWA

全称Progressive Web App，下面看看大佬理解的PWA。

首先它是一个“涵盖性术语”：它泛指所有那些“利用现代 Web 技术以尝试在移动设备上提供顶级体验的 web app”；这个名词本身是发展且包容的，你不一定要使用到所有的现代 web 技术，而只要聪明地发挥技术的优势以提供优秀体验就好了。

PWA有哪些过人之处，值得我们来吹捧呢？

Add to Homescreen：可被添加到主屏
App Shell：第一次渲染渲个壳、等异步数据来了再填充
Offline：离线能力，离线和弱网环境也能秒开的能力，因此Chrome 搞了个 Service Worker 出来，给了 Web 一个可以跑在后台的线程，它可以搭配非常靠谱的 CacheStorage API 做缓存、可以拦截所有 HTTP 请求并使用 Fetch API 进行 response，一个非常完备的 Proxy 就这么诞生了。
Re-engageable：唤回/保持用户的能力，其实目前主要就是推送通知(Push Notification)。

PWA模型提出背景

在Node.js大行其道的环境下，产生很多基于 Node.js 的前端工程化方案：

Webpack、Rollup 这样的打包工具
Babel、PostCSS 这样的转译工具
TypeScript、Elm 这样转译至 JavaScript 的编程语言
React、Angular、Vue 这样面向现代 web 应用需求的前端框架及其生态
服务器端渲染（Server-side Rendering）与单页面应用模型（Single-page App）结合的 web 应用架构方式

但是，Web 应用在移动时代并没有达到其在桌面设备上流行的程度。究其原因，尽管上述的各种方案已经充分利用了现有的 JavaScript 计算能力、CSS 布局能力、HTTP 缓存与浏览器 API 对当代基于 Ajax 与响应式设计的 web 应用模型的性能与体验带来了工程角度的巨大突破，我们仍然无法在不借助原生程序辅助浏览器的前提下突破 web 平台本身对 web 应用固有的桎梏：客户端软件（即网页）需要下载所带来的网络延迟；与 Web 应用依赖浏览器作为入口所带来的体验问题。

在桌面设备上，由于网络条件稳定，屏幕尺寸充分，交互方式趋向于多任务，这两点造成的负面影响对比 web 应用免于安装、随叫随到、无需更新等优点，瑕不掩瑜。但是在移动时代，脆弱的网络连接与全新的人机交互方式使得这两个问题被无限放大，严重制约了 web 应用在移动平台的发展。在用户眼里，原生应用不会出现「白屏」，清一色都摆在主屏幕上；而 web 应用则是浏览器这个应用中的应用，使用起来并不方便，而且加载也比原生应用要慢。

Progressive Web Apps（以下简称 PWA）以及构成 PWA 的一系列关键技术的出现，终于让我们看到了彻底解决这两个平台级别问题的曙光：能够显著提高应用加载速度、甚至让 web 应用可以在离线环境使用的 Service Worker 与 Cache Storage；用于描述 web 应用元数据（metadata）、让 web 应用能够像原生应用一样被添加到主屏、全屏执行的 Web App Manifest；以及进一步提高 web 应用与操作系统集成能力，让 web 应用能在未被激活时发起推送通知的 Push API 与 Notification API 等等。

无需担心网络延迟；有着独立入口与独立的保活机制。之前两个问题的一并解决，宣告着 web 应用在移动设备上的浴火重生：满足 PWA 模型的 web 应用，将逐渐成为移动操作系统的一等公民，并将向原生应用发起挑战与「复仇」。

PWA 模型将继约 20 年前横空出世的 Ajax 与约 10 年前风靡移动互联网的响应式设计之后，掀起 web 应用模型的第三次根本性革命，将 web 应用带进一个全新的时代。

PWA 关键技术的前世今生

Web App Manifest：Web App Manifest，即通过一个清单文件向浏览器暴露 web 应用的元数据，包括名字、icon 的 URL 等，以备浏览器使用，比如在添加至主屏或推送通知时暴露给操作系统，从而增强 web 应用与操作系统的集成能力。
Service Worker：Service Worker 是一个可编程的 Web Worker，它就像一个位于浏览器与网络之间的客户端代理，可以拦截、处理、响应流经的 HTTP 请求；配合随之引入 Cache Storage API，你可以自由管理 HTTP 请求文件粒度的缓存，这使得 Service Worker 可以从缓存中向 web 应用提供资源，即使是在离线的环境下。
1. Service Worker 就像一个运行在客户端的代理
2. Service Worker 的生命周期
  - 出于安全考虑，注册 Service Worker 要求你的 web 应用部署于 HTTPS 协议下，以免利用 Service Worker 的中间人攻击。
3. Service Worker 的一种缓存策略：让网络请求与读取缓存比赛
Push Notification

Service Worker 对 PWA 的重要性相当于 XMLHTTPRequest 之于 Ajax，媒体查询（Media Query）之于响应式设计，是支撑 PWA 作为「下一代 web 应用模型」的最核心技术。

展望

来自 Nitobi 的 Brian Leroux 等人创造了 Phonegap，希望它能以 Polyfill 的形式、弥补目前浏览器与移动设备间的「鸿沟」，从此开启了混合应用（Hybrid Apps）的时代。

我们相信 Web，是因为相信它是解决设备差异化的终极方案；我们相信，当 Web 在今天做不到一件事的时候，是因为它还没来得及去实现，而不是因为他做不到。而 Phonegap，它的终极目的就是消失在 Web 标准的背后。

鱼与熊掌的兼得

经过几年来的摸索，整个互联网行业仿佛在「Web 应用 vs. 原生应用」这个问题上达成了共识：

web 应用是鱼：迭代快，获取用户成本低；跨平台强体验弱，开发成本低。适合拉新。
原生应用是熊掌：迭代慢，获取用户成本高；跨平台弱体验强，开发成本高。适合保活。

但是，PWA 的出现，让鱼与熊掌兼得变成了可能 —— 它同时具备了 web 应用与原生应用的优点，有着自己独有的先进性:「浏览器 -> 添加至主屏/安装 -> 具备原生应用体验的 PWA -> 推送通知 -> 具备原生应用体验的 PWA」，PWA 自身就包含着从拉新到保活的闭环。

WebAssembly

在参会准备前，我特意提前学习了一下这个，当时是很感兴趣的，但是由于他是面向未来的开发技术，同时时间上与有名的狼叔的分享冲突了，因此我就放弃他了，因为对于当前的我，我觉得未来的技术有一个概念就好啦，当下有太多的技术等着我学习与理解，因此我觉得狼叔分享的大前端全栈修炼之道应该是更适合我的。但在学习WebAssembly时，关于JavaScript性能优化历史还是很敢兴趣的！下面简单记载一下！

WebAssembly 是除了 JavaScript 以外，另一种可以在浏览器中执行的编程语言。所以当人们说 WebAssembly 更快的时候，一般来讲是与 JavaScript 相比而言的。

在代码的世界中，通常有两种方式来翻译机器语言：解释器和编译器。如果是通过解释器，翻译是一行行地边解释边执行。编译器是把源代码整个编译成目标代码，执行时不再需要编译器，直接在支持目标代码的平台上运行。

解释器的利弊

解释器启动和执行的更快。你不需要等待整个编译过程完成就可以运行你的代码。从第一行开始翻译，就可以依次继续执行了。

正是因为这个原因，解释器看起来更加适合 JavaScript。对于一个 Web 开发人员来讲，能够快速执行代码并看到结果是非常重要的。

可是当你运行同样的代码一次以上的时候，解释器的弊处就显现出来了。比如你执行一个循环，那解释器就不得不一次又一次的进行翻译，这是一种效率低下的表现。

编译器的利弊

编译器的问题则恰好相反。它需要花一些时间对整个源代码进行编译，然后生成目标文件才能在机器上执行。对于有循环的代码执行的很快，因为它不需要重复的去翻译每一次循环。

另外一个不同是，编译器可以用更多的时间对代码进行优化，以使代码执行的更快。而解释器是在 runtime 时进行这一步骤的，这就决定了它不可能在翻译的时候用很多时间进行优化。

如何提升JavaScript运行性能呢

Just-in-time 编译器：综合了两者的优点。为了解决解释器的低效问题，后来的浏览器把编译器也引入进来，形成混合模式。大致原理如下：

监视器：增加监视器监控着代码的运行情况，记录代码一共运行了多少次，如何运行的等信息。监视器监视着所有通过解释器的代码。如果同一行代码运行了几次，这个代码段就被标记成了 “warm”，如果运行了很多次，则被标记成 “hot”。
基线编译器：如果一段代码变成了 “warm”，那么 JIT 就把它送到编译器去编译，并且把编译结果存储起来。
优化编译器：如果一个代码段变得 “very hot”，监视器会把它发送到优化编译器中。生成一个更快速和高效的代码版本出来，并且存储之。

为了使执行速度变快，JIT 会增加很多多余的开销，这些开销包括：

优化和去优化开销；
监视器记录信息对内存的开销；
发生去优化情况时恢复信息的记录对内存的开销；
对基线版本和优化后版本记录的内存开销。这里还有很大的提升空间：即消除开销。通过消除开销使得性能上有进一步地提升，这也是WebAssembly所要做的事之一。

安全篇

在下午的分会场中，让我我印象最深刻的是Web安全问题，因为共四场，我听到了两场都和安全有关，而是他很吸引我！一场可以说是Web安全的一个总览，介绍了安全与防范措施，另一场则着重演示了XSS攻击的奇门怪招与具体的防范措施，看的我眼花缭乱，心生佩服，这也是我这段时间想重点学习的方向！因为觉得安全是一个系统稳定运行的基石，真的很重要！

这一块在我自己深入学习后，会单独详细总结，就不多说了。

视频篇

面向未来的直播技术-WebRTC，这个标题我一看到的时候就十分吸引我，2016年是直播经济的元年，直播平台如雨后春笋般诞生，虽然现在直播平台已经趋于稳定，但是在技术上我是十分感兴趣的。

今天发生的另外一件重要的事情就是Adobe宣布flash技术将在2020年停止维护更新，如今chrome浏览器也是默认关闭flash插件的，对于依旧使用flash技术的平台，会用弹窗的方式提醒用户允许才能继续使用，这对用户体验上也不是很友好。可以说H5的发展是杀死flash的直接杀手。

H5实现视频技术大致有三种方案，分别是HLS、flv.js和WebRTC，老师从延迟，兼容性等方面对比了三者，WebRTC是未来直播技术的佼佼者。

由于没有接触过视频直播这一块，听起来也是有点懵的，有时间和条件也会重点研究一下！

全栈

最后听得一个是小网红-狼叔的演讲，作为Node的布道师，此人风趣幽默有才华，自己有点被吸粉的感觉的。

他的演讲我觉得主要是从两个角度出发，第一就是Node是了不起的，第二全栈工程师发展之路。

Node是了不起的，并不是说他无所不能，你应该让他去做合适的事情，每个语言工具都有它适合的场景，比如你硬要用Node去做大数据(JAVA)方面的事情，你这不是为难人家嘛！

发展之路，我只能说要学的东西真的太多了，等我弄到他的PPT，完全可以作为接下来的学习指南哇~

其他

其他更多的由于分身无术，就不能在现场一一听到，不过听说在腾讯课堂到时候会有回放，等到有时间的时候，会一一学习或回顾、总结与深入，毕竟真的有太多的东西值得我吸收！

圆桌会议

在最后IMWeb团队有心的将所有讲师组织在一起，解答大家的疑问，我觉得这个环节还是很不错的，很多同行提的问题还是很有共鸣的。

Q:之前在小公司，写了很多的业务代码，觉得能力没有提高，最近跳槽到了一个大团队，我该如何迅速融入呢？

永远不要陷在业务里
这个没什么办法，静下心去沉淀技术
对此真是很有共鸣，现在的我就每天写业务代码，编程能力没什么提高，而且越写越烦

Q:我在公司什么事情都做，我可能一会需要写Java，一会需要写C，一会需要写前端，甚至有时候连UI工作都要坐？我改如何改变呢？

从此可以看出你们公司应该比较小，小公司杂，大公司专，这就看自己取舍了，事情杂肯定不利于自己的成长，如果你选择做技术的话，建议你赶紧换平台，如果不选择做技术的话，可以任劳任怨，赢得老板信任，走管理路线！
可以尝试性的结合自己当前的兴趣和能力，结合公司业务的同时，在公司推你的解决方案，如果不行，大不了换公司呗！
我现在做的事情就很杂，这个在小公司确实无法避免，宝宝心里苦！

Q:我是即将毕业的大学生，对于马上踏入计算机行业的我，能提供几点忠告吗？

掌握基础，大学的课程真的很重要，比如计算机网络，操作系统等！
如果有机会，尽量在大三的时候就可以争取去大平台实习的机会，前几年的成长对你们来说真的很重要！
我个人是十分赞同的，我现在在一个小公司小平台，实在苦不堪言，为了自己的成长，想尽快跳出来！

Q:现在前端MV*框架这么多？比如react，ng，vue等，您推荐我学哪个呢？或者评价一下各框架的优缺点？

你这个问题不好回答，会引起掐架，会被打死，哈哈。具体你需要结合自身实际情况和公司情况进行选项！
我个人的话不纠结这个问题，前端没有什么常青树，不要纠结学什么，只管去学就对了，理解了思想，掌握了基础，学什么都不难！

Better

IMWebConf2017前端开发者大会

概要