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

[kuanat]

图片是这个：

https://imgur.com/XiMulEC.jpg

来源是 jordwalke reactjs 作者：

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

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

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

我大概总结了一下群里四个流派的意见，只说优点：

1. PHP
PHP 是……默认就是 html ，加上<?php ?>就是模板。

2. JSX
像写 HMTL 一样！（之前的说法是“和”写 HTML 一样，被怼了之后改成“像”）

3. Angular/Vue
可读性好。

4. Svelte
逻辑与内容分离。

[bojackhorseman]

这个推下面也吵起来了

[Mr54]

如果代码是给人看的，那我感觉还是可读性重要一点，反正屎山都那么多了，也不差我这一坨，能跑就行

[xujinkai]

可读性也是生产力的一部分

[MossFox]

定义新语法对我这种记性差的不是很适合，所以我用 1 。

不过我自己做前端现在是纯娱乐。如果是吃饭的家伙，能有饭吃就是好东西。

[MYDB]

得分环境吧，如果是共同协作，还是可读性，如果就你一个人负责这一块，性能以及减少代码量更好

[MYDB]

感觉又要“吵”起来了，手动狗头

[k9982874]

前端还在吵的时候其它体系已经在“fuck xxx”了

[MossFox]

JSX 那个如果有没写过的伙计觉得是挺简洁的话，这个地方是啥都能塞的，比如你也可以这样美丽地把啥玩意都塞在这一块：

{(() => {
​ if (...) {
​ return <Box>{...}</Box>
​ }
​ return <>{["114", "514"].map((v, i) => <span key={i}>{v}</span>)}</>
})()}

这个的好处就是，JS 是啥样它就是啥样。
坏处也是 JS 是啥样它就是啥样。

[jinsp]

vue 看着更舒服一点

[X_Del]

很多人不喜欢 JSX ，因为不喜欢在 JS 里写 HTML 。
其实 JSX 只是在 JS 里写 vdom tree 而已，只是长得像 HTML 。
svetle 和 vue 的这部分则是一种模版语言。他们在这个方向上的竞争对手应该是 ejs ，handlerbars 和 jade 。

[leelotov2er]

@X_Del 你这就属于玩文字游戏了，对讨论问题本身没任何意义，不管你把写 jsx 叫写啥，改变了不了它的缺点

[darksheen]

吃瓜路过。公司要用哪个就学哪个，没选择权

[crysislinux]

论出活儿的话还得是 angular ，vue 这种模板来的快，下限也比 jsx 高一些。我们项目里很多 angular 大模板，写成 jsx 得乱的多。

[wzy44944]

go 话题是哪个？

[kuanat]

@wzy44944 #14

golang, 开发效率低执行效率高的语言? https://v2ex.com/t/1101972

[kuanat]

作为吃瓜群众我不理解的是 reactjs 的作者竟然认为，在控制流中使用嵌套三元操作是合理且应当大力推广的。

[flyqie]

jsx 容易写的乱吧。

没有分离，都混在一起。

这点上 vue 什么的就好很多，分离开比较方便开发。

[mizuhashi]

如果非要寫 jsx ，我會選擇 coffeescript/imba

[learnshare]

以前，HTML/JS/CSS 讲究尽量分离
现在，JSX/Tailwind 让你每天八宝粥喝到饱

[96]

前端的朋友是我见过最爱造轮子的开发。放个屁都得打包发到 npmjs 上。

[Nyeshuai]

尽量不创语法贴近语言 JSX 已经是最优解，也是唯一被 TS 官方支持的，这下真能说 React 就是 JS 了。上下限问题确实，还是看人，是真有很多 low 货模版里就地重复 storage get 和 大段计算不觉得难看的。喜欢 tag 打头的封下组件就好，<ToggleView when={...} />

[XCFOX]

JSX 已经赢了，Vue 支持 JSX ，TypeScript 天然支持 JSX ，后来的前端框架 SolidJS 、Qwik 都直接使用 JSX 作为描述 View 的方案。

在组件化时代，应该以组件为单位做分离。组件内部将逻辑(JS)、视图(HTML)和样式(CSS)写到一起对开发效率有非常大的提升。JSX 允许在 JS 里描述视图，Tailwind 和 css-in-js 允许在 JS 里直接写样式。

[angrylid]

仿佛争论生化垃圾和核废料哪种危害性更大，令人忍俊不禁。就这些完蛋玩意儿跟 SwiftUI 之间不知道隔了几个 Flutter

