JavaScript 引擎与跨端跨平台相关

1,561 阅读5分钟

前言

前文 JavaScript & WebAssembly 解释、编译相关

提到了不少编译相关的内容,对应的延伸,想了解下:

  1. 有哪些 JavaScript 引擎?
  2. 跨平台 都有哪些形式?是怎么做到的?

对应的,也搜集了如下一些文章:

JavaScript 引擎对比

mobile app 跨平台

hybrid

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

关于小程序的吐槽

当年,小程序刚出来的时候,负责过小程序的开发系列工作,当时有幸还被公司安排去北京参加了小程序开发者大会。

当时,觉得小程序多少推陈出新。至于,后面支付宝说要推出小程序时,甚至一脸吃惊(抄这么快?)。

然后,现在看下来,其实想吐槽下小程序这个形式,个人认为,被微信以及国内一众厂商带坏了节奏

小程序这个东西感觉就像是一个临时性的产物,但是因为入口、流量的原因,不得不去做(收得好一波年费),连带着其他厂商跟进。

实际上想想,小程序到底本来也就是 webview 渲染,再加点 native 的壳,性能会否有那么大提升?或者这样的性能提升,对于用户来说有多大意义呢?投入大量资源有没有必要?

在我看来,该用的东西,慢点等个 1-2s 不打紧;不用的东西,就算再快,打开看一眼,照旧是关闭。

没什么必要搞不同的写法,即使想提升 微信 APP 内网页得性能,也是可以通过 提供 hybrid API 的方式来实现(即使不能覆盖更高大上的功能),但是微信却是在浏览器标准之外单独搞了一套开发体系。

搞得 1,2,3,4 家厂商齐齐跟进,连带着前端又要搞 h5、又要搞小程序,又要处理不同的厂商之间的小程序兼容性,各家标准不一样,然后又有人针对不同厂商的小程序去做适配抹平。

之前也想着,国内小程序这么火,国外怎么样呢? —— 没有,啥都没有,就是自己在玩

这样的做法,就像是,chrome 说:

  1. 我搞了一个单独的规范,不搞 w3c、ecmascript 那一套了,我们用 dart、gcss、gxml,为了提升页面的性能(实际上还是转成 JS 渲染,然后加一点另外的壳)
  2. 原来的,html、css、js 也支持,但是没有 dart 快
  3. flutter 会有单独的入口哦,非常先进
  4. 用 flutter 开发的 gweb,每年要交 300块保护费

好了,大家各玩各的。safari 推出自己的,firefox 推出自己的,手机浏览器 UC 都推出自己......

原生渲染,bridge 通信

RN

weex

自己画

Flutter

desktop app 跨平台

hybrid

原生渲染,bridge 通信

自己画

flutter

多端

发散

再看:

历史是重复的,以历史维度去看

  • 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 奇技淫巧,对他说的话,还会有一些反感。

现在看来,从

这一系列文章整理下来,他说得没错。JavaScript 自身携带的缺陷,在一些场景下,确属于难解之题。

个人比较看好 Dart / flutter 未来。

至于说

  • 小程序 —— 闭门造车的体系,成不了新标准,比起独家厂商性能方面的些许提升,投入大量人力物力,对 JS 的生态来说,反倒成了一种破坏(因为要花精力去了解 / 学习这种无用东西),可以说最好趁早拜拜了您
  • hybrid 类 apicloud / dcloud —— 仍有一定场景和用途:独立开发者 / 小型公司,开发起来太简单了
  • weex —— 不看好,比起 react native 生态,差距过大
  • RN —— 在比较长的时间内,仍然是主角;但未可知 3 - 5 年以后,会否变成 grunt 的类似存在