浅谈web前端的发展趋势

时间  2019-11-07
标签 浅谈 web 前端 发展趋势 栏目 HTML 繁體版
原文   原文链接

前言

你一个写前端的，也敢自称程序员？？javascript

15308408976286

相信web前端开发的伙伴们，在职业道路上，十有八九会受到这样的质疑或者嘲讽（大多数其实仍是调侃之意）。写几个标签，懂一些HTML CSS 就是程序员？ 大家知道CPU、存储、网络、集群吗？ 大家了解过并发、业务架构、数据库、性能调优、分布式计算、集群架构、容灾、安全、运维吗css

哼 辣鸡👎html

今日咱们为前端带盐

近年来，Web 应用在整个软件与互联网行业承载的责任愈来愈重，软件复杂度和维护成本愈来愈高，Web 技术，尤为是 Web 客户端技术，迎来了爆发式的发展。前端

  • 1.用Node作中间层的前端工程化方案
  • 2.Webpack、Rollup 这样的打包工具；Babel、PostCSS 这样的转译工具
  • 3.前端三架马车React、Angular、Vue 这样面向现代 web 应用需求的前端框架及其生态
  • 4.与APP结合的混合开发模式，内嵌单页webview，Hybrid App

JavaScript 计算能力、CSS 布局能力、HTTP 缓存与浏览器 API带来了用户体验上质的飞跃html5

进入主题，咱们将从2个方面：java

  • 下一代Web应用：PWA
  • WebAssembly

来浅谈一下前端发展的趋势git

下一代Web应用：PWA

老生常谈，咱们先对比一下生活中WebAPP 和 原生APP的优劣程序员

web APP 对比 原生APP 的优点
开发成本低
适配多种移动设备，不用IOS 安卓多套代码
迭代更新容易,省去了审核、发包、各类渠道发布带来的时间损耗
无需安装成本，拿来即用
web APP 对比 原生APP 的劣势
浏览的体验没法超越原生应用，加载慢，白屏转圈圈
不多有支持离线模式
消息推送及其困难
本地系统功能没法调用

PWA 的一系列关键技术的出现，终于让咱们看到了完全解决这两个平台级别问题的曙光github

PWA解决的问题

  • 可以显著提升应用加载速度
  • 甚至让 web 应用能够在离线环境使用 （Service Worker）
  • web 应用可以像原生应用同样被添加到主屏、全屏执行 （Web App Manifest）
  • 进一步提升 web 应用与操做系统集成能力，让 web 应用能在未被激活时发起推送通知 （Push API 与 Notification API） 等等。

一个十分红熟的🌰（例子） 「印度阿里巴巴」 —— Flipkart

FlipKart Lite应该是最为人津津乐道的PWA案例了 当浏览器发现用户须要 Flipkart Lite 时，它就会提示用户“Hello，你能够把它添加至主屏哦”，固然也能够右上角手动添加。 这样，Flipkart Lite 就会像原生应用同样在主屏上留下一个自定义的 icon 做为入口；与通常的添加一个Web书签不一样，当用户点击这个 icon 时，Flipkat Lite 将直接全屏打开，再也不受困于浏览器的 UI 中，并且有本身的启动屏效果。web

15300655325976

并且有一个很大的突破，在没法访问网络时，Flipkart Lite 能够像原生应用同样照常执行，还会很骚气的变成黑白色；不但如此，曾经访问过的商品都会被缓存下来得以在离线时继续访问。在商品降价、促销等时刻，Flipkart Lite 会像原生应用同样发起推送通知，吸引用户回到应用。

15300656314905

接下来咱们看看PWA的2个重要技术点，Web APP Manifest 和 Service Worker

Web App Manifest

参考连接：https://developers.google.com/web/fundamentals/web-app-manifest/?hl=zh-cn

它实际上是一个网络应用清单，一个JSON文件，开发者能够利用它控制在用户想要看到应用的区域（例如移动设备主屏幕）中如何向用户显示网络应用或网站，指示用户能够启动哪些功能，以及定义其在启动时的外观。是PWA技术的必备要素

总结一下Manifest的三个步骤：

  • 建立清单并将其连接到您的页面。
  • 控制用户从主屏幕启动时看到的内容。
  • 启动画面、主题颜色以及打开的网址等。

建立清单demo

15300662214848

