这是一个创建于 1047 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题，请教各位大佬，是否前端都应该熟练使用 node 呢，这样是不是应该就包括后端一系列的基础知识
 |
1
shanyuhai123 2022-01-12 14:02:54 +08:00  3
不要说应不应该学，当你持续深入的时候这些你自然就遇到了。
1. 为了解放复制粘贴，自然就用到 node 读取写入文件 2. 为了写个简单接口，自然就了解到 koa 、nestjs 等 3. 为了部署服务，你自然就了解到服务器知识 4. 服务器被人挂马了，你自然就知道网络安全的重要性 |
 |
2
murmur 2022-01-12 14:18:03 +08:00
除非你们用 node 跑后端，需要学调优这些，否则就复制粘贴 google ，用啥学啥
google 需求+npm ，库都封装好了 |
 |
3
66beta 2022-01-12 14:33:33 +08:00
当然是选择 PHP 啦
|
 |
4
3dwelcome 2022-01-12 14:39:42 +08:00
我也不知道为什么那么多人喜欢用 JS 。
同样学 wasm ，也可以做到前后端逻辑通吃，使用语言又完全随心所欲。 JS 开发调试工具没那么完善，写起来就好比把双手双脚束缚起来，完全没办法发挥全部潜力，跳不到最高点的。 |
|
5
murmur 2022-01-12 14:44:36 +08:00
@3dwelcome js 调试工具可太完善了，不就是 chrome dev tools 么，wasm 为啥要学，不都是其他语言编译过来的么
现在也就是吃 wasm 没调试工具，好混淆，红利一过大家又会想起 js 的好 |
 |
6
mxT52CRuqR6o5 2022-01-12 14:56:19 +08:00
不说要有多熟练，node 一窍不通总是说不过去吧，毕竟大部分都是 js 本身的东西
|
|
7
3dwelcome 2022-01-12 15:07:17 +08:00
"js 调试工具可太完善了，不就是 chrome dev tools 么"
JS 调试和早年比是体验好不少，但和别的语言比，还是有不少差距的。 去年 google 给 chrome 特别支持了 wasm 调试，就是源语言变量也能完美显示的那种。 而且 wasm 是偏二进制内存处理，这点恰恰是 js 的弱项。js 的强项是处理文本逻辑。 |
|
8
mxT52CRuqR6o5 2022-01-12 15:10:05 +08:00
@3dwelcome 要求兼容 IE🐶
|
|
9
mxT52CRuqR6o5 2022-01-12 15:12:54 +08:00
@3dwelcome 正经的讨论一下，wasm 现在生态肯定比不过 js 啊，js 有那么多现在的样式库，wasm 的有多少
|
|
10
3dwelcome 2022-01-12 15:13:52 +08:00
|
|
11
3dwelcome 2022-01-12 15:16:10 +08:00
@mxT52CRuqR6o5
"wasm 现在生态肯定比不过 js 啊，js 有那么多现在的样式库，wasm 的有多少" 正常来说，用 WASM 和用 JS 的，是两种项目两类人，相互之间没太多交集的。 只有极少数我这种用 WASM 写前端逻辑的，习惯后，我个人觉得比写 JS 舒服。 |
 |
12
shyling 2022-01-12 15:24:34 +08:00
还有裸写 wasm 的？
|
 |
13
rsyjjsn 2022-01-12 16:09:55 +08:00
一个稍微技术好点的部门，都有基建的需求，搞基建难道你就用浏览器就能解决？脚手架，打包工具，规范组件库那个不需要 node?
|
 |
