呜啦!日常碎碎念,偶尔掉落优质前端博文推荐、学习资源等
网页:https://tg.cosine.ren
本频道的搜索Bot 来辣 👉 @cosSearchBot
私聊直接发消息就可以搜索啦~
🔖tags
#优质博文 #资源推荐 #博客更新 #碎碎念 #项目更新 #手工 #书摘 #阮一峰的科技周刊 #新动态

图频:Cosine 🎨 Gallery @CosineGallery
猫片: @cosine_cat
#优质博文 #前端 #react #工程化
How to start a React Project [2025]
AI 摘要:Robin Wieruch 在本文中概述了 2025 年启动 React 项目的三种主要方式,并分析了各自的优缺点,以帮助开发者根据需求选择合适的方案。

1. React + Vite (适合学习者和轻量级 SPA 开发)
- 优势 :Vite 是 create-react-app (CRA) 的轻量级替代方案,构建速度快,支持 SPA/CSR,可选 SSR,无框架束缚,适合学习 React 本身。
- 劣势 :默认以 SPA/CSR 为主,不提供内置架构,需自行选择路由、状态管理等库。

2. React + Next.js (适合全栈开发和企业级应用)
- 优势 :提供 SSR、SSG、ISR、CSR 等多种渲染模式,支持 React Server Components (RSC) 和 React Server Functions (RSF),可构建完整的前后端一体化应用,内置 SEO 和优化功能。
- 劣势 :学习曲线陡峭,框架更新快,需适应 Next.js 的特定模式和变化。

3. React + Astro (适合内容驱动型网站)
- 优势 :基于 MPA(多页应用)架构,默认高性能,支持 SEO,采用“岛屿架构”实现选择性水合,适用于博客、文档等内容型网站。
- 劣势 :不适用于动态 Web 应用,但官方正在探索此方向。

此外,文章还提及了 React Native + Expo(移动端)、Tauri/Electron(桌面端)、Monorepo(Turborepo 组织多个框架) 以及 Vue/Svelte/Solid/Qwik 等其他方案。

推荐选择
- 初学者或轻量级 SPA :Vite + React
- 全栈应用或企业级开发 :Next.js + React
- 内容型网站 :Astro + React
- 不适合 Next.js,但需要 SSR 框架 :可考虑 TanStack Start 或 React Router(框架模式)。


via Robin Wieruch How to start a React Project [2025]
#优质博文 #前端 #tools
1. CSS 的 backdrop-filter 属性(英文) 本文介绍 backdrop-filter 属性,可以产生毛玻璃的效果。 #css
backdrop-filter 是一个强大的 CSS 属性,它可以对元素后面的内容应用模糊、亮度调整等滤镜效果,从而创造出玻璃拟态(Glassmorphism)等视觉效果。文章介绍了 backdrop-filter 的基本用法,如 blur() 进行模糊处理,以及 brightness() 进行亮度调整。同时,作者强调了 backdrop-filter 仅影响元素背景,不会影响其自身内容。此外,文章探讨了浏览器兼容性问题,指出 Safari 早期支持较好,而部分浏览器(如 Firefox)需要启用实验性功能才能使用。最后,作者提供了示例代码,并建议开发者结合 background 颜色和 backdrop-filter 以获得最佳视觉效果。

2. 基于 signal 的 Web 组件(英文) #html #WebComponents
作者介绍自己写的一个 Web 组件,可以在不加其他 JS 库的情况下,实现 signal 功能。
本文探讨了在 HTML 中直接定义 信号(Signals) 的可能性,提出 <x-signal> 自定义元素,使其能够管理状态并自动更新 UI,而无需依赖 JavaScript 框架。该方法基于 HTML-based state 概念,直接从 HTML 解析初始值,并支持类型转换、动态渲染、自定义格式化及派生状态计算。最终,作者认为 <x-signal> 代表了一种更细粒度的 **Islets 架构**,在静态 HTML 中提供轻量级的响应式交互能力。