short_name：为应用程序提供简短易读的名称。在没有足够空间显示全名时使用。 name:为应用程序提供一我的类可读的名称。 icons：各类环境中用做应用程序图标的图像对象数组 start_url：指定用户从设备启动应用程序时加载的URL。

15300662332376

在建立清单且将清单添加到您的网站以后，将 link 标记添加到包含网络应用的全部页面上

一些可选项

添加启动画面 splash screen

15300666570624

设置启动样式

15300666779957

这里是选择全屏显示，仍是保留地址栏

debugger

15300675492998

Chrome 浏览器已经提供给咱们一些方法和手段，直接进入 Application 板块，选择 manifest 选项卡，便可，将它添加到 Chrome 应用中。

html5里的manifest是用来缓存网页上的一些资源，跟咱们PWA里的WebApp manifest 彻底不是一回事

<!DOCTYPE HTML>
<html manifest="demo.appcache">
</html>
复制代码

Service Worker

咱们原有的整个 Web 应用，都是创建在用户能上网的前提之下的，因此一离线就只能看转圈圈了。web社区也作过不少相似的尝试，如APP Cache。可是它，几乎没有路由机制，出了BUG没法监控，现下已经在html5.1中 被干掉了

这个时候，Service workers 横空出世！！

Service workers 本质上充当Web应用程序与浏览器之间的代理服务器，也能够在网络可用时做为浏览器和网络间的代理。它们旨在（除其余以外）使得可以建立有效的离线体验，拦截网络请求并基于网络是否可用以及更新的资源是否驻留在服务器上来采起适当的动做。他们还容许访问推送通知和后台同步API。

service worker将遵照如下生命周期：

  • 下载
  • 安装
  • 激活

15300681075578
15300681336107

看一下实例代码

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw-test/sw.js', { scope: '/sw-test/' }).then(function(reg) {

    if(reg.installing) {
      console.log('Service worker installing');
    } else if(reg.waiting) {
      console.log('Service worker installed');
    } else if(reg.active) {
      console.log('Service worker active');
    }

  }).catch(function(error) {
    // registration failed
    console.log('Registration failed with ' + error);
  });
}
复制代码

这段代码先作了一个特性检查，在注册以前确保 Service Worker 是支持的, 接着，咱们使用 ServiceWorkerContainer.register() 函数来注册 service worker， 这就注册了一个 service worker。

self.addEventListener('install', function(event) {
  event.waitUntil(
    caches.open('v1').then(function(cache) {
      return cache.addAll([
        '/sw-test/',
        '/sw-test/index.html',
        '/sw-test/style.css',
        '/sw-test/app.js',
        '/sw-test/image-list.js',
        '/sw-test/star-wars-logo.jpg',
        '/sw-test/gallery/bountyHunters.jpg',
        '/sw-test/gallery/myLittleVader.jpg',
        '/sw-test/gallery/snowTroopers.jpg'
      ]);
    })
  );
});
复制代码

  • 新增了一个 install 事件监听器，接着在事件上接了一个ExtendableEvent.waitUntil() 方法——这会确保Service Worker 不会在 waitUntil() 里面的代码执行完毕以前安装完成。

  • 在 waitUntil()内，咱们使用了 caches.open() 方法来建立了一个叫作 v1 的新的缓存，将会是咱们的站点资源缓存的第一个版本。

  • 它返回了一个建立缓存的 promise，当它 resolved的时候，咱们接着会调用在建立的缓存示例上的一个方法 addAll()，这个方法的参数是一个由一组相对于 origin 的 URL 组成的数组，这些 URL 就是你想缓存的资源的列表。

  • Service Worker 的 新的标志性的存储 API — cache — 一个 service worker 上的全局对象，它使咱们能够存储网络响应发来的资源，而且根据它们的请求来生成key。

15300708550158

参考连接:https://developer.mozilla.org/zh-CN/docs/Web/API/Service_Worker_API/Using_Service_Workers

推送Push Notification

Push API 的出现则让推送服务具有了向 web 应用推送消息的能力，它定义了 web 应用如何向推送服务发起订阅、如何响应推送消息，以及 web 应用、应用服务器与推送服务之间的鉴权与加密机制；因为 Push API 并不依赖 web 应用与浏览器 UI 存活，因此即便是在 web 应用与浏览器未被用户打开的时候，也能够经过后台进程接受推送消息并调用 Notification API 向用户发出通知

self.addEventListener('push', event => {
    event.waitUntil(
        // Process the event and display a notification.
        self.registration.showNotification("Hey!")
    );
});