15
devwolf 2022-01-12 16:36:51 +08:00
是哪个定义下的“学习 node”？
我个人的理解是， 搭项目、研究 webpack 这块也视作学习 node ，而不是仅限于 express 这样的 |
|
16
3dwelcome 2022-01-12 17:15:46 +08:00
|
|
17
3dwelcome 2022-01-12 17:35:44 +08:00
我说一下自己 wasm 模式下的前端吧，还是和上面视频有点区别，没用到 websocket 。
简单来说，就是把 UI 状态和 DOM 节点还有点击之类的事件，打包后发送给 wasm 内部处理。 wasm 内部用其他语言接管逻辑，对 UI 状态解压，对事件响应。同时用模板生成的页面 DOM ，再发送给浏览器生成动态 UI 。 由于 wasm 是浏览器端的，完全不需要服务器辅助，帮我替换了几乎 90%以上的前端逻辑 JS 代码。 |
|
19
3dwelcome 2022-01-12 17:40:33 +08:00
@shyling
不啊，blazor 是基于 C#的，我不太喜欢 C#。 wasm 又不限制特定语言，随心所欲都可以。 以前用 php 写后端模板，后来用 js 写前端模板。写多了，真的是烦透了用 js 拼接字符串，不想再玩了。 |
|
20
shyling 2022-01-12 17:42:11 +08:00
@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 搞了半天还不是写别的语言。。 |
|
22
3dwelcome 2022-01-12 17:49:14 +08:00
@shyling “和用个 scala, kotlin 生成个 js 也没啥区别吧”
是没区别，就是单纯的不喜欢 JS 语法，操作的是对象，不是内存，玩不出花样。 写习惯了别的语言后，换 JS 总有一种说不出来的束缚感。 只不过浏览器和 APP 的存在，导致大家又离不开 JS ，所以 vue 和 react 才那么受欢迎。如果当初没发明 JS ，也许现在互联网会更好。 |
 |
24
DOLLOR 2022-01-12 18:45:51 +08:00 via Android
@3dwelcome
毕竟 js 的生态繁荣，别看网上嘲讽 js 段子多，那恰好是 js 流行的反映。 wasm 的一等公民 C/C++/rust （其他语言都只能算气氛组），个个都是高门槛，不用指望 js 都不愿用的人去学它们。 |
|
25
3dwelcome 2022-01-12 21:06:57 +08:00
|
 |
27
sickoo 2022-01-12 23:13:09 +08:00
取决你的方向，好比你只做页面样式，或者简单逻辑，可能用不上多深的 node ，但是专注前端开发绕不开 node ，至于 JS ，九几年就诞生直到现在，没啥说的
|
 |
28
icySoda 2022-01-13 00:44:04 +08:00 via iPhone
@3dwelcome 大佬能发个 demo repo 看看吗，感觉你这样搞渲染性能会很差啊，每次都从从 wasn 生成模板来渲染
|
|
29
3dwelcome 2022-01-13 02:22:22 +08:00
@icySoda
仔细看 B 站视频，每次渲染都是局部 DOM 替换，速度很快的。用前端的属于，这叫细粒度更新。 前端真正的性能挑战，在于处理 DOM 海量数据的数据上。 这点传统 VUE 的框架有致命缺点，就是 DOM 节点数量有上限。WASM 则刚好弥补全这点，参见 figma 的设计，全都是 WASM 里面的内存对象去模拟 DOM 。 |
 |
30
secondwtq 2022-01-13 03:16:50 +08:00
@3dwelcome 我感觉到了“海量 DOM”这个程度上，浏览器已经卡得不能自理了 ...
这种情况不是应该虚拟列表啥的先把 DOM 降下去么 ... |
|
31
3dwelcome 2022-01-13 03:37:01 +08:00 via Android
@secondwtq
表格的虚模式也不是万能的，第一只能呈现相对简单的结构，第二会让前端代码逻辑变复杂，不好维护。 在 wasm 里，不渲染的 DOM 对象，仅仅只是占个内存，不会让浏览器实际运行变卡。 现在大家缺的不是内存，是性能。JS 为了绕过海量 DOM 缺陷，给代码打上无数个补丁，绕来绕去，这也是我不喜欢 JS 的地方。 |
|
32
secondwtq 2022-01-13 03:56:33 +08:00
@3dwelcome 我就是不明白你这个“DOM”指的是啥 ...
前端说 DOM 指的就是浏览器 native 的 DOM 对象。还有一个为了减少 native DOM 对象操作搞的虚拟 DOM 。不过这俩是分得很清楚的，说 DOM 就是 DOM ，说虚拟 DOM 就是虚拟 DOM 。WASM 里面也可以做虚拟 DOM ，但是要做“DOM”必须过 JS 。 |
 |