3. 鸿蒙 ArkTS VSCode 插件 #vscode #ArkTS #插件 #鸿蒙
ArkTS 是华为鸿蒙系统的开发语言,属于 TypeScript 的超集,这是它的 VSCode 插件。
4. RAG Web UI #AI #RAG
一个开源的 AI 桌面应用,可以上传文档,生成本地的知识库问答系统,基于 RAG(检索增强生成)技术。
5. TEN Agent #AI #agent #语音
一个 AI 的工具框架,快速打造语音相关的 AI 应用。
6. 富文本编辑器比较2025版(英文) #富文本 #编辑器
这个页面详细比较了 JS 的富文本"所见即所得"编辑器,一共十几个库,详细介绍每个库的特点
本文分析了主流的富文本编辑器框架,帮助开发者在 2025 年做出最佳选择。文章涵盖 Lexical、ProseMirror、Slate、Tiptap、Quill 等编辑器,并从 可扩展性、性能、易用性、社区支持 等方面进行了对比。
Lexical (Meta 开源):高性能、模块化、适合复杂应用,但生态仍在发展中。
ProseMirror :功能强大、灵活,但 API 复杂,入门门槛较高。
Slate :React 友好,完全可定制,但文档有限,维护情况不稳定。
Tiptap (基于 ProseMirror):提供更简洁的 API 和更好的 TypeScript 支持,适合现代 Web 应用。
Quill :易用,适合基本需求,但扩展性受限。
结论: 如果你需要高扩展性和现代化 API,Lexical Tiptap 是更好的选择;如果追求稳定和成熟方案, ProseMirror 仍然值得考虑。


via
#阮一峰的科技周刊 337
In the Mood for Love」线上展览入口(刚好今天晚上刚去看了「花样年华」重映,很应景)

https://www.yuloveboyi.com In the Mood for Love
#碎碎念
由于前任充电宝寿终正寝了
(不情不愿)(啊没有被逼的)(真心实意的)感谢妲喵的情人节礼物
#杂谈 #MyGO #AveMujica

尽可能客观评价一下mujica第七集,就当是个杂谈吧,各位如不认同,大可以发表自己的观点。

第六七集单拎出来,其实观感还不至于沦落到烂的程度,第七集主要的问题是:首先节奏炸糊,其次偷摸零全程跑调也很难绷;另一方面,allin的角色弧光给磨平了,已然沦为一般工具人的程度。

但事实是,不可能脱离整部作品(当然这里主要指的是MyGO和目前为止的Ave Mujica)去只评价其中一集。放到整部作品里,这部番事实上已经突破“高中少女乐队”的底线(或者说界限)了,没办法什么都靠所谓的大世界观兜底——这只会显得剧情发展很荒唐——实际上也是观感如此撕裂的原因之一。

从剧情内容上来说:和解的起点应该是“祥子主动给其他人道歉”,但是剧里和解的起点竟然是“别人无限包容祥子、原谅祥子”,这显而易见是不合理的。而且剧情中的回旋镖桥段看多了总有种刻意为之的违和感,玩一两次是神之一手,玩三五次姑且还算是好活,玩这么多只能说是烂活和没活。

从剧情的节奏上来说:前期积累的情感和人物关系似乎之用半集就处理掉了,这种过快且模糊的节奏极大地影响剧情的紧凑性和连续性。尤其是对比mygo和mujica,前者的节奏处理显然更加有力。

再说回第七集,不可避免地提到爱音和祥子,这里引用网友的评价:

爱音对待她们的态度和祥子对她们的态度天差地别。她们对祥子和爱音的态度也天差地别。
仔细想想。还真是。
祥子哪怕对朋友甩脸子冷言冷语,哪怕情绪失控说话特别冲整得高松灯自闭,哪怕看着素世都这样了还能说出“你满脑子都是自己”,哪怕看着发小都疯了也没关心。
但是,在编剧的大手下,依然能做到“不必正式道歉,唱两首歌就和解。”
成功做到包寿司了吗?成功了。
剧里的角色觉得这次“包寿司”好不好?好。
那剧外的观众觉得这个寿司好不好呢?
这就是另一个话题了。


作为观众,希望看到的是角色的成长,是角色能展现出自己的弧光(无论是“善”还是“恶”)。然而,第七集中,爱音用一个季度展现的人物弧光竟然在一集之内被磨平,已然沦为“圣母玛利亚”和尽职尽责工具人的叠加态。这何尝不是对MyGO的主题“迷子でもいい、迷子でも進め”的最大讽刺?

