淺談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教程