一个后端程序员对前端技术的彩虹屁

[WadeLaunch]

我上次正式的写前端代码还是 10 年前，那时候要处理各种浏览器的兼容问题，IE 678 ，Firefox ，Chrome 等等。那时候 WebSocket 标准还是草案阶段，Firefox 和 Chrome 实现的版本还不一样，其他浏览器根本不支持，要开发一个聊天的功能，用了多种方案兼容不同的浏览器。

那时候大家的简历都是写的“熟悉 Div+CSS”，哈哈。而我从来没有真正把 CSS 里的 float: left|right, clear: left|right 搞明白，只知道加了某一行，刷新浏览器，噎，可以了。

JavaScript 框架大部分都是用的 jQuery ，有些项目用的 IBM 的 dojo ，还有 Yahoo 的什么框架，名字也忘记了。

用 Node.js 写聊天功能的后端逻辑，各种回调搞到吐。

后来也写过一些自己用的监控管理页面，一般都是用的 jQuery 和 Bootstrap 。

---

直到最近我要做一个业务管理后台，同时想趁机学一下久仰大名的 Vue 和前端的各种最新技术，就找到一个使用 Vue 的开源后台方案。在学习使用这些新技术过程中，让我每天都感叹现在的前端技术太强了，太好用了，太牛逼了。

请原谅我下面的失态。

ES6 真是太好用了！！！

1. for of, for in, Array.isArray(), Object.keys()...，让循环简单了很多。
2. Let, const, destructuring, template string 太方便了。
3. async, await, promise 太好用了，彻底解决了回调黑洞。
4. Arrow function 赞赞赞！
5. fetch() 这个 API 真是简练啊，同时给 axios 点赞。
6. 给 new FormData() 点赞！
7. 各种浏览器都实现了 ES6 ，然后终于把 IE 淘汰了（同情还要兼容 IE 的朋友）
8. 还有很多优点没写，有同样感觉的可以补充。

CSS 里的 display: flex 真棒！ CSS 其他的新技术我还没学，肯定有很多好用的技术。

然后 Vue 太牛逼了！想起以前用 jQuery hide/show 、append DOM 苦日子，我现在每天都感叹 Vue 牛逼！这就是响应式(reaction) 啊？

题外问：非浏览器的原生界面是否一直都是响应式这种方案？ Vue 是把这种技术移植到了浏览器前端？

再来一次：Vue 牛逼！

在编辑器保存后浏览器自动刷新界面，太方便了🥰。这是用 vite 实现的吧？还没有仔细研究 vite 的功能。

最后，TypeScript 这么牛逼的语言 V 站上怎么才 5 页讨论帖啊，比 Rust 还少，它比 Rust 简单多了吧，是大家很少用吗？类型系统这么强的语言怎么不用，能避免大部分写 JavaScript 时的低级 bug ，赶紧用起来。 虽然我现在不用 Node.js 了，但我认为新项目应该要强制用 TypeScript ，可以避免很多问题。

我本来打算上周就写贴彩虹屁的，但拖延症发作，今天看到下面这贴，被它催更(写)了。 “现在的前端技术栈真的太恶心了！”

[gadfly3173]

@shyling #74
1 、虽然可以在 vue 的指令里直接写很多代码，但是应该没有正常人会这么写吧。。。常规做法就是在这些地方传入一个值，这个值可以是 data 、computed ，也可以是 methods 返回的
2 、slot 也许看着有点怪，但是你理解成<div><slot></div>的话，slot 和你平时写在 div 之类的地方里的内容没什么区别

[lanten]

@Alander

“只有新手才会在 jsx 中添加大量业务代码。” 是反驳 @murmur 在 15 楼的观点。

依赖库中存在大篇幅代码和业务代码中的上千行是两码事，你在日常开发中根本不需要阅读和维护库中的代码，而业务代码不同，篇幅越大越难以理解。

react 的优雅是在于程序设计，而不是代码范式。

你似乎不太理解插入元素的含义，插入的不是原生 dom ，而是 jsx 虚拟 dom ，我真的不太明白你是怎么理解到那上面的，这让我感觉你似乎不是很懂。

逐句对线你似乎怒气很大，就像炸了毛的刺猬，有点好笑。

[murmur]

@lanten 所以我帮你总结下观点

vue 对 ts 支持不好

这不就完了

[shyling]

@gadfly3173 写代码这个我觉得应该不算少见吧。。。v-if="xxx.length"
主要多了心智负担，你的双引号里不是字符串而是 js 代码。
然后你看了 v-for ，又发现你的双引号里的不是 js 代码。。a in b 得到的 a 居然不是 key 。。

[Torpedo]

其实都是发展演化来的，也不都是凭空出现，只有逐渐淘汰的

发展演化来的：
vue 、react 框架，在 n 年前，虽然大部分都写 jq ，但是上规模的项目都有自己封装的框架，基本做到组件化，但是响应式数据绑定做的不多，而且大家各自封装，没有几种特别流行的

ES6 这些，吸取了很多 es4 标准，不过 es4 死掉不谈，lodash 等函数库和内置 api 有很多相似的地方

编辑器保存后浏览器自动刷新界面，live reload 很早就有了，不过现在基于响应式的视图，发展除了 hmr （不过有些人不一定喜欢用）

强类型语言，最开始 coffe 和 ts 齐头并进，后来 ts 更贴合 js 生态，加上 vscode 、 @types 的支持，ts 慢慢胜出。同时 ts 自身也不断完善

nodejs 的回调，也是从回调到 generator 到 async await 越来越方便


