2017前端技术预览(未完结,最后更新于1月7日)

Kamunape

Kamunape

发表于 2017-01-07 16:40:16

(删掉了第一小段,因为和内容关系不大。。)

本来这该是个技术分享会的内容,参加完 Google Developer Day(GDD) 后想做个 AI Demo 来分享,奈何技术实力不够,害怕把大家带进沟里,想想还是讲比较擅长的前端领域的比较靠谱。等哪天经历过人工智能相关项目后再分享也不迟。

图:在 GDD 上海站围观 TensorFlow 与艺术分享会

Progressive Web Apps

Progressive Web Apps(PWA)指代那些使用最新的 Web 技术构建的类似原生 App 体验的 webapp,这也是今年前端最热词之一,虽然感觉说来说去就是为了一堆新技术取个名字,就像之前的 HTML5 一样。不过,这些技术确确实实提高 Web 的用户体验。

为此各大浏览器厂商都卯足了劲(我是说除了Safari,连 IE 都在努力了啊喂!),这篇文章将从三个方面来讲解这些技术:

  1. 可靠,即使网络不稳定也需要提供服务;

  2. 更快;

  3. 功能更丰富!

(恰好 PWA 也这么认为)

这些都是为了让 WebApp 能像 App 一样提供沉浸式的用户体验。

技术是为内容服务的,单纯的技术没法让我们爬到馬斯洛需求理論的更高层,但是技术一直在为实现它而努力。接下来将要介绍的就是2016年各大浏览器厂商为前端技术做出的努力。(本文不包括类似 async 函数、Promise、以及 Websocket 之类的一些“老技术”)

图:只有Safari还在考虑是否实现 Service worker,连 IE 都在努力你 Safari 凭啥不努力。。。

可靠

技术关键词:Service WorkerBackground Sync

相对于 App , Web 最痛的点在于如果网络不靠谱,一切无从谈起。打开任何一个页面,WebApp 都需要经过下载、解析并初始化代码、执行路由逻辑跳转到相应页面、请求网络数据、渲染页面...而性能瓶颈最容易出现在网络部分。设想如果可以预先将网页的外壳安装到设备上,启动时从本地加载这层壳,并请求网络获取渲染需要的数据,甚至更极端一点,数据全存在本地磁盘,启动时优先使用的本地已经保存同步好的数据,保证即使在 Lie-Fi* 环境下也能提供正常服务。

注:Lie-Fi是比断网更要命的移动网络。症状是手机告诉你你已经联网,但是网页却打不开,甚至连“Chrome小恐龙”都不让玩。

图: 这就是那只“Chrome小恐龙”

在讲 Service worker 之前,浏览器中已经实现了一个类似的功能,叫 AppCache ,AppCache 的运行原理不复杂,就是在网页加载完成后,浏览器闲下来的时下载一个清单文件,这个文件列明了哪些资源可以离线使用,哪些资源需要请求网络,如果请求不到网络该怎么办等等。类似一个配置清单。

图:AppCache在首次启动页面时缓存数据到磁盘,此后打开的页面如果有用到已缓存的资源则直接由缓存提供。

不过,HTTP 缓存在上古时期就实现了这个功能,看起来只是换了个马甲。

的确,理论上 HTTP 缓存完全能实现这个功能,但实际却不是这样,由于浏览器厂商很多、版本也多,相互之间兼容性或多或少有些差异,如果某个浏览器对程序员的失误容忍程度过低,很容易导致渲染出现问题。类似问题也出现在 HTTP 请求上,如果浏览器严格按照请求头的缓存控制规则来控制网络请求,很容易导致页面无法更新或者部分更新、新旧代码混合的问题。所以大部分浏览器倾向不完全相信 HTTP 请求头。这也从另一个方面印证了“单一职责原则“的重要性(传输数据的就好好传输数据,别抢人家缓存的饭碗,你也抢不来。。)。

嗯,看起来 AppCache 比 HTTP 缓存棒多了,功能强大而且单一职责,只要一份清单文件就能把资源都缓存起来离线访问。

但AppCache犯了比HTTP严重的多的错误!

我们知道,AppCache的确是单一职责,意味着浏览器必须信任他,如果不相信那它存在的意义是什么?问题在于,假设程序员犯了一个小错,一个匹配规则不小心匹配到了这个清单文件,你的代码将永远都更新不了!!

代码不小心犯个错简直太正常不过了,就好像程序员需要吃饭睡觉上厕所一样,程序员也需要会写bug。。

延伸阅读:AppCache Issue is a Douchebag

好的,冷静一下。。其实有个不完美的解决方案,通过脚本自动生成缓存规则,具体可以参考 offline-plugin AppCache 部分的做法,但这样 AppCache 的其他“好处”就完全体现无法体现出来!

这时候 Service worker 该登场了!简单来说,Service worker 是一段运行在页面之外的一段脚本,这段脚本在启动时会注册一些事件到浏览器中,当事件触发时可以通过预先定义好的 Javascript handler 控制如何响应这个事件。

但为什么说 Service worker 比 AppCache 好呢?

首先 Service worker 应该说彻底解决了 AppCache 无法更新的问题,在使用 Service worker 时,只要网络畅通,浏览器都会尝试在启动后检查 Service worker 是否有更新,而且 Service worker 并不能截获请求更新 Service worker 的事件,换句话说就是无法缓存自身,也就是永远都有机会更新自己。

其次,Service Worker 通过事件机制配合 js 脚本来控制浏览器,并且脱离于页面生存,这让web终于有了“常驻”系统的机会!

这是技术上的一小步,但是却给 web 的能力提供了无限的想象空间!

为了更好的理解什么是 Service Worker,我们可以把它想象成是生存于浏览器页面中、页面之外的动态代理,当类似网络请求之类的事件触发时,由这个代理决定如何处置这个事件。下面这个例子就是演示如何截获并处理网络请求的。


图:浏览器向服务器发起请求前先被 Service worker 截获,处理完成后再向远端服务器发起请求

这里有个小视频,演示了如何通过 Service worker “凭空捏造” 离线数据

用户评论
开源开发学习小组列表