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

4 天前
 kuanat

图片是这个:

https://imgur.com/XiMulEC.jpg

来源是 jordwalke reactjs 作者:

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

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

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

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

<div v-if="condition">
Content
这里可以有很多 div ,很容易看错哪个是条件结束的 div
</div>
多个条件之间也可以插入很多 div ,够乱的
<div v-else-if="condition">
Other Content
</div>
Ocyss
4 天前
在 Vue 里面写 tsx 也行呀,比如一些递归或者复杂的就用 tsx 来写了,比如用 NaiveUI 框架有些组件支持传渲染函数,那当然写 tsx 最好看而不是写 h 函数,然后在配合 tailwindcss 基本上就只用看 script 和 template 两个框
shadowyue
4 天前
@X_Del #36
不同意你的观点,HTML+CSS 与 JS 应该分开来讨论。
我觉得 HTML+CSS ,目前来说,这种方式是写 UI 界面的最佳选择。
简单快速易上手,讲求效率的今天,没有更好的方案了,不然也不会有 Electron 的流行,
哪怕是其它原生的应用开发,我认为界面开发的方式也会朝这模式靠拢,例如安卓的 xml, JavaFX 中也能用 css 。
用声明式语法来写界面一定是大势所趋,
这就是当前开发人员能找到的最佳的 UI 写作方式。
最后是交互问题,我觉得在 web 端,交互的处理有部分代码写在 html 中更多的是习惯问题,
其实现在已经完全可以在 js 中处理交互,保持 html 的纯净。
交互过程中,无法避免需要去修改 HTML 和 CSS ,这不得不使得 JS 必须拥有能够编写界面的能力,这才是混乱的根源。
然而这种模式就是现在能找到的最佳银弹了。
你说不适合写 UI ,这我完全无法同意,你找不到更合适的 UI 写作办法,别的形式只会吵的更多。
dufu1991
4 天前
看来做前端的大家都很无聊
3382410
3 天前
php 是世界上....
abcbuzhiming
3 天前
@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
3 天前
@abcbuzhiming 你说的正交是指啥?选择器类名选错了节点选到别的组件里去了? css 类名类似语言的全局变量,当然也需要一个规范,远的有 BEM 之类的方案可以完全避免这种, 现在流行的 css-in-js 和 tailwindcss 也没这种问题。这不是 css 的问题。
kcross
3 天前
我选 vue  
前端想怎么写就怎么写关我啥事呢?

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1102700

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX