这是一个创建于 1446 天前的主题，其中的信息可能已经有所发展或是发生改变。
害……作为用户，我对 Electron 简直深恶痛绝，一言难尽……
今天百度某个软件的汉化方法时，无意间发现发现了一个叫做 app.asar 的东西，搜索了一下，原来是 Electron 构建的软件基本都有这个东西，那么如果我禁止一切文件扩展名为 .asar 的文件运行是不是就可以干死用 Electron 写的软件了呢？
亲测有效，如果还有其他方法，欢迎补充！
第 1 条附言 · 2020-12-07 14:44:53 +08:00
卧槽，一天没看帖子，怎么炸锅了？
-----------------------------------
楼主只是随便找了个软件举例而已，大家不用针对例子去讨论。也不用去讨论为何楼主偏偏下载了一个基于 Electron 构建的软件，我只是拿来验证是否能禁止运行而已，软件本体已经删除了，不用针对我言辞激烈，害怕……
当然可能会有认为楼主电脑辣鸡，应该还不算太辣鸡吧？瑟瑟发抖~
-----------------------------------
处理器 Intel(R) Xeon(R) CPU E3-1231 v3 @ 3.40GHz 3.40 GHz
内存 16.0 GB
显卡 GTX 970 4GB
硬盘 512GB SSD
系统类型 Windows 10 20H2 企业版
-----------------------------------
楼主只是随便找了个软件举例而已，大家不用针对例子去讨论。也不用去讨论为何楼主偏偏下载了一个基于 Electron 构建的软件，我只是拿来验证是否能禁止运行而已，软件本体已经删除了，不用针对我言辞激烈，害怕……
当然可能会有认为楼主电脑辣鸡，应该还不算太辣鸡吧？瑟瑟发抖~
-----------------------------------
处理器 Intel(R) Xeon(R) CPU E3-1231 v3 @ 3.40GHz 3.40 GHz
内存 16.0 GB
显卡 GTX 970 4GB
硬盘 512GB SSD
系统类型 Windows 10 20H2 企业版
 |
101
CodeCodeStudy 2020-12-07 17:00:27 +08:00
Postman 这种组装 HTTP 请求的软件，内存占用超过 1 个 G，16G 内存都嫌不够啊
|
 |
102
namelosw 2020-12-07 17:11:53 +08:00
@charlie21 结果不是很明显嘛? 我理解每个人都能立刻想出来吧.
> 这叫引狼入室 本来一个人做完的事情, 非得 30 个人做, 抵抗是没用的. 你用打孔器编程, 别人用电脑编程, 你不管怎么挣扎, 都不可能让这个社会停在打孔器阶段. 精英厨师打击味精类似学阀, 可以叫厨阀, 换到程序员上可能可以叫码阀. 要被替换的码阀: 1. 本早就应该打算好, 很多年前趋势就已经很明显了. 只会 Cobol 还指望着永远能有工作? 只会 OC 还指望打击 Swift 是玩具过日子? 好的程序员应该熟悉不变的部分, 至于工具平台什么上手都快. 2. 多挣扎几年只能越来越痛苦, 真正的精英 native 开发永远都不愁工作, 因为优化到极致之后就是拼技术栈了. 要愁的是 average client dev - 扪心自问自己客户端做得还没有别人 Electron 做得好使的那些人. 3. Native 和 Electron 都不是很好的方案, Electron 只是一个过程, trade off 很明显, 问题很多, 所以码阀还能重点打击一下. 以后会有类似 LLVM 或者 LSP 模式的方案把它们都干掉的 - 又通用又快体验又好, 到时候就不用撕逼了 - 以前 AMD Intel 差不多的时候天天撕逼, i3 默秒全之后就没人撕了. |
|
103
namelosw 2020-12-07 17:26:55 +08:00
@MengiNo 好一个只有程序员才鄙视 Electron，我可以理解成：喂门外汉、小白们吃屎的行为被有技术的人揭发了，开始解决发现问题的人吗。是不是程序员丝毫不影响我是一个用户。
1. 不是所有的 Electron app 都辣鸡. 2. 不是所有的 Native app 都不辣鸡. 3. 因为 Electron 就一杆子打死跟 40 年代坑杀没区别. 4. Electron app 辣鸡最重要的原因是不愿意花钱, 用同样的钱做 n 份 Native 你只能得到更辣鸡的产品, 往往一半功能都是坏的. 5. 体验如何是人直接能感知出来的, 不能感知的区别不重要. App 不好用, 喂小白吃屎, 小白是能感觉出来的. 现在是程序员一听 Electron 就开始四处找毛病. 6. 当时味精有害的研究出来之后, 人们都给那个研究组写信, 说自己出现了这些不应该出现的症状. 很多人一知道某个 app 是 Electron 的就开始挑毛病, 程序员不做双盲实验是说不清的. |
 |
104
3dwelcome 2020-12-07 17:52:38 +08:00
楼上提到 LLVM 也是未来的一个亮点。
就如当年大神用 LLVM，让 Linux 运行在浏览器上一样。以后当 Electron 发展到足够强大，能打通语言障碍，能一键发布移动端，能用 LLVM/WebAssembly 桥接任何原生软件内核的时候，也许又会刮目相看。 |
 |