至于场外的杂七杂八,尤其是结合苦来兮苦三次元“复活”,这一切只能显得这集到底是多抽象。

另外关于“国内互联网害的”等言论,尽管B站的宣发确实存在问题,但这并不能完全解释为何一些观众对剧情不满。虽然剧集的核心是“16岁的小孩搞乐队”,但这并不意味着它的剧情和角色关系就可以随便处理,观众依然期望能够看到有深度、有层次的故事;而不是反过来给观众喂屎。文化差异确实可能影响对剧情的理解和评价,但是一个好的作品应该能够跨越这种差异,让观众无论身处何地都能感同身受。真要这么说的话,那MyGO当时还算是少有的“仅大陆好评(基本上是这样)”的作品。总的来说,你不能只在风评差的时候才说“都是国内互联网导致的”。

综上所述,我认为目前最大的两个问题一是节奏崩坏、二是世界观崩塌,这些能不能在后面的6集救回来虽犹未可知,但我也不抱太大期望。至于第七集,最大的问题就是它在第七集这个位置上,如果做成ova或者sp我都不认为会像现在这样烂穿地壳()
科技圈🎗在花频道📮
苹果与谷歌恢复TikTok上架

苹果和谷歌已恢复字节跳动旗下短视频应用TikTok在美国的应用商店上架。

彭博社
#碎碎念
我急了我急了,原来只有我是限定一天的受害人,我昨天都用土区账户下完了今天回来了 😭 好——惨——啊——
#优质博文 #科普
科普 | 高帧率、好画质的「光追」是如何实现的?

AI 摘要:本文解析了光线追踪(Ray Tracing)如何提供更真实的光影效果,。同时介绍了 DLSS 技术的发展,从 DLSS 2 的超分辨率提升,到 DLSS 3 的帧生成优化,再到 DLSS 3.5 的 AI 光线重建,以及 DLSS 4 通过 Transformer 模型与多帧生成进一步提升画质和帧率,使高帧率与高画质兼得,推动游戏体验进化。


via 少数派
#碎碎念
我:啊明天情人节吗,要不请个假吧。
妲喵:不准请,给我上班挣钱。

【好吧,情人节出去玩儿确实好亏,算了 😭 还是等平日再请吧】
科技圈🎗在花频道📮
阿里巴巴联合创始人、董事局主席蔡崇信确认阿里与苹果在人工智能合作 2月13日,在阿联酋迪拜举办的World Governments Summit 2025峰会上,阿里巴巴联合创始人、董事局主席蔡崇信回应阿里与苹果合作传闻。 他表示,苹果在中国需要一个本地化的合作伙伴,为他们的手机服务。苹果一直非常挑剔,他们与中国的多家公司进行了交谈。最终,他们选择与我们做生意。我们非常幸运,也非常荣幸能够与苹果这样的伟大公司做生意。 第一财经 📮投稿 ☘️频道 🌸聊天 🗞𝕏
#碎碎念
这下百度真🤡了,好喷
https://fixupx.com/foxshuo/status/1889512275041776032

- 李厂长李厂长,你能再表演一次那个吗,就是那个,开源模型会越来越落后的经典发言;

- Qwen是个很好的模型,在开源社区的刷分成绩也相当优秀,但产品太落后了,我自己其实长期在用好几款通义系产品解决需求,但从来不推荐的原因就是因为产品做得太烂,不想坑人⋯⋯😅
阑夕 (@foxshuo)
阿里巴巴联合创始人、董事局主席蔡崇信确认阿里与苹果在人工智能合作

2月13日,在阿联酋迪拜举办的World Governments Summit 2025峰会上,阿里巴巴联合创始人、董事局主席蔡崇信回应阿里与苹果合作传闻。

他表示,苹果在中国需要一个本地化的合作伙伴,为他们的手机服务。苹果一直非常挑剔,他们与中国的多家公司进行了交谈。最终,他们选择与我们做生意。我们非常幸运,也非常荣幸能够与苹果这样的伟大公司做生意。

第一财经

📮投稿 ☘️频道 🌸聊天 🗞𝕏
#碎碎念
说起来很神奇,但是我那么多苹果设备却一直没iphone(想等新款),然后申请公司买了台二手测试机🌚这转转的机子包装也太……环保了,没蚌住,笑死我了
#优质博文 #前端 #移动端适配 #RWD
将响应式网页设计推向极致 - Taking RWD To The Extreme

