node 在前端当中的重要性，是否每个前端都应该学习

[zzwyh]

如题，请教各位大佬，是否前端都应该熟练使用 node 呢，这样是不是应该就包括后端一系列的基础知识

[shanyuhai123]

不要说应不应该学，当你持续深入的时候这些你自然就遇到了。

1. 为了解放复制粘贴，自然就用到 node 读取写入文件
2. 为了写个简单接口，自然就了解到 koa 、nestjs 等
3. 为了部署服务，你自然就了解到服务器知识
4. 服务器被人挂马了，你自然就知道网络安全的重要性

[murmur]

除非你们用 node 跑后端，需要学调优这些，否则就复制粘贴 google ，用啥学啥

google 需求+npm ，库都封装好了

[66beta]

当然是选择 PHP 啦

[3dwelcome]

我也不知道为什么那么多人喜欢用 JS 。

同样学 wasm ，也可以做到前后端逻辑通吃，使用语言又完全随心所欲。

JS 开发调试工具没那么完善，写起来就好比把双手双脚束缚起来，完全没办法发挥全部潜力，跳不到最高点的。

[murmur]

@3dwelcome js 调试工具可太完善了，不就是 chrome dev tools 么，wasm 为啥要学，不都是其他语言编译过来的么

现在也就是吃 wasm 没调试工具，好混淆，红利一过大家又会想起 js 的好

[mxT52CRuqR6o5]

不说要有多熟练，node 一窍不通总是说不过去吧，毕竟大部分都是 js 本身的东西

[3dwelcome]

"js 调试工具可太完善了，不就是 chrome dev tools 么"

JS 调试和早年比是体验好不少，但和别的语言比，还是有不少差距的。

去年 google 给 chrome 特别支持了 wasm 调试，就是源语言变量也能完美显示的那种。

而且 wasm 是偏二进制内存处理，这点恰恰是 js 的弱项。js 的强项是处理文本逻辑。

[mxT52CRuqR6o5]

@3dwelcome 要求兼容 IE🐶

[mxT52CRuqR6o5]

@3dwelcome 正经的讨论一下，wasm 现在生态肯定比不过 js 啊，js 有那么多现在的样式库，wasm 的有多少

[3dwelcome]

@mxT52CRuqR6o5

wasm 支持高版本 IE ，他只是一个堆栈虚拟机，运行时可以编译成 JS 的。

[3dwelcome]

@mxT52CRuqR6o5

"wasm 现在生态肯定比不过 js 啊，js 有那么多现在的样式库，wasm 的有多少"

正常来说，用 WASM 和用 JS 的，是两种项目两类人，相互之间没太多交集的。

只有极少数我这种用 WASM 写前端逻辑的，习惯后，我个人觉得比写 JS 舒服。

[shyling]

还有裸写 wasm 的？

[rsyjjsn]

一个稍微技术好点的部门，都有基建的需求，搞基建难道你就用浏览器就能解决？脚手架，打包工具，规范组件库那个不需要 node?

[murmur]

@3dwelcome 能贴点代码出来看看么，不要翻译过的代码，贴点裸写的出来

[devwolf]

是哪个定义下的“学习 node”？

我个人的理解是，
搭项目、研究 webpack 这块也视作学习 node ，而不是仅限于 express 这样的

[3dwelcome]

@murmur

https://www.bilibili.com/video/BV1244y1e7W2

我写的代码，基本上和这个视频介绍的非常接近，八九不离十。

[3dwelcome]

我说一下自己 wasm 模式下的前端吧，还是和上面视频有点区别，没用到 websocket 。

简单来说，就是把 UI 状态和 DOM 节点还有点击之类的事件，打包后发送给 wasm 内部处理。

wasm 内部用其他语言接管逻辑，对 UI 状态解压，对事件响应。同时用模板生成的页面 DOM ，再发送给浏览器生成动态 UI 。

由于 wasm 是浏览器端的，完全不需要服务器辅助，帮我替换了几乎 90%以上的前端逻辑 JS 代码。