105
charlie21 2020-12-07 18:20:05 +08:00
@namelosw 其实你说的这个我是很同意的。我也希望能出现一个 高级编程办法，可以把 native GUI 软件 秒杀得像 “用打孔器编程”，但很可惜 electron 难堪重任。electron 这个玩意不用说 10 年，5 年之后是否仍然存在？我是怀疑的。
指望一个 5 年之后是否存在的 SDK 能做什么，你可以指望它，我对它不抱希望。Delphi 写的桌面软件今天还可以跑，因为它实现商业化了 它有很好的支持，仅仅从这一点看，electron 连 Delphi 都不如。。。。。。。。我倒希望我可以感受到你描述的挣扎，但你这种拙劣类比可能只体现了你自己词穷的挣扎吧，反正 electron 淡出历史舞台之后呢你肯定还会有另一套说辞 而 native dev 的 比如 WPF 10 年前写的软件今天还能拿来就跑 —— 显然 electron 无法带来挣扎，也无法让这个社会停留在 electron 阶段 |
 |
106
SuperMild 2020-12-07 18:34:02 +08:00
@charlie21 Delphi 和 WPF 都是不跨平台的，拿任何不跨平台的技术栈与 Electron 比都不公平。
|
 |
107
sujin190 2020-12-07 20:26:01 +08:00
@charlie21 #105 工程是性能和开发难度妥协的最优结果，虽然你觉得 electron 傻叉，但是很不幸，估计 Delphi 后面估计是要被 electron 干死了，别说 pc 了，后面手机端的 native 估计都走向淘汰了，个人感情偏好终究干不过市场啊
|
 |
108
LokiSharp 2020-12-07 20:56:07 +08:00
@SuperMild #106 Electron 是跨平台的但是 Electron 开发的东西不见得是跨平台的，这玩意只是个 GUI 实现，任何语言 GUI 跨平台其实都不是问题。已经有人用 .net Core 写了跨平台的的 NS 模拟器了 https://github.com/Ryujinx/Ryujinx 这种应用这个世代的硬件 Electron 是不可能整的。别在前端的小圈子里故步自封了，说句不好听 Electron 已经是上个世代的跨平台开发技术了，对公司来说除了 JS 入门门口低有大量廉价低端开发者之外没有什么优势。
当然不排除微软谷歌联合起来对 Electron 做像亲儿子一样的优化的可能。 |
|
109
SuperMild 2020-12-07 21:06:27 +08:00
@LokiSharp electron 一堆大公司在用，其他跨平台技术有是有，而且有一大堆，但为啥很少人用？在跨桌面平台这一块，如果说 electron 是小圈子，那我真的不懂了，大圈子在哪里？
|
|
110
LokiSharp 2020-12-07 21:45:36 +08:00
@SuperMild #109 对大公司来说，Electron 就是比 Native 省钱罢了。桌面软件商用能卖钱的真的没几个用 Electron 的，大多公司 Electron 都是哪些无关紧要的组件，让前端兼职做就行的那种，搞砸了也不出什么乱子的东西。关乎生死的拳头级产品要是敢用 Electron 要么是没钱了要么就是被办公室政治搞残了。
|
|
111
SuperMild 2020-12-07 21:53:36 +08:00
@LokiSharp 我同意你说的，最重要、最关键的部分用 Native. 但是 eletron 主要也不是与 native 争啊，没有完美的技术，electron 也不是适用于一切场景，现在就是一块市场，需要桌面跨平台，也许做的不是最重要的产品，在这一个领域 electron 就是老大。
|
|
112
LokiSharp 2020-12-07 22:07:20 +08:00  3
@SuperMild #111 我看不惯的是那种给本身几十 k 的 unix 小工具用 Electron 套个 GUI 的比如 balenaEtcher 这类，还有某些常驻后台的进程比如 Clash for WIndows 这类。要真有 VSCode 、Slack 、Termius 、Hyper 这类强前台需求的优化得好，吃个 100-200M 资源也无所谓。我最看不惯的是一堆只会 JS 的前端不管三七二十一什么都用 Electron，问就是跨平台，然而结果写出来的一看除了几个打包的套壳 HTML 静态页之外，稍微接触点底层东西的都只能在 Windows 下面跑。
|
|
113
namelosw 2020-12-08 00:33:44 +08:00
@charlie21 拿来跑和有活力可以大规模二次开发不是一回事, Cobol 和 Solaris 也都可以拿来跑.
> electron 这个玩意不用说 10 年，5 年之后是否仍然存在？我是怀疑的。 5 年之后不存在你也太小看浏览器了吧…… 另外我既不挣扎, 也不关心 Electron 的死活, 我根本不做 desktop / mobile. 我只是一个旁观者, 只是很多 Electron 警察给我的感觉就是跟我拙劣的比喻一样…… |
 |
114
spcharc 2020-12-08 06:10:02 +08:00
支持，一直觉得 electron 很烦
说个类似的，比如 gnome3 那会儿出来我就把 gnome 卸了，原因就是太卡太耗资源。用什么 CSS 和 javascript，还嫌吃资源不多 gnome2 明明还行，也不知道那群人都在折腾啥…一上了 gnome3 都快卡住不动了 于是换上 lxde+openbox，世界顿时美好多了。一直用到现在，lxqt 都不想上 说起来 gnome 系列的很多东西都挺臃肿，比如 gedit，这么个文本编辑器，打开竟然要 3 、5 秒钟。geany 是个 IDE，开启时间都跟 gedit 差不多了。也不知道 gedit 背后都在做什么。强烈怀疑 gedit 使用了 python 之类的臃肿玩意！ |
 |
115
daysv 2020-12-08 15:37:13 +08:00
以前用 node webkit 写的聊天软件软件除了通信录跑批， 在 windows 一般占用内存不到 50mb，怎么现在 electron 这么疯狂了？
|
Select Language