逐渐淘汰的：
IE 的兼容性问题
float 的布局方式

其实楼主感觉是对的，整体就是再越来越好。只不过也带来一些问题

[gadfly3173]

@shyling #84 xxx.length 这种还是可以接受的范围，可以很直观的知道这是一个值。
双引号里是代码这个其实只有声明了这个属性需要 bind 才是代码，vscode 装上官方插件就会有高亮，webstorm 也有很好的支持。这个东西我觉得比按照 react 那样要搞一堆拼接还是更容易理解的
v-for 这个确实坑爹，in of 竟然还是相同的表现。。。

[shyling]

@gadfly3173 对呀，template 里的怪怪的。

结果就是你想用个新语法，obj[key] ?? 'xxxx' 还得思考一下到底能不能用

[Alander]

@lanten

“只有新手才会在 jsx 中添加大量业务代码。” 是反驳 @murmur 在 15 楼的观点。我就是在替 15 楼反驳你的观点，你说 react 不会有上千行代码，vue 也不会有，你说 vue 会有上千行代码，react 也会有

依赖库中存在大篇幅代码和业务代码中的上千行是两码事，你在日常开发中根本不需要阅读和维护库中的代码，而业务代码不同，篇幅越大越难以理解。React 本身就是个业务框架啊，写 React 就是一种业务啊，其中 reconcilation 的代码也就是普通业务，其理解难度本身也很大，代码行数上千行。所以你的“上千行的代码就是糟糕的代码”这个观点肯定是不敢苟同。

“你似乎不太理解插入元素的含义，插入的不是原生 dom ，而是 jsx 虚拟 dom ，我真的不太明白你是怎么理解到那上面的，这让我感觉你似乎不是很懂。” show me the code ，让我看看到底是什么场景，我确实没理解你说的 jsx 虚拟 dom 是什么场景，如果你说的是可以用 js 写 React.crateElement ，那用 babel 替换 React.createElement ，完全可以用 jsx 写 vue ，vue 没有用 jsx 而是用 template 的考量普通业务程序员有思考过吗？

“逐句对线你似乎怒气很大，就像炸了毛的刺猬，有点好笑。”我怒气并不大，只是实在是在技术上看见你说的一大堆文字里面没几句话是正确的，摘出来提醒后续人看的时候注意一下别带偏了。

反倒是我想问你个问题，你理解的 jsx 到底是什么？你理解的虚拟 dom 到底是什么？你知道为什么你只需要写 jsx 却可以最后生成了 dom 元素？如果理解了那你理解 vue 是怎么生成的 dom 元素？如果理解了这两个差异是不是用现有工具完全可以用 jsx 写 vue 代码？

不懂可以，在指出来问题的时候不要避重就轻，理性回复就可以了。

[Alander]

@murmur haha

[murmur]

@shyling a in b 对于数组来说本来就直接对着元素遍历啊，你难道不知道要 key 可以写 item, index in array 这种写法

[unco020511]

后端你用 kotlin 可能也会有这种体会

[yazoox]

@libook "以及用 Rust 写 WebAssembly 可以把性能坑也给填了"听到过几次这种说法，不是很理解。
有没有比较好的文档，或者例子，来说明，如何使用 Rust 解决前端的某些性能问题？谢谢

[libook]

@yazoox #82 JS 虽然借助一些引擎能具有很不错的性能了，但保不齐有一些对性能要求极其苛刻的场景，比如专有格式的视频解码，用 JS 写个视频解码器怕不是只能放 PPT ，那么你可以用 C++、Rust 等语言，按照 WebAssembly 标准来写，然后编译成 WebAssembly 字节码的 js 文件，在页面上引入这个 js 文件，然后就可以用原生 JS 来调用解码器对视频进行解码了，性能能做到跟 C++、Rust 编译成的桌面版本软件差不多。

感兴趣可以直接去 MDN 上看相关介绍，https://developer.mozilla.org/zh-CN/docs/WebAssembly

[Austaras]

@murmur 那你去写 _jsx/createElement 啊谁拦着你了。。。

[lanten]

@Alander

你最好查看并尝试理解一下 15 楼老哥到底说了啥。

你也提到了用 jsx 写 vue ，你看，你这不是能理解吗？
遗憾的是，vue 的 jsx 与 ts 的契合度非常差。

这是一个简单的例子， `notification.error` 方法会在执行后弹出一条消息。注意此方法可以在任意区域执行。
```tsx
notification.error({
content: (
<div>Any React.ReactNode</div>
)
})
```

[shyling]

@murmur 没看懂意思吗，js 本身的语法里可不是你说的这样。你难道以为你在 js 里写 py ？

[murmur]

@shyling js 的语法里有 xml 么，你都 jsx 了还在 js

[murmur]

@lanten 这个例子很糟糕，有什么场景让 notification 弹出的消息还要嵌套组件

这是 dialog 不是 notification ，如果复杂到 dialog 肯定要抽组件出来的

[murmur]

而且正常的思维不是
this.$notification({
type: 'error',
icon: 'icon-alert',
title: '错了',
msg: '你自己猜哪里报错了',
callback: function(){...}
})

[lanten]

@murmur

试想想一个场景，你需要弹出 10 个 notification ，每一个的 content 都不相同，它不是简单的 string ，里面有 input ，有 button ，有其他组件，量不大。按你说的封装策略，是不是需要封装 10 个组件？这些代码分散后，阅读者无法一目了然的掌握所有逻辑，还得一个个找，可读性是不是就差了？