不过就实际开发来说，JSX 是最容易写成三角地狱，幸亏这破烂语言不需要游标卡尺也能跑。

[abc0123xyz]

吃瓜

[LaTero]

个人从开发体验的角度来说，HTML/CSS/JS 分离不过是 CSS 和 JS 出现得比较晚，用组件分离才是正确逻辑。现在有些所谓”separation of concern“就是单纯为了分离而分离，不考虑分离到底有什么益处（因为并没有），比如 Unity 的 UI Toolkit ，2024 年的”声明式“（自称，实际只是用了声明式的 markup 语言描述布局，data-binding 并不声明式，还是"Object Oriented Programming Architecture Design Patterns Model View ViewModel Separation of Concern“那一套巨啰嗦的传统 binding ）框架居然还在搞什么 uxml ，uss ，C#脚本分离，开发体验并不好，甚至还不如 WPF 和 QML ，至少人家编译迭代快得多。

[nomagick]

前端这几个框架，只有 Angular 稍微有那么一点点可读性，其他的都是灾难
只配和 PHP 比

就算和 PHP 比也差了一大截

[nomagick]

比啥不好非要比可读性可维护性

前端根本谈不上可读性可维护性，哪个页面是多人维护持续开发的，哪次不是换新人来新设计就重新写
为零，真的为零

[SoyaDokio]

jsx 这种 js 里面写 html/vdom 的，跟当年 java 里写 html 的 jsp 有什么本质差异？

[Dynesshely]

@angrylid 对的, 说到底这种要把多种语言体系混在一起写的都是垃圾
要么就像 dotnet 生态里 wpf 和 avalonia 那样把后台和前台分开, 一个 C# 一个 xaml / axaml
要么就像 swift / flutter 那样 UI 和语言是一个体系的, 不需要介入什么 html, css 这些挂件

[DOLLOR]

@SoyaDokio
jsp 只是纯纯的 string ，不具备 event 和各种 DOM 方法。

[paopjian]

jsx 要是没有那个小括号,我觉得还算可以, svelte 至少一行一个指令,vue 就当写 html 了, 可 jsx 这又是花括号又是小括号的

[darkengine]

我在 JSX 里会把这坨东西封装个函数，在函数里 if (condition) 短路返回第一坨 html ，再 if (otherCondition)短路返回第二坨 html ，最后返回一个兜底的第三坨 html 。

毕竟是个需要自己长期维护的项目，方便读懂才是王道。

[zhengfan2016]

反正我投 jsx/template/html 一票，flutter 这种括号地狱的语言才是配进垃圾桶的那个。我写过类似的前端框架 mithril ，层层括号，行数上来了可读性就是屎。

m('div',{ class: 'flex flex-row items-center space-x-4' }, [m('img', {class: 'w-12 h-12 rounded-full',src: props.avatar,}),m('div', { class: 'text-lg font-medium text-gray-800 flex-1' }, props.username),])，

[zpf124]

作为一个后端，看着.svelte 最顺眼

[wolfie]

后端，看起来 2 > 3 > 1

[X_Del]

某种意义上，此争论的根源之一是：HTML / CSS / JS 并不适合写 UI 。

HTML + CSS 本来是服务于排版的。HTML 只用来表达信息，而 CSS 赋予信息以样式，JS 则提供简单的交互和动态更新内容的能力。
- HTML 是可以脱离 CSS 存在的：打开一个博客页面，文章内容都在 HTML 里，即使 CSS 完全没加载出来，用户也可以阅读文章内容；
- HTML + CSS 又是可以脱离 JS 存在的：现在还有很多人认为网页就该脱离 JS 也能正常工作，比如这里的讨论： https://news.ycombinator.com/item?id=33212448 。
早期的互联网上，网站以门户网站、博客、论坛等形式为主，这一套可以说非常成功。网站就是一篇文章，文章的内容、文章的样式、文章的交互，就该是解耦的，用三种语言很自然。

但前端开发者面对的问题今非昔比，如今我们要开发的，不再是门户网站、博客和论坛，而是各种富交互的“应用程序”。前端开发与桌面 / 移动端 UI 开发越来越像，这要求我们的工具也越来越像 UI 开发工具。这时的 HTML / CSS / JS ，就有点不太够用了。

UI 开发与网页开发有着根本的不同：数据 / 样式 / 交互的解耦不再有意义。在一个应用程序中，应用被分成一个个 UI component ，而一个 UI component ，就该是 self contained 的。习惯于三件套老前端们也许不会有这样的疑问，但为什么写一个 button 需要切换三种语言？ button 的 label 写在 HTML 里，button 的颜色写在 CSS 里，button 绑定的事件则要写在 JS 里？