[shyling]

@3dwelcome 重新实现 blazor ？

[3dwelcome]

@shyling

不啊，blazor 是基于 C#的，我不太喜欢 C#。

wasm 又不限制特定语言，随心所欲都可以。

以前用 php 写后端模板，后来用 js 写前端模板。写多了，真的是烦透了用 js 拼接字符串，不想再玩了。

[shyling]

@3dwelcome 我还以为这么写代码的。。。
block $label0
local.get $var0
i32.const 12
i32.add
local.get $var0
i32.const 8
i32.add
call $wasi_snapshot_preview1.environ_sizes_get
br_if $label0
i32.const 628036
local.get $var0
i32.load offset=12
i32.const 2
i32.shl
i32.const 4
i32.add
call $malloc
local.tee $var1
i32.store
local.get $var1
i32.eqz
br_if $label0
local.get $var0
i32.load offset=8
call $malloc
local.tee $var1
if
i32.const 628036
i32.load
local.get $var0
i32.load offset=12
i32.const 2
i32.shl
i32.add
i32.const 0
i32.store
i32.const 628036
i32.load
local.get $var1
call $wasi_snapshot_preview1.environ_get
i32.eqz
br_if $label0
end
i32.const 628036
i32.const 0
i32.store
end $label0

搞了半天还不是写别的语言。。

[shyling]

@3dwelcome 和用个 scala, kotlin 生成个 js 也没啥区别吧

[3dwelcome]

@shyling “和用个 scala, kotlin 生成个 js 也没啥区别吧”

是没区别，就是单纯的不喜欢 JS 语法，操作的是对象，不是内存，玩不出花样。

写习惯了别的语言后，换 JS 总有一种说不出来的束缚感。

只不过浏览器和 APP 的存在，导致大家又离不开 JS ，所以 vue 和 react 才那么受欢迎。如果当初没发明 JS ，也许现在互联网会更好。

[shyling]

@3dwelcome 也许吧 w0w

[DOLLOR]

@3dwelcome
毕竟 js 的生态繁荣，别看网上嘲讽 js 段子多，那恰好是 js 流行的反映。
wasm 的一等公民 C/C++/rust （其他语言都只能算气氛组），个个都是高门槛，不用指望 js 都不愿用的人去学它们。

[3dwelcome]

@DOLLOR

js 繁荣，是因为互联网平台提供的工作机会，养活了一大批人。

这些人是 JS 选择了他们，不是他们选择了 JS 。

[Cielsky]

@3dwelcome 高版本 IE 不需要支持，最需要支持的还是低版本啊

[sickoo]

取决你的方向，好比你只做页面样式，或者简单逻辑，可能用不上多深的 node ，但是专注前端开发绕不开 node ，至于 JS ，九几年就诞生直到现在，没啥说的

[icySoda]

@3dwelcome 大佬能发个 demo repo 看看吗，感觉你这样搞渲染性能会很差啊，每次都从从 wasn 生成模板来渲染

[3dwelcome]

@icySoda

仔细看 B 站视频，每次渲染都是局部 DOM 替换，速度很快的。用前端的属于，这叫细粒度更新。

前端真正的性能挑战，在于处理 DOM 海量数据的数据上。

这点传统 VUE 的框架有致命缺点，就是 DOM 节点数量有上限。WASM 则刚好弥补全这点，参见 figma 的设计，全都是 WASM 里面的内存对象去模拟 DOM 。

[secondwtq]

@3dwelcome 我感觉到了“海量 DOM”这个程度上，浏览器已经卡得不能自理了 ...
这种情况不是应该虚拟列表啥的先把 DOM 降下去么 ...

[3dwelcome]

@secondwtq
表格的虚模式也不是万能的，第一只能呈现相对简单的结构，第二会让前端代码逻辑变复杂，不好维护。
在 wasm 里，不渲染的 DOM 对象，仅仅只是占个内存，不会让浏览器实际运行变卡。
现在大家缺的不是内存，是性能。JS 为了绕过海量 DOM 缺陷，给代码打上无数个补丁，绕来绕去，这也是我不喜欢 JS 的地方。

