debuggerx 最近的时间轴更新
debuggerx

debuggerx

V2EX 第 223488 号会员,加入于 2017-03-29 10:25:41 +08:00
屏蔽 V2EX 无聊的 AI 讨论的油猴脚本
分享发现  •  debuggerx  •  2023-02-20 13:21:49 PM  •  最后回复来自 debuggerx
4
不知是否火星,能科普下这个站是什么情况么
分享发现  •  debuggerx  •  2018-10-25 11:26:04 AM  •  最后回复来自 nullornull
7
debuggerx 最近回复了
前端转换,转好了再上传🐶

canvas.toDataURL(type, encoderOptions)
16 天前
回复了 itakeman 创建的主题 Linux Deb 系 Linux 没有 snap 的发行版有哪些?
deepin🐶
18 天前
回复了 idragonet 创建的主题 职场话题 说说自己带去办公室的设备
100 出头的三模 84 键机械键盘
30 块的 usb 鼠标
二手显示器当扩展屏
旧手机当系统资源监视器
mini 路由器把有线网转成热点给手机用
魔百盒用于跑 clash 给开发机提供代理服务
USB 风扇、制冷杯、铝制水杯、茶叶等……
19 天前
回复了 hillary666 创建的主题 酷工作 武汉 Linux 研发,加入我们,职等你来
@shawndev darwin 就是 mac ,这里都列的意思显然是说需要支持全平台,会 iOS 开发的可不一定会 mac 程序开发; HTTP/GRPC 都是封装好的协议,这个除外的意思显然不是说它过时,而是说工作需要直接做更底层一些的 Linux 网络编程,比如嵌套字、多路复用这些吧
20 天前
回复了 noisywolf 创建的主题 程序员 Linux 启动自己的 GUI 应用,不进桌面
如果是类似工控机点餐机那种,只需要开机打开一个图形应用然后点点点,那就直接 xinitrc 指定程序就行,参考:
https://wiki.archlinuxcn.org/wiki/Xinit#%E5%9C%A8%E6%B2%A1%E6%9C%89%E7%AA%97%E5%8F%A3%E7%AE%A1%E7%90%86%E5%99%A8%E7%9A%84%E6%83%85%E5%86%B5%E4%B8%8B%E5%90%AF%E5%8A%A8%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F

但是这种方式不适合自用,比如输入法就不好搞,建议还是起一个最简单的窗管,除了上面别人提到了的 i3wm 这种平铺式,还可以考虑 openbox 这种配置简单的堆叠式窗管
辨别错误和垃圾信息所花的时间精力提高了。
如果默认允许这样玩了,谁还下载 APP🐶
@flyqie 个人认为 react 是独立的前端概念形成以来,最伟大、影响最深远的前端思想。react 改变了前端开发的思路和模式,之后的各种 web 前端框架以及 flutter 乃至 swiftui ,compose 其实都是 react 思想的应用于特定场景和目的的产物。很多人可能不喜欢 react 而倾向于 vue 或者 svelte 等等,但其实更多的是工程上的区别,比如谁的 api 设计得更易用,谁在某些方面上的性能表现更出色,而不是“纯思想”上的对比。但是思想伟大并不意味着 react 在工程上也就无可挑剔,我用 js 写过 class 组件模式的纯 react 项目,也用 ts 做过 hooks 模式的,还写过不同版本的 next.js 和 taro ,虽然同是 react 系方案思想都一样,但其实开发体验差异是很大的,所以虽然我个人很推崇 react ,但是并不是很看好 rn 这种“在上层对齐各平台差异,底层使用原生组件”的跨平台模式。虽然我也很喜欢 ts 的语法,但是并不认为 js/ts 是足够适合跨平台的语言(原因看下面对 dart 的评价)
做跨平台,无外乎就是自绘和包装复用平台组件这两种模式,基于 web 的跨平台方案比如 electron 或者 webview2 ,其实本质也可以认为是利用浏览器内核做的“自绘”,但相比于 flutter/qt 的那种自绘要重得多。复用平台组件的模式一定会存在渲染不一致,依赖真机环境调试验证,框架和应用代码中存在大量判断分支,某个平台增加新特性或组件后需要持续适配投入大量精力的问题,这些是原理上难以避免的,反倒是很多人以为的性能问题,其实并不是那么的无解。所以一开始了解 flutter 是自绘的方案,我就认为这是一个加分项,一是其表现力的“上限”更高,二是由于自绘所依赖的底层相对都很稳定(比如 opengl ,canvas 这些东西),所以其本身也可以更加稳健,无需经常被平台牵着鼻子走,有问题持续优化总会越来越好。
我写过十好几种语言,dart 是我目前为止最喜欢的语言。除去个人喜好,客观来说 dart 其实是一门很适合跨平台的语言,首先是它原生支持 jit 和 aot ,分别可以实现前端开发时即时生效,边写代码边看效果(也就是所谓 hot reload 或者 live edit)的高效开发(比 java,oc,qt 这些强),以及在各个平台上无需虚拟机和复杂依赖而高效地运行(比 js/ts 这些需要解释器和 swift,kotlin 跨平台运行难度高的强)。再来这门语言的语法总的来说相当平庸(褒义),但凡了解过 java,js,python 等主流语言就可以很快上手,而且吸收了各种现代的语法特性,取得了开发效率和学习难度之间的平衡(比 go,rust 等特立独行的好掌握,比 kotlin 这种语法糖多到腻的简单),相对比较简单的语法特性也让它的 sdk 跨平台维护的成本较低,现在可以直接同时 compile 到 native binary 和 js 的语言就不多。很多人受不了 dart/flutter 的点无外乎是所谓的“嵌套”,我觉得主要是两点,一个是没有认识到 UI 的本质其实就是嵌套,用嵌套来表达 UI 其实才是最高效且接近本质的方式,再来就是被原生和 web 开发 UI 描述和逻辑分离的固有模式束缚,内心里抵触把整个 UI 应用抽象成“UI=fn(state)”这样统一的模型。其实 jsx 也是“ui in js”的方案,react 有段时间也推崇过“css in js”乃至“all in js”(个人认为它们没有普及成功更多是因为 js 本身的能力问题以及相关工具链没跟上导致的),可以认为 flutter 就是实现了终极版的“all in dart”,是一种 react 在跨平台领域的完全进化体。
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   848 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 22ms · UTC 21:21 · PVG 05:21 · LAX 14:21 · JFK 17:21
Developed with CodeLauncher
♥ Do have faith in what you're doing.