新的需求出现了，我们理应有新的工具。我们本可以开发一样新的技术替代 HTML / CSS / JS ，最终产物可能像是属于 Web 的 Swift UI 或者 Flutter 。但阴差阳错，最终的结果是 JS 一桶浆糊：我们有了 JSX 和 CSS-in-JS 。

回到开头，HTML / CSS / JS 并不适合写 UI ，但 Web 开发无法抛弃 HTML / CSS / JS ，最终我们不得不以某种形式在 JS 里写 HTML ，无论是 vue 还是 JSX 。

这种以 JS 强兼 HTML 的方式总是有某种代价（ SEO 、性能等），我们又搞出了各种技术来擦屁股：比如 SSR 和各种 zero-runtime CSS-in-JS 。

[X_Del]

Bonus：实在讨厌嵌套三元表达式的话，还有这种东西： https://github.com/romac/react-if

[dccif]

前端开发大部分不需要所谓的可维护性，可读性，动不动就变，大部分一次性代码的东西。当然是怎么快怎么来，jsx 最快，所以 jsx 已经赢了。
现代前端界面代码就那么点东西，还在为了可读性而可读性，感觉是方向错了

[Leviathann]

当然是 iife + react

[Leviathann]

@X_Del 儿子像爸是吧，没有 react 哪来的 swiftui flutter compose

[asdfsadfsdf]

@96 你是说 github 现状吗

[X_Del]

@Leviathann React 的确是爸爸。

[june4]

楼上竟然有人说 HTML / CSS / JS 并不适合写 UI🐶
这套写 UI 只有一个缺点，性能没有原生高，其它在灵活性可调试性所有方面秒杀各种原生方案。

[visper]

当从美观可读来说，vue 完胜。整洁一点，看起来就和 html 差不了多少。当然灵活性就差 jsx 一点了。

[marcong95]

就这个图而言，在 react 没火之前下面两种类型的形式才是真 template syntax 吧，react 火了连 template syntax 的名字都要抢走了么。糊三元运算符这种虽然理解是可以理解，但是我觉得这才算 mental illnesses 吧。。。。

[TimPeake]

@96 你还在真别说，我记得 npm 上有个包，就几行代码，好像上百万的下载量？

[Justin13]

我倒是觉得三件套是最合适写 UI
因为其他的语言也好，框架也好，也是逃不脱这三样，一样有组件，样式，逻辑
无非是默认分离罢了，如果你喜欢一样有 jsx,css-in-js 给你选
最烦的就是强迫一种范式全堆一块写所有，等你遇到巨大屎山，就会想起分离的好了

[AlexHsu]

@june4 浏览器技术什么都在写 ui 不是说他有多好 是 ui 圈的技术已经烂透了

[wangxiaoer]

@SoyaDokio 没有本质区别，就是一坨黑色巧克力。

[dylanqqt]

@96 太赞同了

[bojackhorseman]

yyx：cnm ，听见了吗，cnm

[ChefIsAwesome]

react 里，jsx 写的 component 可以当变量，可以传到函数里当参数，可以 return 。
类似的还有 js 里的 promise ，一个还没发生的事情，可以赋值给变量，可以当参数。
js 里的函数，也是如此，即所谓的 first class 。
这种抽象方法，能帮助你更容易的做拆分组合，才是上面几种方法的亮点。讨论模板 if else 怎么写，真的是不得其要领，浪费了 react 这么好的工具。

[chandlerbing9317]

后端，感觉 vue 直观很多，好维护很多

[hxtheone]

不管是不是写模板, 三元表达式套三元表达式都是纯纯的 mental illness

[iv8d]

在 JS 里写 HTML 没人觉得奇怪吗，感觉还是``包裹起来比较合适

[geekris1]

@TimPeake isarray 这个包 5.4kw/week 下载量 本身一共才五行代码 而且现在很多浏览器都支持 但是有最底层的库用这个包 所以 download 飞起

[abc1310054026]

结论：看场景使用。高复杂度用 jsx ，低复杂度用模版语法。

jsx 和 svelte ，vue 的模版语法都不一样，前者基于 js ，而后两者基于 html 。

由于 js 天然的可编程性，jsx 方案在复杂度较大的场景具有更好的可读性。
而 html 天然的可读性，svelte ，vue 方案在简单场景更合适。