33
rioshikelong121 2022-01-13 08:37:29 +08:00
Rust + Node + deno 。三手抓，三手都要硬。
|
 |
34
jguo 2022-01-13 08:42:48 +08:00
node 只是 javascript 在浏览器外的运行环境，跟后端是两码事。只要涉及前端工程化必然要用到 node
|
 |
35
yaphets666 2022-01-13 09:18:32 +08:00
@3dwelcome 因为你不是专业前端，你做的前端项目也不是真正的工程。WASM 的出现是为了增强前端对某些特定功能的实现能力，比如在线音视频剪辑。不是让你拿来写逻辑的。java 一样也可以写前端逻辑。
|
 |
36
IvanLi127 2022-01-13 09:22:02 +08:00
不搞基建，不学没事，知道怎么运行 node 程序就够了。
|
|
37
3dwelcome 2022-01-13 09:32:06 +08:00
|
|
38
3dwelcome 2022-01-13 09:38:01 +08:00
@yaphets666
仔细看 B 站视频，视频里的 WASM ，就是用来写逻辑的。你不用，不代表别人也不用啊。 所谓“真正的工程”，JS 也是这几年，才刚从 TS 体系建立起来。而 WASM 背后别的语言，很多都有几十年大工程的经验积累，随便哪个体量，都是秒杀普通前端项目的。 |
 |
39
grewer 2022-01-13 09:55:45 +08:00
学 都可以学
|
|
40
yaphets666 2022-01-13 10:06:04 +08:00
@3dwelcome 。。。你还是不懂兄弟，你们这些业余前端的两个特征，喜欢吹 TS 和 WASM
|
 |
41
oubenruing 2022-01-13 10:16:11 +08:00
@3dwelcome 个人看来，目前 wasm 是用来处理一些 cpu 密集计算使用的，例如处理一些图像计算。
如果是： 1."不用必须经过 JS ，WASM 可以直接在 canvas 上自绘制，有 gpu 加持后，性能很高的" 利用 canvas 来做一些网页级别的工作。 那面临的代码将会从 "使用 html js css 写个页面" 变成 "使用任意可编译成 wasm 的语言 （ X 语言），写一个 dom 解析器，css 解析器，以及用 X 语言 来控制 canvas 中的绘制(逻辑控制)"。这样听起来是否就会变成：用 X 语言写了一个浏览器，然后编译到 wasm ，并且嵌入到浏览器中？ 如果是： 2."" |
|
42
oubenruing 2022-01-13 10:19:45 +08:00
@oubenruing
手滑继续： 如果是： 2."用 wasm 做一个类似 react 的框架"，那听起来似乎性能更高，但是 wasm 数据传给 js 来最终控制 DOM ，将会有额外的 IO 开销。实际性能如何，还要实验才知道。 如果是： 3.用 wasm 控制 cavnas 绘制一些简单的 ui ，和复杂的图形图像场景或进行 CPU 密集型计算，我觉得是正解。 |
 |
43
Leviathann 2022-01-13 10:27:50 +08:00
es6 还行啊
解构就是半个 pattern matching |
 |
44
linshuizhaoying 2022-01-13 10:40:40 +08:00
抛开团队开发协作性框架谈 js wasm 性能并没什么用 js 再垃圾 起码三大框架给入门到深入都有适配 前端更多还是协作性开发 只折腾小项目当我没说
|
|
45
3dwelcome 2022-01-13 11:12:06 +08:00
@yaphets666
软件工程最重要的是代码复用，JS 代码复用性和跨平台移植性，远远没有虚拟机 WASM 来的好。 可能没看到实际代码，想法相互理解不了，也正常。反正我自己写的很爽。 前端那么卷，职业规划被 JS 限制死不是什么好事，不利于和后浪竞争。 大家天天用 Babel 支持 ES 新特性，我不过把别的语言编译到 WASM ，再从 WASM 编译回 JS 来运行，这并不奇葩的，最多小众了一点。 |
|
46
oubenruing 2022-01-13 12:20:29 +08:00
@3dwelcome 请问能否有个小 demo 供学习，我也有做过一个 c++ 编译的 wasm 小工程 处理图形计算的。希望可以交流下。
|
|
47
3dwelcome 2022-01-13 12:30:09 +08:00
|
 |