[secondwtq]

@3dwelcome 我就是不明白你这个“DOM”指的是啥 ...
前端说 DOM 指的就是浏览器 native 的 DOM 对象。还有一个为了减少 native DOM 对象操作搞的虚拟 DOM 。不过这俩是分得很清楚的，说 DOM 就是 DOM ，说虚拟 DOM 就是虚拟 DOM 。WASM 里面也可以做虚拟 DOM ，但是要做“DOM”必须过 JS 。

[rioshikelong121]

Rust + Node + deno 。三手抓，三手都要硬。

[jguo]

node 只是 javascript 在浏览器外的运行环境，跟后端是两码事。只要涉及前端工程化必然要用到 node

[yaphets666]

@3dwelcome 因为你不是专业前端，你做的前端项目也不是真正的工程。WASM 的出现是为了增强前端对某些特定功能的实现能力，比如在线音视频剪辑。不是让你拿来写逻辑的。java 一样也可以写前端逻辑。

[IvanLi127]

不搞基建，不学没事，知道怎么运行 node 程序就够了。

[3dwelcome]

@secondwtq

"WASM 里面也可以做虚拟 DOM ，但是要做 DOM 必须过 JS 。"

不用必须经过 JS ，WASM 可以直接在 canvas 上自绘制，有 gpu 加持后，性能很高的。

[3dwelcome]

@yaphets666

仔细看 B 站视频，视频里的 WASM ，就是用来写逻辑的。你不用，不代表别人也不用啊。

所谓“真正的工程”，JS 也是这几年，才刚从 TS 体系建立起来。而 WASM 背后别的语言，很多都有几十年大工程的经验积累，随便哪个体量，都是秒杀普通前端项目的。

[grewer]

学 都可以学

[yaphets666]

@3dwelcome 。。。你还是不懂兄弟，你们这些业余前端的两个特征，喜欢吹 TS 和 WASM

[oubenruing]

@3dwelcome 个人看来，目前 wasm 是用来处理一些 cpu 密集计算使用的，例如处理一些图像计算。
如果是：
1."不用必须经过 JS ，WASM 可以直接在 canvas 上自绘制，有 gpu 加持后，性能很高的"
利用 canvas 来做一些网页级别的工作。
那面临的代码将会从
"使用 html js css 写个页面"
变成
"使用任意可编译成 wasm 的语言 （ X 语言），写一个 dom 解析器，css 解析器，以及用 X 语言 来控制 canvas 中的绘制(逻辑控制)"。这样听起来是否就会变成：用 X 语言写了一个浏览器，然后编译到 wasm ，并且嵌入到浏览器中？

如果是：
2.""

[oubenruing]

@oubenruing
手滑继续：
如果是：
2."用 wasm 做一个类似 react 的框架"，那听起来似乎性能更高，但是 wasm 数据传给 js 来最终控制 DOM ，将会有额外的 IO 开销。实际性能如何，还要实验才知道。

如果是：
3.用 wasm 控制 cavnas 绘制一些简单的 ui ，和复杂的图形图像场景或进行 CPU 密集型计算，我觉得是正解。

[Leviathann]

es6 还行啊
解构就是半个 pattern matching

[linshuizhaoying]

抛开团队开发协作性框架谈 js wasm 性能并没什么用 js 再垃圾 起码三大框架给入门到深入都有适配 前端更多还是协作性开发 只折腾小项目当我没说

[3dwelcome]

@yaphets666

软件工程最重要的是代码复用，JS 代码复用性和跨平台移植性，远远没有虚拟机 WASM 来的好。

可能没看到实际代码，想法相互理解不了，也正常。反正我自己写的很爽。

前端那么卷，职业规划被 JS 限制死不是什么好事，不利于和后浪竞争。

大家天天用 Babel 支持 ES 新特性，我不过把别的语言编译到 WASM ，再从 WASM 编译回 JS 来运行，这并不奇葩的，最多小众了一点。

