JavaScript 引擎與跨端跨平臺相關

前言

前文 JavaScript & WebAssembly 解釋、編譯相關

提到了很多編譯相關的內容，對應的延伸，想了解下：

1. 有哪些 JavaScript 引擎？
2. 跨平臺 都有哪些形式？是怎麼作到的？

對應的，也蒐集了以下一些文章：

JavaScript 引擎對比

• J2V8 —— Android JavaScript 引擎學習之初探 V8
• Hermes —— 逆襲Futter? Facebook 發佈全新跨平臺引擎 Hermes！
• Hermes —— 乾貨 | 加載速度提高15%，攜程對RN新一代JS引擎Hermes的調研
• JS 引擎大 PK：JSC vs V8 vs Hermes

mobile app 跨平臺

hybrid

大部分 webview 渲染，再套一些 native bridge API

• Adobe PhoneGap
• Apache Cordova
• ionic （Angular + Cordova）
  • 手摸手帶你入門ionic3(一)：ionic介紹
• dcloud 5+runtime
• apicloud Deep Engine
• 小程序
  • 微信小程序目前是採用webview渲染的嗎？
  • 淺談小程序運行機制
  • 微信，支付寶小程序實現原理概述
  • 支付寶、百度、頭條、QQ...
  • 小程序跨端
    • uni-app
    • taro
    • Taro vs uni-app選型對比經歷

關於小程序的吐槽

當年，小程序剛出來的時候，負責太小程序的開發系列工做，當時有幸還被公司安排去北京參加了小程序開發者大會。

當時，以爲小程序多少推陳出新。至於，後面支付寶說要推出小程序時，甚至一臉吃驚（抄這麼快？）。

而後，如今看下來，其實想吐槽下小程序這個形式，我的認爲，被微信以及國內一衆廠商帶壞了節奏。

小程序這個東西感受就像是一個臨時性的產物，可是由於入口、流量的緣由，不得不去作（收得好一波年費），連帶着其餘廠商跟進。

實際上想一想，小程序到底原本也就是 webview 渲染，再加點 native 的殼，性能會否有那麼大提高？或者這樣的性能提高，對於用戶來講有多大意義呢？投入大量資源有沒有必要？

在我看來，該用的東西，慢點等個 1-2s 不打緊；不用的東西，就算再快，打開看一眼，照舊是關閉。

沒什麼必要搞不一樣的寫法，即便想提高 微信 APP 內網頁得性能，也是能夠經過 提供 hybrid API 的方式來實現（即便不能覆蓋更高大上的功能），可是微信倒是在瀏覽器標準以外單獨搞了一套開發體系。

搞得 1,2,3,4 家廠商齊齊跟進，連帶着前端又要搞 h五、又要搞小程序，又要處理不一樣的廠商之間的小程序兼容性，各家標準不同，而後又有人針對不一樣廠商的小程序去作適配抹平。

以前也想着，國內小程序這麼火，國外怎麼樣呢？ —— 沒有，啥都沒有，就是本身在玩

這樣的作法，就像是，chrome 說：

1. 我搞了一個單獨的規範，不搞 w3c、ecmascript 那一套了，咱們用 dart、gcss、gxml，爲了提高頁面的性能（實際上仍是轉成 JS 渲染，而後加一點另外的殼）
2. 原來的，html、css、js 也支持，可是沒有 dart 快
3. flutter 會有單獨的入口哦，很是先進
4. 用 flutter 開發的 gweb，每一年要交 300塊保護費

好了，你們各玩各的。safari 推出本身的，firefox 推出本身的，手機瀏覽器 UC 都推出本身......

原生渲染，bridge 通訊

RN

• ReactNative設計與實現之一：背景
• ReactNative設計與實現之二：實踐
• ReactNative設計與實現之三：總體架構
• ReactNative設計與實現之四：Android端源碼分析
• 庖丁解牛！深刻剖析 React Native 下一代架構重構

weex

• Weex原理之帶你去蹲坑

本身畫

Flutter

• Flutter原理與實踐

desktop app 跨平臺

hybrid

• nw.js
• Electron
• NW.js & Electron Compared

原生渲染，bridge 通訊

• react-native-windows

本身畫

flutter

• Flutter for Desktop: Create and Run a Desktop Application
• flutter-desktop-embedding

多端

• React Native 三端同構實戰

發散

再看：

• 知乎：Flutter 在 2019 年會有怎樣的表現？
• 如何評價 Flutter for Web？
• Web Dashboard in Flutter Hummingbird

歷史是重複的，以歷史維度去看

• 10年讀大學的時候，你們買手機大多數是諾基亞 5230系列，塞班論壇很是火爆。結果僅僅過了 1 - 2 年 —— 沒落
• 此外，在 11年左右，印象中，學校選修課開了 android 開發的課程
• windows phone 剛出來時，由於開發人員很是稀少，薪資很是高？ 後來，windows phone 淘汰 —— 白學

目前也將近 10年的光景

• android 碎片化問題、補丁升級的問題...
• Fuchsia 系統發佈在即
• flutter android、ios、fuchsia，甚至 windows、macOS 之後也能玩
• dart 能夠 dart2js
• 要是 flutter 搞出一個 瀏覽器SDK 支持的話 —— 昨天這麼說，今天查了一下發現已經有了 flutter_web（儘管可能還不完善）
• ...

諸如此類，若是 Fuchsia、flutter 在於 google，推行得開；大膽猜想，之後更多的體系會搭建在 dart、flutter 上。畢竟誰也不想每天搞來搞去寫重複的代碼搞同樣的事情還搞適配。

此外，在剛開始工做時，有一個同事，偶爾會提，JavaScript 語言自身其實帶着很多的缺陷，後來過了幾年他轉後端作 PHP 去了；那些年，會一些 JavaScript 奇技淫巧，對他說的話，還會有一些反感。

如今看來，從

• 抽象語法樹 AST 與 編譯器 Compiler
• babel 7 全套
• babel 7 插件開發相關
• JavaScript & WebAssembly 解釋、編譯相關

這一系列文章整理下來，他說得沒錯。JavaScript 自身攜帶的缺陷，在一些場景下，確屬於難解之題。

我的比較看好 Dart / flutter 將來。

至於說

• 小程序 —— 閉門造車的體系，成不了新標準，比起獨家廠商性能方面的些許提高，投入大量人力物力，對 JS 的生態來講，反倒成了一種破壞（由於要花精力去了解 / 學習這種無用東西），能夠說最好趁早拜拜了您
• hybrid 類 apicloud / dcloud —— 仍有必定場景和用途：獨立開發者 / 小型公司，開發起來太簡單了
• weex —— 不看好，比起 react native 生態，差距過大
• RN —— 在比較長的時間內，仍然是主角；但未可知 3 - 5 年之後，會否變成 grunt 的相似存在