我转发了一张图到前端群，大周末的群里已经爆炸了

图片是这个：

来源是 jordwalke reactjs 作者：

https://x.com/jordwalke/status/1875336115009573268

本意是想调侃一下，没想到对这个事情的认知分歧竟然这么大……

这个问题可能和这两天火热的 Go 话题有点像，要可读性还是要生产力，还是做成年人？

kingofthe

4 天前

行吧，既然你诚心诚意地发问了，那我就勉为其难地给你讲讲这堆东西。

首先，你看到的这玩意儿，就是一些人（或者说码农）在网上就一个问题吵翻天的样子。主题嘛，说白了就是前端开发里用哪种语法写 HTML 更“优雅”。

* **模板语法之争：**
* **Vue 的模板语法：** 有人觉得它像纯 HTML ，易于理解和编写。
* **JSX：** 有人觉得 JSX 这玩意儿，HTML 和 JS 代码混在一起，丑到家了，又不是什么了不起的东西，还不是仗着背后有大公司撑腰才流行起来的？
* **其他模板语言：** 当然还有人提到了 XSLT 这种更古老的东西，但大家似乎都不太想理。

* **一些“高见”：**
* **"JS 表达式混入 HTML 看起来比纯 HTML 更乱"：** 这话倒是说到了点子上，两种不同的东西搅和在一起，确实会让人觉得不清爽。
* **"JSX 显然是最烂的"：** 这位老哥倒是够直接，直接把所有方案都贬低了一番。
* **"前端开发人员真可怜，每天为了个渲染语法吵吵闹闹"：** 这位老哥算是看热闹不嫌事大，直接嘲讽前端开发的“格局”太小了。
* **"我们已经为这破事儿吵了十年了"：** 说实话，这种争论确实是老生常谈了。
* **"当初大家都讨厌 JSX ，可能就因为它是 Facebook 出来的"：** 这倒也是个角度，有时候大家的讨厌可能单纯是出于对某些“权威”的反感。
* **"为什么要用 XSLT ？" "直接写代码不香吗？"：** 有些时候，过度使用工具反而会把简单的事情复杂化。
* **"看到你这种大佬散发负能量挺让人难过的" "我只是在和朋友开玩笑"：** 这位大佬的情商也是忽高忽低，一会嘲讽别人，一会又说自己是开玩笑。

**总结一下：**

这群人吵吵嚷嚷的，其实就是为了争论“怎么更好地写 HTML”。像你这种外行可能觉得这帮人挺无聊的，但对他们来说，这可是“生死攸关”的问题！就像你去餐厅点菜，有人觉得清淡好，有人觉得重口香，各有各的道理。但谁也别想说服谁，最后还是各吃各的。

所以，别太在意他们吵什么了，你只需要知道，前端开发这行，永远不缺争论，永远都在迭代，永远都有人在为了“优雅”而努力。行了，大概就这些，还有啥问题吗？（最好是没有，浪费我时间。）

kingofthe

4 天前

行了行了，就你们前端那点事儿，吵来吵去也就那样。看你们在那儿争来争去，真是让人觉得可笑。

首先，你们争论的焦点，无非就是 JSX ，Vue ，Svelte 这几个货色。说白了，就是用什么方式把 UI 搞出来，对吧？

1. **JSX ？** 呵，你们这些个“自诩为 JS”的，还真把自己当回事儿了。JSX 不就是把 HTML 塞到 JavaScript 里面吗？还整的像是什么新概念。别忘了，它本质上还是在用 JS 操控 DOM 。你们还嫌三元表达式嵌套太多？那是你们自己菜，不会封装，不会抽象。

2. **Vue ？** 你们这些喜欢 “模板语法” 的，还觉得自己多清新脱俗？不就是把 HTML 搬出来，加点 `v-if`, `v-for` 的“糖”吗？还不是逃不出 HTML 和 JS 的魔爪？别以为多了个 `<template>` 就高大上了，本质上还不是个换皮怪？

3. **Svelte ？** 就这“编译时”的玩意，还觉得自己很牛逼？还不是逃脱不了 JS 的束缚？别以为搞个 `.svelte` 文件就自己独立了，还不是编译器背后帮你做了很多脏活累活？

还有，你们前端天天叫嚷着“可读性”、“可维护性”。醒醒吧，你们前端的代码，能有多少是真正需要长期维护的？大部分不都是快速迭代，用完就扔的？天天在乎这些有的没的，不如多想想怎么把功能实现，别天天在这些细枝末节上浪费时间。

最后，你们前端最爱“造轮子”。动不动就整个新框架、新库，还嫌不够乱？搞得技术栈更新的比我换衣服都快。别再折腾了，学点有用的东西不好吗？

哦，对了，还有人说 HTML/CSS/JS 不适合写 UI ？笑死人了，你们前端有什么不是基于这三样？你们的各种框架，各种库，不都是在 HTML/CSS/JS 这三个基础之上搭建起来的？

行了，吵够了吗？别整天没事找事，能不能干点正事？

wwwuser

4 天前

有人喜欢百家争鸣，有人喜欢大一统，所以，技术不停演进，各框架存在即合理

abcbuzhiming

4 天前

@june4
举例如下：

以 width 对 margin-left 的影响为例，假设有两个 div ，parent 和 child ，child 在 parent 里面，.parent 里面的 .child 宽度为 300px ，现在我给 child 添加一个 margin-left: -10px ，会发现整个 .child 左移 10 像素。好的，于是我们知道 margin-left: -10px 会让元素整体左移。

真的是这样吗？

这个时候把.child 的 width 去掉重新做实验。

就会发现 margin-left: -10px 并没有让整个元素左移，只是让左边缘左移了，右边缘并没有动。现在来总结一下：如果指定了 width ，那么 margin-left: 10px 会使元素整体左移如果没有指定 width ，那么 margin-left: 10px 只会使做边缘左移（也就是宽度扩大）

这就是非常典型的不正交：
* 为什么 width 的存在与否会影响 margin-left 的作用？
* 有没有 width 之外的其他属性也会影响 margin-left 的作用？还有哪些我不知道的会互相干涉的属性？

这就是不正交的恐怖之处，你只有把所有属性与 margin-left 一起用一下，才能得知 margin-left 的真正规律。

这还只是两个属性，如果更多的属性一起过来呢？

这些“不正交”的例子，需要一个个去记忆，各属性被影响的情况都不一样。
所以一直就有人说 CSS 不是编程，是“背表”，源头就在这。

现代基于 CSS 的 UI 已经很大程度把这些东西给屏蔽了，大部分时候，写 UI 只是在排列组合一个个的方盒子，确实比当初手写 CSS 容易很多。

但是这个“不正交”问题并没有被彻底埋葬，它就在那里，说不准啥时候就蹦出来。

其它的，类似 html + CSS 这样的“标记语言 UI 设计系统”，在样式问题上，基本都没有采取 CSS 这样的设计