目前同时支持 jsx 和 模版语法的似乎只有 vue ？

[lambdaq]

要说清晰还得是 php

[chanChristin]

@iv8d 写多了就还好，如果用``包裹的话编辑器着色和提示会有问题。

[cenbiq]

对我来说，JSX > Vue > Svelte ，JSX 给我一种很自然的感觉

[jackerbauer]

还是 PHP 好

[gefangshuai]

@X_Del #36 那咋办

[lekai63]

@X_Del #36 精辟

[tool2dx]

@iv8d “在 JS 里写 HTML 没人觉得奇怪吗"

不奇怪。自从 js 被发明出来的那一天起，大家都用 js 来拼接 html 。

[hahastudio]

难道不都是 mental illness
三元连用本身就是个问题
第二个还行
第三个 condition 要 escape 的

[wangyzj]

《可读性好》

[DICK23]

不知道有啥好吵的。。。vue 也支持 jsx 啊，svelte 就是模版语法也没任何毛病

[chairuosen]

我写 vue 多，但我支持 jsx ，有时候做复杂的 dom 切换 vue 的模板真不好用。比如不同状态时叶子节点的 dom 可以复用但是 wrapper 节点结构不能复用，jsx 定义一个变量即可，但是 vue 得把叶子节点重复写一遍

[mcfog]

#25 该评论涉及虚假广告 @Livid

[lyxxxh2]

vue 最易读,最简洁的是 react,所以就是说,请选择你的口味: ["简洁","易读"],我选择"简洁"。
像图中 react 这种三元,我也是经常用的。 虽然图中三个分支,我还是站 react 。
2 个分支: 三元
3 个分支: if 和三元都行
4+个分支: 三元不能用了,人脑很难解压出逻辑。


我还喜欢用"短路符代替 if 和 else",当然挺多人不赞同的, 不过在我代码经常使用。
```
if ($model->save()) {
$this->handleOrder()
}

$model->save() && $this->handleOrder();
```

[DefectingCat]

jsx 是有所抛弃的。vue svelte 的模版语法都会有个编译阶段，而 jsx 只有 babel 转了下写法而已。实际上的函数式组件真的是纯粹的函数。

函数传参时写不了表达式，就和在 jsx 中用不了 for 循环一个道理。

babel:
https://babeljs.io/repl#?browsers=defaults%2C%20not%20ie%2011%2C%20not%20ie_mob%2011&build=&builtIns=false&corejs=3.21&spec=false&loose=false&code_lz=MYewdgzgLgBAwiAtgB3AUzLAvDAFAShiwD4YBvAKBhgCc0oBXGsGAHmLNDABMBLKXuBgB-NnwBuxVgHoJpAFxjekmXIC-M4gG4KanUA&debug=false&forceAllTransforms=false&modules=false&shippedProposals=false&evaluate=false&fileSize=true&timeTravel=false&sourceType=module&lineWrap=true&presets=env%2Creact%2Cstage-3%2Ctypescript&prettier=false&targets=&version=7.26.4&externalPlugins=&assumptions=%7B%7D

有人说 vue 模版有黑魔法，同理在 vue 中用了 jsx 也就享受不到提前编译带来的优化了。本质上就是个选择题，和选择是用 vue 还是用 react 是一个道理。

争这个不如多看看 js 基础原理

[lawted]

人怎么写，喜欢怎么写不重要，重要的是 AI 最会写哪个

[Torpedo]

不太喜欢模板语法。模板语法的问题在于能力太弱了。表象之一就是你都不知道有多少种模板语法。vue 、php 、Mustache 、jade 等等。这些模板语法第一眼看上去很像，但是遇到逻辑的时候，都会设计自己的一套东西。
面对一些复杂的逻辑，就会遇到很多困难，或者写出来很复杂的代码。

当然这些语法也是有优势的。特别是展示类型的页面。用这种语法可以方便的 ssr ，无论 seo 、首屏性能都有优势。

但是复杂逻辑就不太行了。这也是为什么 jsx 流行的原因。毕竟现在 web 开发的交互越来越复杂。

jsx 好就好在不同的 jsx 区别不太大，构建工具、编辑器支持了一种 jsx 的构建、智能提示就很容易支持多种。不同框架的 jsx 区别主要还是在响应式实现那里。jsx 本身倒是大同小异。

[981130508]

甜豆浆好吃还是咸豆浆好吃？

[dudubaba]

