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

[zzwyh]

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

[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 依然没有必然关系。