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 的相似存在