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

[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 ，可以避免很多问题。

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

[murmur]

@lanten 不要试想，拿出具体的业务来，为了吹 react 的好举例子可太多了，你把这个落到具体业务里再来说

[murmur]

你这个设想，先把 ui 设计打一顿，一个系统里的 notification 有 10 个复杂不同样式，ui 和需求总得有一个要挨打

[shyling]

@shyling 噗嗤，自己杠吧

[Alander]

@lanten 太难沟通了，包括后面举的例子，这种业务真的存在吗，如果真的存在样式还不统一，那我确实没什么好说的，产品和研发肯定有一个有问题。
你也没理解我说的意思：vue 完全可以选择用 jsx 去写代码，而它采用了 template 。你还在揪着“可以写，写的难看”，vue 都不采用还争辩什么呢。根本不需要 jsx ，因为本身就是糟糕的形式。
对此我不会再进行回复了，你认为的是对的，我认为的也是对的。

[gadfly3173]

@lanten #100 以 vue 中最常用的 element-ui/element-plus 为例，你要是想在一个弹出组件里搞一堆复杂的逻辑而一般的组件库还不能满足的时候，首先你就应该去用那个叫做 dialog 的东西，这个东西可以像你写 div 一样放在 template 的任何地方，自己调整下样式就好了。

[lanten]

@Alander @gadfly3173 不管是 notification 还是 dialog ，还原的都是在 render 函数之外插入 React.Node 的场景，notification 中添加操作按钮简直不要太常见，加个 icon ，加个链接，导一个组件，等等。。怼都怼不到点上，只会暴露出自己代码写得少。

此特性属于基础特性、基础功能，它没有得到支持，这就是客观事实。

@Alander 自始至终我都是基于 “template 方案优于 jsx 方案” 这个观点提出异议，根本没有反对在 vue 中使用 jsx ，你这种篡改发言的行为有点莫名其妙。

[gadfly3173]

@lanten #106 不如你先看看 react 的知名组件库 antd 的 notification 的实现？按你说的这么广泛的需求，应该会是第一梯队的组件库会去实现的东西，至少我们可以看到 antd 没有这么做。antd 虽然提供了一个可以传入 button 的接口，这个也只是让你来自定义一个按钮而已，位置也是不能通过简单设置改变的。
vue 和 react 都是数据驱动视图的框架，但是你一直强调要在 render 函数之外来进行组件的创建传递，那么还需要 render 函数干嘛呢？你所需求的实现对于 template 来说一样可以做到啊，你也可以像 element 一样做一个 SFC ，把你需要的东西都做成配置项再暴露一个全局方法。

[wangtian2020]

学会 async fun 后。回调？狗都不写

[2i2Re2PLMaDnghL]

@lanten 你是真没看懂 @Alander 在说什么
你确实没有『反对在 vue 中使用 jsx 』，因为他说了他在反对并认为鱿鱼也不推荐。Vue 的编程界面，默认可以选 JSX 也可以选 template ，鱿鱼最后选了 template （尽管留了 JSX 的路）。

[sjhhjx0122]

吵这么长，还是 angular 香，打起来打起来

[xqk111]

前端早就不是远古时代了

[tenclock]

react 和 vue 大战又开始了

[lanten]

@gadfly3173 你这一条把我逗乐了，你好好阅读一下 antd 的文档，notification 的 api 中 message 和 description 字段接收的类型到底是啥，看清楚了再发表想法。如果你不知道 ReactNode 类型意味这什么，去查阅 react 文档，希望你有所收获。

@2i2Re2PLMaDnghL 任何人在 vue 中使用任何方案我都没有意见，你甚至可以使用 jq ，这与我们讨论的议题有关联吗？我要捍卫的，是 template 相对于 jsx 具有致命缺陷这一真理。

楼上有个老哥称述了 react 使用优雅这一事实，并没有提到 vue 怎么怎么样，迅速引来一群人围攻，并且这些人的论据是可笑的 template 优于 jsx 这一观点。

拿着牙签拼刺刀。

大多数人都是谦逊的，不屑于争论，这让一些人产生了“我很能打”的错觉。

[2i2Re2PLMaDnghL]

@lanten 我只是向你解释一个鸡同鸭讲的情景；我解释完了你愿不愿意跳出来是你的事情。
我是认为 template 和 jsx 没什么区别，jsx 只是把 template 内联进代码里去了。你把 template 写在哪并不影响它还是个 template 。
最恰当的是通过编译器重新解读 a.data=b 的含义，这一过程中必不可少地需要反复地构造元解释器，所以唯有 s expr 才是终级方案。

顺便一提，你 #95 提出的那个情况，我弄 Vue 的时候随手做过一个封装，只要构造一个 notifiable 组件就行，用起来像这样：
<notifiable ref="notification">
...anything
</notifiable>
平时渲染为空，要弹通知时使用 this.$refs.notification 调用相关方法
因为这个封装太简单了，大概只写了十分钟，所以根本没有保留下来。
预先放置在 VDOM 里的话，因为会一并接受 JIT ，可能效率还高不少。

[Yuiham]

@shyling
“<slot>也是凭空出来的定义”
————————————
slot 可不是凭空设计出来的，是基于 Web Components 的 [Slots 提案]( https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Slots-Proposal.md) 设计出来的

[shyling]

@Yuiham https://github.com/vuejs/vue/issues/1167 嗯，有关系

[tianzi123]

@M003 初学者今天刚写了遍轮播图,js 部分 80 行左右吧,感觉这玩意直接封装调用应该更有效率

[lanten]

@2i2Re2PLMaDnghL 说的好，你指出了两个看上去可行的替代方案。
现在我顺着之前的例子继续延伸，在全局 request 方法中通常需要添加一个异常拦截器，我希望在状态码异常时调用 notification 弹出错误消息（包涵额外组件）并返回 Promise.reject 。
按照你 notifiable 组件的逻辑，我是不是要将这个全局处理定义为.vue 文件？
并且我在什么地方调用 request 方法，就要在什么地方导入并初始化这个组件。
如果没有发生请求异常，那么在运行时的 notifiable 组件初始化产生的算力开销是无意义的。
这合理吗？这不合理。

所以在这种场景下，良好的解决方案应该使用你说的 sexpr ，也就是半结构化表达式来创建 VNode ，并手动将 VNode 挂载到真实 DOM 上（这里手动挂载的操作在 react 中也是一样的）。
能做到，但是很麻烦且难以阅读。

我写过两年以上的 vue ，一直在尝试解决这个问题，但是没有成功，只能通过手动创建 VNode 来妥协。
这是一种回归本源的操作，就好像某一个高级语言你写着写着，忽然发现某一个功能无法实现，你只能通过手敲二进制码来曲线救国，这样的缺陷要是放在一个语言中，我完全可以将其定义为图灵不完备。

这是在 template 方案设计之初就注定无法弥补的缺陷。
缺陷就是缺陷，大可不必那么倔。

[2i2Re2PLMaDnghL]

@lanten 这个开销九牛一毛，现在的框架都是在用 vDOM 开销换 DOM 开销，这里只有 vDOM 有开销。
另一方面也可以 <notifiable v-if="..."> 处理
s expr 是真正意义上结构化的，代码即数据。

顺便，个人经历：绝大多数语言都没有开箱即用的 safe_eval 或者 sandbox_eval ，导致很多时候不得不重复一下格林斯潘第十定律。
这是不是说这些语言都是图灵不完备呢？你要说是，我举双手双脚赞成。

另，有没有可能，这不是缺陷而是 feature 呢？