我转发了一张图到前端群,大周末的群里已经爆炸了
图片是这个:
imgur.com/XiMulEC.jpg
来源是 jordwalke reactjs 作者:
x.com/jordwalke/status/1875336115009573268
本意是想调侃一下,没想到对这个事情的认知分歧竟然这么大……
这个问题可能和这两天火热的 Go 话题有点像,要可读性还是要生产力,还是做成年人?
我大概总结了一下群里四个流派的意见,只说优点:
- PHP
PHP 是……默认就是 html ,加上<?php ?>就是模板。 - JSX
像写 HMTL 一样!(之前的说法是“和”写 HTML 一样,被怼了之后改成“像”) - Angular/Vue
可读性好。 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
else if(other condition) return
else return
}
或者:
function Component(){
const isFallback = !condition && !!otherCondition;
return(
<>
condition &&
otherCondition &&
isFallback &&
</>
)
}
不是前端, 我倒是觉得 jsx 的写法最好了(因为我觉得三元很易读)
1>2>3,
vue 那个完全看不懂,
除非外面再包装一个类似这种.
前些天,创新工场李开复同学在2012博鳌亚洲论坛表示: “你们有多少人丢过手机?大概有15%。你们有多少人数据放在微软掉过的?我想不见得很多吧。所以相对来说是安全的。放在大公司…
一两个月前在淘宝内网里看到一个优化Javascript代码的竞赛,发现有不少的人对Javascript的执行和装载的基础并不懂,所以,从那天起我就想写一篇文章,但一直耽搁了。自…
分享信息并不难,大多数人都能做到,就算是不善言谈性格内向的技术人员,通过博客或社交媒体,或是不正式的交流,他们都能或多或少的做到。但是如果你想要做一个有质量有高度的分享,这个就…