捍卫Electron作为跨平台GUI平台

多年来,我来到Electron时曾使用多个跨平台GUI平台。 20年前,我使用Xvt开发了一个电子邮件用户代理,Xvt是1990年代初期的C / C ++ GUI工具包,然后我在Mainsoft的MainWin工具包上工作,该工具包可以在Unix / X11上重新编译Windows WIN32 / MFC应用程序,之后,我在Sun Microsystems的Java SE团队工作了10年以上。 最近几年,我一直在探索Node.js平台,并写了几本有关使用Node.js编写软件的书。 最近,我学会了使用Electron来实现应用程序,并发现它是我使用过的最有趣的GUI平台。

看到Electron被冠以Write-Once-Run-Anywhere概念的“笨拙的怪兽”实现,真是令人失望。 我曾见过对Electron的类似投诉,而在查看可用数据时,这种表征并不成立。

文章中的声明有很多问题,例如:

  • 基于Java的应用程序的占用空间与作者描述的不同
  • 在我的环境中,基于电子的应用程序不会很麻烦
  • 基于电子的应用程序具有与本机代码应用程序相似的内存占用量
  • 运行时与应用程序的捆绑简化了应用程序的交付

链接文章的主要主张是,Electron中的内存占用量巨大,而其他平台则不那么多。 给出的论点是完全错误的。

部署的Electron应用程序将Electron运行时,应用程序中使用的HTML和JavaScript文件以及包含所有相关库的必需的node_modules目录捆绑在一起。 确实,每个部署的Electron应用程序都会复制运行时,并且可能会复制从属库。 这真的有问题吗? 我的笔记本电脑有1.25 TB的磁盘空间,我几乎不认为重复的JavaScript源有几兆字节是个大问题。

Java应用程序也存在类似情况。 尽管Java运行时是共享资源,但每个已安装的Java应用程序都需要安装一堆JAR,其中包括该应用程序和其他资产。 同样,磁盘空间消耗是否有问题?

由于同时运行多个内存消耗型应用程序可能是个大问题,因此内存占用空间更大。

在我的笔记本电脑上(具有16GB内存的2012 MacBook Pro Core i7),我目前正在运行Chrome(打开许多选项卡),Postman,Gitkraken,Slack,Visual Studio Code,以及一些诸如Terminal.app和Preview之类的本机代码应用程序.app。 通过活动监视器,我看到了以下内存占用量度:

  • GitKraken — 213MB
  • Terminal.app — 187MB
  • Preview.app — 143MB
  • Visual Studio代码— 123MB(打开了几个窗口,每个窗口中打开了几个文件)
  • 邮递员— 110MB
  • 松弛-64MB

尽管我不确定如何说明出现的许多“ GitKraken帮助程序”和“代码帮助程序”等过程,但这些似乎彼此一致。

最重要的措施是我的笔记本电脑仍然具有4GB的可用内存。 打开Chrome浏览器标签过多的几天让我的笔记本电脑非常痛苦,但是当我关闭多余的标签时,这种情况就变得很紧张。

有一点关于共享库和内存占用量。 所有现代操作系统都允许在应用程序之间共享库,从而有效地减少了内存占用。

Electron错失了这个机会,因为每个应用程序附带了Electron框架的完整副本。

解决该问题的方法是将Electron平台与Electron应用程序分开运送/安装。 这带来了一个问题……

要使共享库减少应用程序占用空间,就必须以某种方式将要共享的库与应用程序分开安装。

这就是为什么在安装Eclipse或Freemind或任何其他基于Java的应用程序时,必须首先安装Java实例的原因。

前几天,我的女友想学习思维导图,我们选择了Freemind,这是一个免费的开源思维导图应用程序。 但是,她仔细阅读了说明,并陷入了安装Java的第一步,而我必须为她做这一步。

通常,任何首先需要安装其他东西的应用程序(例如运行时平台)都会变成接受障碍。

将运行时与应用程序捆绑在一起可消除该障碍。 它还可以确保应用程序针对测试平台的版本运行。

我不会断言Electron没有缺陷。 人类创造的一切事物都有缺陷。

在Motif,Xvt,WIN32 / MFC,Java / Swing,HTML5 + JavaScript和现在的Electron中编写了GUI应用程序之后,我将在一周中的任何一天使用Electron。

首先,Node.js是一个快乐的开发平台。 然后,就像在Electron中一样,使用HTML + JavaScript编写应用程序很高兴。 最后,Electron使得将所有内容放在一起相对容易。

在跨平台GUI开发中已经进行了数十次讨论,Electron提供了一种非常好的方法。 例如,应用程序在整个平台上的行为完全相同。 但是,Electron应用程序的包装令人困惑,这是Electron团队可以在此领域进行巨大改进的地方。

在Electron中开发有意义的内容存在一些限制-但这些限制是由于浏览器内JavaScript的限制所致。 例如,不建议在Electron中实现像Final Cut Pro这样的高端视频编辑应用程序。 但是对于一般的常规产品来说,这很好。 任何人都可以证明自己的权利-只需安装台式机Slack客户端,或使用用Electron编写的任何其他高级应用程序。

要求:

由于所有Java应用程序都依赖于同一个单一的JVM,并且由于Java在版本之间可能会有巨大的变化,因此碎片化成为Java应用程序和用户的主要问题

如果给定的应用程序需要给定的平台版本,则可以并排安装多个JRE / JDK实例。

Java团队实行极端的向后兼容性,以允许过去的任何应用程序都可以在当前JVM上运行。 唯一的不足是,使用Java 8功能编写的应用程序不能(当然)不能在Java 6或Java 1.1上运行。

要求:

由于JVM拖延了主要问题,因此Java在台式机上已几乎完全被废弃

由于Java插件中存在大量重大的无法修复的安全问题,因此浏览器内的Java被放弃了。 每个人都被命令停止使用浏览器内的Java,而不是发出警告。 桌面Java仍然存在,并在Netbeans和其他许多应用程序中使用。 但是,它从未像以前那样流行。

而且,是的,正如上面链接的文章所述,对于没有Java问题的新型WORA系统,还有空间。

移动领域爆发的不是Java,而是Android。 您使用Java语言和某些Java运行时程序包编写Android应用程序的事实并不会使Android成为Java实现。

在测试套件上有测试套件,用于验证给定的事物是否可以称为Java。 Android无法通过这些测试套件,因此不能称为Java。