self.addEventListener('notificationclick', event => {
    // Do something with the event
    event.notification.close();
});

self.addEventListener('notificationclose', event => {
    // Do something with the event
});

复制代码

PWA任重道远

  • 国内较重视 iOS，而 iOS 对PWA是十分不友好的。

  • 国内的 Android 实为「安卓」，不自带 Chrome ，其次，各厂商喜欢本身瞎加班（JB）订制各类系统，带来兼容性问题

  • Push Notification还处于襁褓阶段（尚未一个标准的协议），将来的变数较大

  • 国内的web应用入口多集中于各种APP，如微信，qq，带来的限制较多

WebAssembly

部分图片和概念来自 参考连接：https://hacks.mozilla.org/2017/02/a-cartoon-intro-to-webassembly/

15300714659625
15300714727109

布兰登·艾克：你说大家老板10天上线1个app，丧心病狂？大哥10天干了一门语言

正是由于JS的诞生显得没有那么"正式"，因此带来了不少的坑点和性能上的限制。它更像一个还在建造当中的楼房，咱们web开发人员不断的为它添砖加瓦，总有一天会变成摩天大楼！

什么是WebAssembly

  • WebAssembly 是由主流浏览器厂商组成的 W3C 社区团体 制定的一个新的规范。

  • 它的缩写是".wasm"，.wasm 为文件名后缀，是一种新的底层安全的二进制语法。

  • 能够接近原生的性能运行，并为诸如C / C ++等语言提供一个编译目标，以便它们能够在Web上运行。它也被设计为能够与JavaScript共存，容许二者一块儿工做。

  • 能突破前端3D game 、 VR/AR 、 机器视觉、图像处理等运行速度瓶颈

咱们来看一个demo:http://webassembly.org.cn/demo/Tanks/

WebAssembly 工做原理

了解WebAssembly以前，咱们先大概的了解一下代码的运行机制

在代码的世界中，一般有两种方式来翻译机器语言：解释器和编译器。

若是是经过解释器，翻译是一行行地边解释边执行

15300785911993

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

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

编译器是把源代码整个编译成目标代码，执行时再也不须要编译器，直接在支持目标代码的平台上运行。

15300786239924

它须要花一些时间对整个源代码进行编译，而后生成目标文件才能在机器上执行。对于有循环的代码执行的很快，由于它不须要重复的去翻译每一次循环。

最开始的浏览器是只有解释器的，由于解释器看起来更加适合 JavaScript。对于一个 Web 开发人员来说，可以快速执行代码并看到结果是很是重要的。后来将编译器也加入进来，造成混合模式。

再添加一个监视器，用来监控着代码的运行状况，记录代码一共运行了多少次、如何运行的等信息。

加这么多东西的好处是什么呢

起初，监视器监视着全部经过解释器的代码。

15300791434221

若是同一行代码运行了几回，这个代码段就被标记成了 “warm”，若是运行了不少次，则被标记成 “hot”。

若是一段代码变成了 “warm”，那么 浏览器 就把它送到编译器去编译，而且把编译结果存储起来。--（基线编译器）

代码段的每一行都会被编译成一个“桩”（stub），同时给这个桩分配一个以“行号 + 变量类型”的索引。若是监视器监视到了执行一样的代码和一样的变量类型，那么就直接把这个已编译的版本 push 出来给浏览器。

15300797943329

若是一个代码段变得 “very hot”，监视器会把它发送到优化编译器中。生成一个更快速和高效的代码版本出来，而且存储之。--（优化编译器）

优化编译器会作一些假设。若是某个循环中先前每次迭代的对象都有相同的形状，那么优化编译器就能够认为它之后迭代的对象的形状都是相同的。但是对于 JavaScript 历来就没有保证这么一说，前 99 个对象保持着形状，可能第 100 个就少了某个属性，这个时候，执行过程将会回到解释器或者基线编译器,叫作去优化

15300797943329 

function arraySum(arr) {
  var sum = 0;
  for (var i = 0; i < arr.length; i++) {
    sum += arr[i];
  }
}
复制代码

若是arr 是一个有 100 个整数的数组，类型肯定，就很容易的派发到优化编译器中 可是JavaScript 中类型都是动态类型，sum 和 arr[i] 两个数并不保证都是整数，arr[i] 颇有可能变成了string 类型，就会去优化，从新分配到解释器或者基线编译器