48
retrocode 2022-01-13 12:40:36 +08:00
倒不必须是 node,前端由于生理限制只能是 js,对 node 的熟悉随用随查,慢慢就好.
后端别限制太死,java/php/python/node 随便掌握一个即可,把自己当全栈发展. 比如我工作用 vue/react 写前端,java 写后端,然后自己写的简易 api 会用 php. 别把语言限制太死,工作中你要让我接手 N 年 java 项目我勉强可以接手,但是要让我接手 N 手的 PHP 项目我可能会边做边骂娘考虑跑路 然后我自己写 api 还是习惯 php...写完直接丢 nginx 里就好,免编译,支持在线修改爽啊 |
 |
49
uni 2022-01-13 12:53:58 +08:00
@oubenruing wasm 做的类似 react 的框架就是 yew 吧，实际性能并不见提升很大
|
|
50
oubenruing 2022-01-13 13:36:21 +08:00
@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/ |
|
51
secondwtq 2022-01-13 13:43:23 +08:00
@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 框架的工作量会远超搞编辑器的工作量 ...） |
 |
52
gkiwi 2022-01-13 13:44:15 +08:00
不需要，现在前端都开始学 rust 了[doge]
|
|
53
oubenruing 2022-01-13 13:46:06 +08:00
@uni 看到 yew 仓库中描述是这样。操作 DOM API 比直接用 js 慢。希望以后 wasm 能直接控制 dom 吧。
|
|
54
3dwelcome 2022-01-13 14:33:52 +08:00
@oubenruing 那个 github 列表，只是用来说明 DOM 事件可以不用 JS 处理。把 ui state 和 event 打包，发给远程服务器，可以用其他语言来处理。
其他语言也可以编译成 wasm 放进浏览器里，那就是消息打包，发给本地的 wasm 内部函数来处理。 对于我来说，写 WebUI 并不需要很高的性能，通过 JS 胶水层来代理控制 DOM ，完全够用。 通常界面都是用户点击后，才会刷新，是个非常低频的函数调用，都不怎么需要去费力优化。只有游戏的 directui ，保持每秒 60 帧刷新率，那才真的需要优化。 |
|
55
3dwelcome 2022-01-13 14:43:11 +08:00
@secondwtq
对于我来说，只要是浏览器页面上的单个元素，我都叫 DOM 。比如 html 里，svg 的<rect>标签，就是一个 DOM 。 在 figma 里面，canvas 上的单个 rect ，内部肯定也是一个元素对象。就是没有浏览器 BOM 对象一一对应，这样叫虚拟 DOM ，也都习惯了。 你用 react-canvas 举例，WASM 能做的 UI 框架，JS 也都行，这没问题。但 JS 是无类型的动态语言，写个严谨的算法，需要额外语法补丁太多。算法真的出个错，有时候内部 BUG 都不太好调试，费力不讨好。 放弃 JS ，选择 WASM 写代码就是为了舒心。说运行速度什么，那都是次要的。 |
 |
56
BeautifulSoap 2022-01-13 15:48:26 +08:00
@murmur 就 JS 那调试器真没什么值得称其为“完善”的。跳入一个大点的 js 文件中当场给你卡死（我曾调试过一个游戏，跳入一个几 MB 的单 JS 文件后整个调试器就直接卡死再也没能恢复）
|
|
57
murmur 2022-01-13 16:50:08 +08:00
@BeautifulSoap 那八成是反调试工具，进了死循环了
|
|
58
BeautifulSoap 2022-01-13 16:56:32 +08:00
@murmur 根本不是，就是 js 这调试器太弱鸡了，面对大点的 JS 代码就卡死。你试过就明白了
|
 |
59
kop1989smurf 2022-01-13 17:20:22 +08:00
我个人理解，在非初学者的前提下，软件工程实践领域没有什么“必然需要学习”的。
因为所有“必要”的知识，一定会在你实现业务、逻辑的过程中涉及到，你自然会为了解决而搜索和思考。 |
|
60
secondwtq 2022-01-14 02:00:44 +08:00
@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 依然没有必然关系。 |
Select Language