一直写的 jsx ，也不喜欢三元，如果是 if else 这种都是 true && <div></div> 这种并列写，

[gongquanlin]

写 vue 的时候一会儿往上找样式，一会儿跑到下面找 script ，难受的很；

[geekris1]

@hahastudio 说句不好听的 这本身就是黑 jsx 的 jsx 难道就不能写 if else 了吗 非得给 jsx 用嵌套三元 其他写 if else....

[oliveira]

基于 JSX 的灵活性，完全可以使用更加优雅的写法：
function Component(){
if(condition) return <div>Content</div>;
else if(other condition) return <div>OtherContent</div>;
else return <div>Fallback Content</div>
}
或者：
function Component(){
const isFallback = !condition && !!otherCondition;
return(
<>
condition && <div>Content</div>
otherCondition && <div>OtherContent</div>
isFallback && <div>Fallback Content</div>
</>
)
}

[vvtf]

不是前端, 我倒是觉得 jsx 的写法最好了(因为我觉得三元很易读)
1>2>3,
vue 那个完全看不懂,
<div></div>我认为这就已经完成结束了, 后面的任何操作都跟它无关,后面又跟了一个<div></div>我的直觉是会都会渲染.
除非外面再包装一个类似这种.
<v-condition>
<div v-if />
<div v-else-if />
<div v-else>
</v-condition>

[xing7673]

@XCFOX 其实就是越来越客户端 hhhhhhhh

[vvtf]

而且 jsx 这种最外面是一个{}包括, 表示这是一整个代码段.
每个 condition 都用()包括也很容易区分整个边界.

[abcbuzhiming]

@june4
我认为那位朋友没说错，HTML / CSS / JS 就是不适合写 UI 。而且理由人家也说的很清楚了，UI 应该以组件为单位，但是现实里我们写一个 UI 组件却需要再三种语言里切换（而且是三种思路完全不同的语言），这会带来巨大的心智负担。

最早说 Web 这套逻辑适合开发 UI 的，是因为 UI 界有个观点，认为“标记型语言”是最适合描述 UI 的，而 Html 刚好是标记型语言。所以 UI 界才开始注意到 web 这个东西的 UI 潜力。但是偏偏 CSS 这个东西，它不是为 UI 设计的，它是为排版设计的，排版的需求和 UI 的需求，只能说有交集，不能说完全匹配，所以你如果用 CSS 去做 UI 的话，总会被 CSS 里为排版设计但不是为了 UI 设计的那部分特性干扰。很多人对 CSS 的畏惧就来自于此，这东西并不是为 UI 开发的。

相比而言，性能反而不是最重要的问题，毕竟不是所有领域的 UI 都对性能有较高要求。

HTML / CSS / JS 这套，从 2000 年左右开始，一直到现在，不断变革，不断翻来覆去大家吵架，已经 20 年了，大家还是没争吵出个最佳实践来。而争吵的业务在什么领域呢？就是 UI 。单纯的没有交互的排版页面大家反而没争议。这恰恰说明了，这套东西基础层面上有问题，以至于大家反复的在实践上翻烧饼。这个问题，其实就是基于排版设计的系统，和基于 UI 设计的系统之间的阻尼。

[caocong]

期待 web 端有一天能来个革命，把 HTML/CSS/JS 抛弃用一个新的或者现有的语言，然后浏览器有新底层引擎能原生支持解析这个语言来渲染页面

[june4]

@abcbuzhiming >这个问题，其实就是基于排版设计的系统，和基于 UI 设计的系统之间的阻尼。
举几个具体例子？没觉得 CSS 和 UI 设计有什么不匹配。你要说以前没有 flex/grid 的时候，要用 float 甚至 table 来搞排版，那还勉强可以说是 CSS UI 排版不方便，但现在是什么时代。

[jevonszmx]

@96 嘿嘿，你看看 npm 包多么丰富： https://www.npmjs.com/package/is-thirteen

[coderlxm]

一个个菜得抠脚的码农在这评价，太经典了，就好像还没 1800 分的菜鸡指导小孩怎么打街霸一样。

[henix]

个人最喜欢 https://github.com/hyperhype/hyperscript 纯粹用 js 生成 html

[julio867]