摘要:Tomasz Jakut 回顾了网页设计的发展历程,回顾了表格布局风靡一时、Flash 游戏塑造网络文化的时代。 然后,响应式网页设计(RWD)出现了——这常常让人感觉像是历史的终结,至少对网页设计来说是这样。 毕竟,我们仍在创建响应式网站,这才是真正的网页布局方式(The True Way)。 然而,今年,也就是 2025 年,是伊桑-马科特(Ethan Marcotte)发表文章 15 周年,这篇文章永远地改变了网页开发。 以 "网络 "年计算,这是一个完整的时代。 所以,也许在 RWD 之后发生了一些事情,但它是如此明显,以至于几乎不为人所知。 让我们试着揭开它的面纱。
通过DeepL翻译


via Frontend Focus#679
将响应式网页设计发挥到极致--自从伊森-马科特(Ethan Marcotte)首次撰文介绍响应式网页设计(Responsive Web Design)以来,已经过去了 15 年(!),在此期间,我们获得了各种新的强大 CSS 布局工具(如 Flexbox 和 Grid)。 这些布局系统反过来又开创了一个声明式、固有网页设计的新时代,浏览器比以往任何时候都更有能力处理布局。
Taking RWD To The Extreme — Smashing Magazine
#前端 #优质博文 #javascript #性能优化
There are a lot of ways to break up long tasks in JavaScript.
有很多方法可以在JavaScript中分解长任务

AI 摘要:这篇文章讨论了长任务(Long Tasks)对网页性能的影响,以及如何优化用户体验。长任务是指执行时间超过 50ms 的 JavaScript 任务,会阻塞主线程,导致页面卡顿,影响交互响应。文章介绍了如何使用Performance API识别长任务,并提出了优化策略,如将任务拆分成更小的部分 (如使用 setTimeoutrequestIdleCallback )、 Web Workers以及避免不必要的重排和重绘。此外,作者还提供了一些实用工具,如 Chrome DevTools,用于分析和优化长任务,以提升页面的流畅度和响应速度。



我们在这里介绍的方法并不详尽,但我认为这些方法很好地体现了在分解长任务时应该考虑的各种权衡。不过,根据需要,我自己可能只会采用其中的一个子集。

If I can do the work off from the main thread, I'd choose a web worker, hands-down. They're very well supported across browsers, and their entire purpose is to offload work from the main thread. The only downside is their clunky API, but that's eased by tools like Workerize and Vite's built-in worker imports.
如果能从主线程中卸载工作,我会毫不犹豫地选择网络 Worker。网络 Worker 在各种浏览器中都得到了很好的支持,而且它们的全部目的就是从主线程中卸载工作。唯一的缺点是 API 比较笨拙,但 Workerize 和 Vite 内置 Worker 导入等工具可以缓解这一问题。

If I need a dead-simple way to break up tasks, I'd go for scheduler.yield(). I don't love how I'd also need to polyfill it for non-Chromium users, but the majority of people would benefit from it, so I'm up for that extra bit of baggage.
如果我需要一个简单的方法来分解任务,我会选择 scheduler.yield()。我不喜欢还需要为非 Chromium 用户 polyfill 它,但大多数人都会从中受益,所以我愿意承受额外的负担。

If I need very fine-grained control over how chunked work is prioritized, scheduler.postTask() would be my choice. It's impressive how deep you can go in tailoring that thing to your needs. Priority control, delays, cancelling tasks, and more are all included in this API, even if, like .yield(), it needs to be polyfilled for now.
如果我需要非常细粒度的控制工作优先级,那么scheduler.postTask()将是我的选择。令人印象深刻的是,您可以为您的需求量身定制这种东西多么深刻。优先控制,延迟,取消任务以及更多内容都包含在此API中,即使现在.yield()它需要暂时进行polyfilled。

If browser support and reliability are of the utmost importance, I'd just choose setTimeout(). It's a legend that's not going anywhere, even as flashy alternatives hit the scene.
如果浏览器支持和可靠性至关重要,我只选择setTimeout() ,它是一个不会消失的传奇,即使华而不实的替代品层出不穷。



via Alex MacArthur About
Back to Top