[oubenruing]

@3dwelcome 请问能否有个小 demo 供学习，我也有做过一个 c++ 编译的 wasm 小工程 处理图形计算的。希望可以交流下。

[3dwelcome]

@oubenruing

https://github.com/dbohdan/liveviews

[retrocode]

倒不必须是 node,前端由于生理限制只能是 js,对 node 的熟悉随用随查,慢慢就好.

后端别限制太死,java/php/python/node 随便掌握一个即可,把自己当全栈发展.

比如我工作用 vue/react 写前端,java 写后端,然后自己写的简易 api 会用 php.

别把语言限制太死,工作中你要让我接手 N 年 java 项目我勉强可以接手,但是要让我接手 N 手的 PHP 项目我可能会边做边骂娘考虑跑路

然后我自己写 api 还是习惯 php...写完直接丢 nginx 里就好,免编译,支持在线修改爽啊

[uni]

@oubenruing wasm 做的类似 react 的框架就是 yew 吧，实际性能并不见提升很大

[oubenruing]

@3dwelcome 看了下这个列表的项目，似乎都是“交互式远程渲染”的项目... 跟 wasm 沾边的只有 Blazor ，找了几个 Blazor 的 demo 项目看了下，加载.net 的运行时，运行 c#，最后还是通过 js 来控制 dom....

https://demos.telerik.com/blazor-financial-portfolio/real-time
https://demos.telerik.com/blazor-coffee/
https://blazor-demo.github.io/

[secondwtq]

@3dwelcome #37
CanvasRenderingContext2D 或者 WebGLRenderingContext 也算是 native DOM 对象啊，操作这个也是要过 JS ，只不过不操作 DOM 元素而已。
而且你这么做不就是在 canvas 上搞 DirectUI 么 ... 第一你这也不叫 DOM ，UI 框架里面的元素就叫 Widget/Element/View whatever ，但是一般不会叫 DOM ，因为广义地来说它是“document model”，最开始 Web 就是文档+链接这么一个 idea ，所以叫“document”，只不过后来被用来做 application 了（这是很糟糕的事情，不过前端很多东西都这么过来的），正经做 UI 不会做出“DOM”这么一个东西。狭义的来说“DOM”是一套标准，不符合这套标准不能叫 DOM 。你看 Python 里面的 xml.dom ，接口和浏览器里的 DOM 是差不多的。

第二你这个不只 WASM 能做，没必要强调 WASM （你后来说的什么“真正的工程”可能是 valid point ，但是和这一点无关）。因为这里真正重要的是你这个 UI 框架的架构设计和组件实现质量，这些是不限语言的，JS 早就玩过了: https://github.com/Flipboard/react-canvas
当然考虑到性能问题的话，WASM 确实可以做到比 JS 更高的性能，但是并不是说你把一个 JS 程序重写成 WASM 性能就一定更高。而且你要“发挥全部潜力”，那 WASM 局限性也很大。这些问题这个帖子里面吵过了: https://v2ex.com/t/804821

Figma 貌似是 React+ReactDOM 做 UI ，然后 WASM+canvas 做渲染。因为 React 这一套经过框架的封装和长期填坑之后已经是很成熟高效的做 UI 的方案，而 Figma 的工作区本来就是一个 literally 的 canvas ，这叫在合适的地方用合适的技术。（当然我做可能会把 ReactDOM 踢掉，因为你应该也看得出来我也不喜欢 native DOM ，但是我觉得在 WASM 里面搞 UI 框架的工作量会远超搞编辑器的工作量 ...）

[gkiwi]

不需要，现在前端都开始学 rust 了[doge]

[oubenruing]

@uni 看到 yew 仓库中描述是这样。操作 DOM API 比直接用 js 慢。希望以后 wasm 能直接控制 dom 吧。

[3dwelcome]

@oubenruing 那个 github 列表，只是用来说明 DOM 事件可以不用 JS 处理。把 ui state 和 event 打包，发给远程服务器，可以用其他语言来处理。