那是如何编译解释呢？

咱们进行机器码的翻译并非只有一种，不一样的机器有不一样的机器码，就像咱们人类也说各类各样的语言同样，机器也“说”不一样的语言。

你想要从任意一个高级语言翻译到众多汇编语言中的一种（依赖机器内部结构），其中一种方式是建立不一样的翻译器来完成各类高级语言到汇编的映射。

15300804906133

这种翻译的效率实在过低了。为了解决这个问题，大多数编译器都会在中间多加一层。它会把高级语言翻译到一个低层，而这个低层又没有低到机器码这个层级。这就是中间代码（ intermediate representation，IR）。

15300807406283

编译器的前端把高级语言翻译到 IR，编译器的后端把 IR 翻译成目标机器的汇编代码。

重点来了

15300808312348

WebAssembly 在什么位置呢？实际上，你能够把它当作另外一种“目标汇编语言”。

每一种目标汇编语言（x8六、ARM）都依赖于特定的机器结构。当你想要把你的代码放到用户的机器上执行的时候，你并不知道目标机器结构是什么样的。

而 WebAssembly 与其余的汇编语言不同，它不依赖于具体的物理机器。能够抽象地理解成它是概念机器的机器语言，而不是实际的物理机器的机器语言。

正由于如此，WebAssembly 指令有时也被称为虚拟指令。它比 JavaScript 代码更直接地映射到机器码，它也表明了“如何能在通用的硬件上更有效地执行代码”的一种理念。因此它并不直接映射成特定硬件的机器码。

那为何不直接用JS，这么麻烦用WebAssembly

15300826048069

这是JS的性能使用分布状况

  • Parsing——表示把源代码变成解释器能够运行的代码所花的时间；

  • Compiling + optimizing——表示基线编译器和优化编译器花的时间。一些优化编译器的工做并不在主线程运行，不包含在这里。

  • Re-optimizing——包括重优化的时间、抛弃并返回到基线编译器的时间。

  • Execution——执行代码的时间

  • Garbage collection——垃圾回收，清理内存的时间

15300828887458

这是WebAssmbly与JS的对比

wasm的优点是自己就是经过编译器并优化事后的二进制文件，能够直接转换为机器码，省去了Javascript须要解析，优化的工做，因此在加载和执行上自己就具备优点

具体优点点

  • 文件获取

WebAssembly 比 JavaScript 的压缩率更高，因此文件获取也更快。即使经过压缩算法能够显著地减少 JavaScript 的包大小，可是压缩后的 WebAssembly 的二进制代码依然更小。

这就是说在服务器和客户端之间传输文件更快，尤为在网络很差的状况下。

  • 解析

JavaScript 源代码到达浏览器时被解析成了AST （抽象语法树）。 解析事后 AST （抽象语法树）就变成了中间代码（叫作字节码），提供给 JS 引擎编译。

而 WebAssembly 则不须要这种转换，由于它自己就是中间代码。它要作的只是解码而且检查确认代码没有错误就能够了。

  • 优化

浏览器的JIT会反复地进行“抛弃优化代码<->重优化”过程， 好比当循环中发现本次循环所使用的变量类型和上次循环的类型不同，或者原型链中插入了新的函数，都会使 JIT 抛弃已优化的代码，进行重优化。

在 WebAssembly 中，类型都是肯定了的，因此 JIT 不须要根据变量的类型作优化假设。也就是说 WebAssembly 没有重优化阶段。

  • 垃圾回收

在JS中的内存概念是很是模糊的，由于JS并不须要申请内存，全部内存都有JS自动分配，由于它不可控，因此清理垃圾的时候会带来性能开销

WebAssembly不须要垃圾回收，内存操做都是手动控制的（像 C、C++同样）。这对于开发者来说确实增长了些开发成本，不过这也使代码的执行效率更高。

如何实现一个WebAssembly demo

参考连接：http://webassembly.org.cn/getting-started/developers-guide/

15300836901005 

int square (int x) {
  return x * x;
}
复制代码
emcc math.c -s WASM=1 -o index.html
复制代码

15300837997256

从0开始完成刚刚坦克大战的例子

15300845024215

15300845134273

4.大功告成

谢谢你们~

广而告之

本文发布于薄荷前端周刊，欢迎Watch & Star ★，转载请注明出处。

欢迎讨论，点个赞再走吧 ｡◕‿◕｡ ～

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程