图片是这个:
imgur.com/XiMulEC.jpg
来源是 jordwalke reactjs 作者:
x.com/jordwalke/status/1875336115009573268
本意是想调侃一下,没想到对这个事情的认知分歧竟然这么大……
这个问题可能和这两天火热的 Go 话题有点像,要可读性还是要生产力,还是做成年人?

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

  1. PHP
    PHP 是……默认就是 html ,加上<?php ?>就是模板。
  2. JSX
    像写 HMTL 一样!(之前的说法是“和”写 HTML 一样,被怼了之后改成“像”)
  3. Angular/Vue
    可读性好。
  4. Svelte
    逻辑与内容分离。

    这个推下面也吵起来了

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

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

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

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

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

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

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

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

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

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

vue 看着更舒服一点

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

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

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

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

go 话题是哪个?

#14
golang, 开发效率低执行效率高的语言? hesudu.com/t/1101972

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

jsx 容易写的乱吧。

没有分离,都混在一起。

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

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

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

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

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

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

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

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

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

吃瓜

个人从开发体验的角度来说,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 ,至少人家编译迭代快得多。

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

就算和 PHP 比也差了一大截

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

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

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

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

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

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

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

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

反正我投 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),]),

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

后端,看起来 2 > 3 > 1

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

HTML + CSS 本来是服务于排版的。HTML 只用来表达信息,而 CSS 赋予信息以样式,JS 则提供简单的交互和动态更新内容的能力。

  • HTML 是可以脱离 CSS 存在的:打开一个博客页面,文章内容都在 HTML 里,即使 CSS 完全没加载出来,用户也可以阅读文章内容;
  • HTML + CSS 又是可以脱离 JS 存在的:现在还有很多人认为网页就该脱离 JS 也能正常工作,比如这里的讨论: 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 。

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

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

当然是 iife + react

儿子像爸是吧,没有 react 哪来的 swiftui flutter compose

你是说 github 现状吗

React 的确是爸爸。

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

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

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

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

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

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

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

太赞同了

yyx:cnm ,听见了吗,cnm

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

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

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

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

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

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

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

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

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

要说清晰还得是 php

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

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

还是 PHP 好

#36 那咋办

#36 精辟

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

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

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

《可读性好》

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

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

#25 该评论涉及虚假广告

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

我还喜欢用"短路符代替 if 和 else",当然挺多人不赞同的, 不过在我代码经常使用。

if ($model->save()) {
 $this->handleOrder()
}

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

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

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

babel:
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 基础原理

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

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

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

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

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

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

一直写的 jsx ,也不喜欢三元,如果是 if else 这种都是 true &&

这种并列写,

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

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

基于 JSX 的灵活性,完全可以使用更加优雅的写法:
function Component(){
if(condition) return

Content
;
else if(other condition) return
OtherContent
;
else return
Fallback Content

}
或者:
function Component(){
const isFallback = !condition && !!otherCondition;
return(
<>
condition &&
Content

otherCondition &&
OtherContent

isFallback &&
Fallback Content

</>
)
}

不是前端, 我倒是觉得 jsx 的写法最好了(因为我觉得三元很易读)
1>2>3,
vue 那个完全看不懂,

我认为这就已经完成结束了, 后面的任何操作都跟它无关,后面又跟了一个
我的直觉是会都会渲染.

除非外面再包装一个类似这种.

其实就是越来越客户端 hhhhhhhh 而且 jsx 这种最外面是一个{}包括, 表示这是一整个代码段. 每个 condition 都用()包括也很容易区分整个边界. 我认为那位朋友没说错,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 设计的系统之间的阻尼。 期待 web 端有一天能来个革命,把 HTML/CSS/JS 抛弃用一个新的或者现有的语言,然后浏览器有新底层引擎能原生支持解析这个语言来渲染页面 >这个问题,其实就是基于排版设计的系统,和基于 UI 设计的系统之间的阻尼。 举几个具体例子?没觉得 CSS 和 UI 设计有什么不匹配。你要说以前没有 flex/grid 的时候,要用 float 甚至 table 来搞排版,那还勉强可以说是 CSS UI 排版不方便,但现在是什么时代。 嘿嘿,你看看 npm 包多么丰富: www.npmjs.com/package/is-thirteen 一个个菜得抠脚的码农在这评价,太经典了,就好像还没 1800 分的菜鸡指导小孩怎么打街霸一样。 个人最喜欢 github.com/hyperhype/hyperscript 纯粹用 js 生成 html 2016 年开始学 vue ,用了几年之后朋友推荐 react ,但是由于对 jsx 的语法偏见我学了几次又放弃了几次,因为实在是习惯了 vue 的简洁与易懂~ 直到 2024 年暑期,才开始强忍着把 react/redux/react-router 的官方文档全部看完,并用 react 改造了一个 vue3 的项目,整个耗时大概 4 个月~ 最后的感受就是,学下来之后 react 也没那么不容易接受,而且很多方面确实值得借鉴与学习,至少对于我来说又看到了一个不同的世界~ 人不要被偏见蒙蔽了双眼,去学习、去深挖,才能知道它好不好、是否合适,技术人员应该选择适合自己的~ 第一个图的图源是不是挂了,挂了代理也访问不了 JSX is similar to another extension syntax created by Facebook for PHP called XHP. 先做个预言,未来一定是组件化的; 随着产能的从量到精,大量开发人员会各司其职(甚至删减),不常用的自定义 UI component ; www.primefaces.org/ 会给到我们常用的; 前端娱乐圈??
谈谈数据安全和云存储

前些天,创新工场李开复同学在2012博鳌亚洲论坛表示: “你们有多少人丢过手机?大概有15%。你们有多少人数据放在微软掉过的?我想不见得很多吧。所以相对来说是安全的。放在大公司…

Javascript 装载和执行

一两个月前在淘宝内网里看到一个优化Javascript代码的竞赛,发现有不少的人对Javascript的执行和装载的基础并不懂,所以,从那天起我就想写一篇文章,但一直耽搁了。自…

如何做一个有质量的技术分享

分享信息并不难,大多数人都能做到,就算是不善言谈性格内向的技术人员,通过博客或社交媒体,或是不正式的交流,他们都能或多或少的做到。但是如果你想要做一个有质量有高度的分享,这个就…

programmer