其他语言也可以编译成 wasm 放进浏览器里，那就是消息打包，发给本地的 wasm 内部函数来处理。

对于我来说，写 WebUI 并不需要很高的性能，通过 JS 胶水层来代理控制 DOM ，完全够用。

通常界面都是用户点击后，才会刷新，是个非常低频的函数调用，都不怎么需要去费力优化。只有游戏的 directui ，保持每秒 60 帧刷新率，那才真的需要优化。

[3dwelcome]

@secondwtq

对于我来说，只要是浏览器页面上的单个元素，我都叫 DOM 。比如 html 里，svg 的<rect>标签，就是一个 DOM 。

在 figma 里面，canvas 上的单个 rect ，内部肯定也是一个元素对象。就是没有浏览器 BOM 对象一一对应，这样叫虚拟 DOM ，也都习惯了。

你用 react-canvas 举例，WASM 能做的 UI 框架，JS 也都行，这没问题。但 JS 是无类型的动态语言，写个严谨的算法，需要额外语法补丁太多。算法真的出个错，有时候内部 BUG 都不太好调试，费力不讨好。

放弃 JS ，选择 WASM 写代码就是为了舒心。说运行速度什么，那都是次要的。

[BeautifulSoap]

@murmur 就 JS 那调试器真没什么值得称其为“完善”的。跳入一个大点的 js 文件中当场给你卡死（我曾调试过一个游戏，跳入一个几 MB 的单 JS 文件后整个调试器就直接卡死再也没能恢复）

[murmur]

@BeautifulSoap 那八成是反调试工具，进了死循环了

[BeautifulSoap]

@murmur 根本不是，就是 js 这调试器太弱鸡了，面对大点的 JS 代码就卡死。你试过就明白了

[kop1989smurf]

我个人理解，在非初学者的前提下，软件工程实践领域没有什么“必然需要学习”的。
因为所有“必要”的知识，一定会在你实现业务、逻辑的过程中涉及到，你自然会为了解决而搜索和思考。

[secondwtq]

@3dwelcome #55
> 在 figma 里面，canvas 上的单个 rect ，内部肯定也是一个元素对象。就是没有浏览器 BOM 对象一一对应，这样叫虚拟 DOM ，也都习惯了。

你看看你这个定义推广开来会发生什么事情：
我的头像是用 C4D 搞的 3D 模型，现在在 Three.js 里面渲染出来，因为是在浏览器里面，所以里面的一个 Box 是个 DOM
我用 Unity 做个游戏，里面有根草，哪怕这玩意是 GPU Instancing 出来的，因为可以跑在浏览器里面，也叫 DOM 。
你这个回复每一段有两行，每一行在浏览器里面都会有一个内部的对象来做排版，虽然你没办法用 DOM API 直接操作它，但是因为它在浏览器内部有个东西，所以叫 DOM 。

如果他们不是在浏览器里面，那该叫 mesh 就叫 mesh ，该叫 instance 叫 instance ，该叫 line 叫 line ，就因为生在了浏览器里面，所以通通叫 DOM 。

这 就 是 前 端

> 放弃 JS ，选择 WASM 写代码就是为了舒心。说运行速度什么，那都是次要的。
你是不是忘了有 WASM 之前前端是怎么玩的了 ... JS 不好用没拦着你用 TypeScript ，Reason ，Fable ，PureScript ，Scala.js ，Elm ，Kotlin ，Dart 啊。这和 WASM 依然没有必然关系。

[3dwelcome]

@secondwtq

前端挂在 document 下面的一棵树的子节点，叫 DOM 没问题吧。老外也是这样定义的啊。

"你是不是忘了有 WASM 之前前端是怎么玩的了"
在 WASM 之前，JS 是绝对的王者，又没人能撼动其地位的。是 WASM 把虚拟机概念引入了进来，今天微软能用 mono 编译成 wasm 来运行.net 的 dll ，明天说不定就能运行 exe 了。这在以前，完全超乎普通人的认知。