2016 年开始学 vue ，用了几年之后朋友推荐 react ，但是由于对 jsx 的语法偏见我学了几次又放弃了几次，因为实在是习惯了 vue 的简洁与易懂~
直到 2024 年暑期，才开始强忍着把 react/redux/react-router 的官方文档全部看完，并用 react 改造了一个 vue3 的项目，整个耗时大概 4 个月~
最后的感受就是，学下来之后 react 也没那么不容易接受，而且很多方面确实值得借鉴与学习，至少对于我来说又看到了一个不同的世界~
人不要被偏见蒙蔽了双眼，去学习、去深挖，才能知道它好不好、是否合适，技术人员应该选择适合自己的~

[Lockroach]

第一个图的图源是不是挂了，挂了代理也访问不了

[ben1024]

JSX is similar to another extension syntax created by Facebook for PHP called XHP.

[526326991]

先做个预言，未来一定是组件化的；
随着产能的从量到精，大量开发人员会各司其职（甚至删减），不常用的自定义 UI component ；
https://www.primefaces.org/ 会给到我们常用的；

[guanhui07]

前端娱乐圈？？

[hutoer]

单看这张图，我觉得 Vue 是设计的最差的

<div v-if="condition">
Content
这里可以有很多 div ，很容易看错哪个是条件结束的 div
</div>
多个条件之间也可以插入很多 div ，够乱的
<div v-else-if="condition">
Other Content
</div>

[Ocyss]

在 Vue 里面写 tsx 也行呀，比如一些递归或者复杂的就用 tsx 来写了，比如用 NaiveUI 框架有些组件支持传渲染函数，那当然写 tsx 最好看而不是写 h 函数，然后在配合 tailwindcss 基本上就只用看 script 和 template 两个框

[shadowyue]

@X_Del #36
不同意你的观点，HTML+CSS 与 JS 应该分开来讨论。
我觉得 HTML+CSS ，目前来说，这种方式是写 UI 界面的最佳选择。
简单快速易上手，讲求效率的今天，没有更好的方案了，不然也不会有 Electron 的流行，
哪怕是其它原生的应用开发，我认为界面开发的方式也会朝这模式靠拢，例如安卓的 xml, JavaFX 中也能用 css 。
用声明式语法来写界面一定是大势所趋，
这就是当前开发人员能找到的最佳的 UI 写作方式。
最后是交互问题，我觉得在 web 端，交互的处理有部分代码写在 html 中更多的是习惯问题，
其实现在已经完全可以在 js 中处理交互，保持 html 的纯净。
交互过程中，无法避免需要去修改 HTML 和 CSS ，这不得不使得 JS 必须拥有能够编写界面的能力，这才是混乱的根源。
然而这种模式就是现在能找到的最佳银弹了。
你说不适合写 UI ，这我完全无法同意，你找不到更合适的 UI 写作办法，别的形式只会吵的更多。

[dufu1991]

看来做前端的大家都很无聊

[3382410]

php 是世界上....

[abcbuzhiming]

@june4
最大的问题在于 CSS 自己的设计思路，它不是个“正交系统”。所谓正交系统，你改变 A 条件，它应该只产生 A 结果；但 CSS 不是这样，CSS 改变 A 条件，会引发 B 条件联动改变，从而影响出 B 结果。

这是 CSS 让很多人觉得难以掌握的根本原因。CSS 最初的设计者是为了让这个东西更符合设计者直觉，而编程人员的直觉则更强调逻辑直觉。所以长久以来，编程界就有相当一部分人觉得 CSS 难以学习，而另外相当的一部分人觉得 CSS 有什么难的？就是因为这种思维模式的阻尼。

后来 CSS 确实加了一些专门为 UI 设计的布局，比如你说的 flex/grid, 但是 CSS 本身不正交这个问题，一直拖累 CSS 的 UI 编程。
如果你观察过其它的，“类标记语言 UI 设计系统”，诸如 WPF ，它们确实搞的很像 Html + CSS ，但是它们都极度的让自己的系统正交，避免出现 CSS 这种“明明改的是 A 怎么 B 跟着跑？”这类问题。

样式表描述界面是个很好的想法，完全可以用于 UI ，但是 CSS 本身的不正交设计，让这东西用于 UI ，在编程开发者看来痛苦万分，所以才出现了如此多的诸如 bootstrap 这样试图屏蔽 CSS 不正交问题的方案。

[june4]

@abcbuzhiming 你说的正交是指啥？选择器类名选错了节点选到别的组件里去了？ css 类名类似语言的全局变量，当然也需要一个规范，远的有 BEM 之类的方案可以完全避免这种， 现在流行的 css-in-js 和 tailwindcss 也没这种问题。这不是 css 的问题。

[kcross]

我选 vue 　
前端想怎么写就怎么写关我啥事呢？