
获得徽章 16
- Graphize —— 支持在浏览器中可视化查看并下载 JSON / YAML / XML 内容。
#Tools赞过评论1 - 《JavaScript 按需加载:Qwik 如何不同于 React 的 Hydration》
作者 Paul Scanlon 探讨了 Qwik 的恢复性(resumability),这是 Qwik 解决客户端 JavaScript 问题的方法,并详细解释了它与 React 的不同。
文章主要内容 :
- 客户端 JavaScript 面临的问题和 Qwik 的解决方案。
- React 的 Hydration(客户端重新活化)如何工作,通过类比“倒下多余的啤酒”来解释 React 常导致的浪费。
- Qwik 通过询问用户需求然后精准提供服务的方式,类比于在酒吧根据顾客需求逐个提供啤酒,说明了 Qwik 的恢复性工作方式。
- Qwik 的 JavaScript 按需加载与其恢复性原则,以及如何实现仅在需要时才加载代码段,从而优化应用性能。
- 介绍了 Qwik 的 Service Worker 如何改进应用代码加载。
- 提供了一个实例,说明了 Qwik 是如何智能加载必要的代码段并提高性能的。
Qwik 的特点 :
- 更精细的 JavaScript 代码切分,可生成更小的代码块。
- 恢复性原则,确保只有用户需要时才加载和执行特定的代码。
- 强调使用 Service Worker 来提高应用性能,减少主线程的负担。
React 的挑战 :
- 重现全部应用状态使用时间长、带宽高。
- 客户端激活(Hydration)可能导致不必要的复杂度和性能问题。
Qwik vs React :
- Qwik 专注于仅在必要时加载交互性的 JavaScript,而 React 的应用通常在加载时就需要所有 JavaScript。
- Qwik 以性能优化为核心,而 React 需要在代码切分和懒加载技术上多费工夫。
最终思考 :
- 通过恢复性原则,Qwik 提供了一个节省资源和提升用户体验的方法,仅加载和执行必要的代码。
- Qwik 正在改变开发者构建交互式 web 应用的思维模式,使其变得更加智能和高效。
这篇文章向开发者提供了一个不同于常规 React 应用激活方法的新思路,即 Qwik 的恢复性,并深挖了它如何有效地减少不必要的加载和执行,从而提高性能和用户体验。
#前端 #Qwik #React展开赞过评论1 - 《HTMX vs React:完整比较》
详细比较了 HTMX 和 React ,两种前端开发技术的不同点。文中讨论了 HTMX 的目标是直接在 HTML 中提供现代浏览器交互性,而无需 JavaScript,这一点与 React 有着显著不同。
总览 :
- HTMX 发展迅速,在 2023 JavaScript 星光大奖“前端框架”类别中获得第二名。
- HTMX 项目在 GitHub 上获超过 20,000 星,入选 GitHub Accelerator。
比较 :
- HTMX 由 Big Sky Software 开发,以 HTML 为基础,致力于简化开发流程。
- React 由 Meta 开发,并以 JSX 为基础,提供了一个基于组件的全功能 UI JavaScript 库。
性能 & 特性 :
- HTMX 专注于简约性,轻量级(2.9 kB),而 React 较为重量级(6.4 kB)但功能全面,适用于大型应用。
- HTMX 着力于通过自定义属性来简化 AJAX 请求等操作,React 则提供了一系列高级特性,包括状态管理和钩子。
社区 & 生态系统 :
- HTMX 拥有一个正在增长的小型社区,而 React 拥有市场上最大的社区及丰富的生态系统。
HTMX 的主要优势 :
- 使用特殊 HTML 属性而无需写 JavaScript。
- 对现有 HTML 页面具有高度的集成性。
- 对于简单交互的项目来说是轻量级和高效的选择。
- 适合后端开发者提供交互式 HTML 页面。
React 的主要优势 :
- 结构化 UI 的可重用组件使得网站的维护和重用变得简单。
- 适合构建提供丰富用户体验和处理复杂状态的单页应用程序。
- 吸引了大型团队跨项目共享 UI 组件。
这篇文章为开发者提供了在两个库之间做出明智选择的见解,并指出 HTMX 并非要取代 React,它们各有适用场景并可以共存。
#前端 #React #HTMX展开赞过评论1 - Apache ECharts 5.5.0 版本更新
1. 增强 ESM 支持 :
- 为开发者测试和 Node.js 中的模块定制使用场景而设计的默认 ESM 包的重要改变。
- 添加了 "type": "module" 和 "exports": {...} 到 package.json ,改善了之前版本在 Node.js 中的表现。
- 保持了与多种运行环境和打包工具的兼容性。
2. 服务端渲染 + 轻量级客户端运行时 :
- 引入了服务端 SVG 字符串渲染解决方案,并支持图表的初始动画。
- 引入了仅需 4KB (gzip 压缩后 1KB ) 的轻量级运行时以实现初步动画和一些通用交互。
- 减少了数据包大小,加速了页面加载,特别是在移动设备上的体验。
3. 数据钻取支持过渡动画 :
- 新增 childGroupId 配置项,可以实现数据钻取时的过渡动画功能。
4. 饼图支持扇形之间的间隙 :
- 通过设置扇形之间的间隙,使饼图的数据块更加清晰,并形成独特的视觉效果。
5. 饼图和极坐标系统支持结束角度 :
- 可配置的结束角度允许创建不完整的饼图,如半圆。
6. 新增 min-max 采样方法 :
- 当数据量远大于像素数量时,可以通过 "min-max" 采样方法更准确地显示数据极值,同时保持数据趋势。
7. 新增两种语言:阿拉伯语和荷兰语 :
- 通过 echarts.registerLocale 方法注册新的语言包。
8. 工具提示支持指定容器 :
- 可通过 tooltip.appendTo 配置项来指定 Tooltip 的容器,更灵活地控制 Tooltip 位置。
9. 坐标轴最大和最小标签的对齐方式 :
- 新增 axisLabel.alignMinLabel 和 axisLabel.alignMaxLabel 配置项,以控制坐标轴上最大和最小标签的对齐方式。
10. 象形柱状图支持剪辑 :
- 通过 series-pictorialBar.clip 配置项剪辑超出绘图区域的象形柱状图。
11. 为 Tooltip valueFormatter 添加 dataIndex 参数展开赞过评论1 - 《如何避免 repo-jacking(仓库劫持)》
文章讨论了针对开源软件可能的供应链攻击:repo-jacking(仓库劫持),解释了它是什么、存在什么风险,以及如何保护自己不受其影响。
以下是文章的核心内容:
1. Repo-jacking 是一种供应链攻击,其影响可能延伸到大量使用开源软件的用户和系统。
2. 如果你从包管理器(如 npm 或 PyPI)获取所有软件依赖,你不会直接受到 repo-jacking 的影响。但如果你直接从 GitHub 获取依赖项,就需要更加小心。
3. 防御 repo-jacking 的简单方法是锁定特定的提交ID(commit ID)。
4. GitHub 采用了一种名为“碑石算法”(tombstoning algorithm)的机制,通过永久淘汰特定的用户名和仓库名组合来减少 repo-jacking 的风险。故而,repo-jacking 只针对低于特定使用门槛的仓库构成风险。
5. GitHub上的自动重定向功能可能会增加 repo-jacking 的风险,因为重定向可能让人们不易察觉依赖已经被改名。
6. 包管理器创建了额外的保护层来对抗 repo-jacking,因为你需要获得维护者账号的访问权限来用恶意软件替换包管理器上的包。
7. 如果你或你的项目构建系统直接从 GitHub 下载软件,你需要特别小心,可以通过锁定特定的提交ID来避免 repo-jacking。
8. 作者还讲述了如何使用 GitHub API 来检查仓库是否已被重命名或替换,作为检测 repo-jacking 的一种方法。
9. 文章也提到了供应链安全中值得关注的新进展,如使用 OpenID Connect (OIDC) 安全上传构建工件到包管理器,并介绍了跨机构合作开发的软件供应链级别框架(SLSA)。
文章的结论是,尽管 GitHub 使用了碑石算法来降低因更改用户名可能导致的 repo-jacking 风险,但如果你的项目有直接从 GitHub 下载的依赖,最简单的安全保护措施是锁定特定的提交ID。
#Github #安全展开等人赞过35 - Chrome 122 更新介绍
1. 存储桶 API(Storage Buckets API) :提供了更多细粒度的控制,以更好地管理持久化存储。通过创建多个存储桶,浏览器可以独立地选择删除每个存储桶,让您指定删除优先级以确保不删除最重要的数据。每个存储桶都可以包含诸如 IndexedDB 和 CacheStorage 等既定存储 API 的数据。
2. DevTools 性能面板改进 :Chrome 122 的 DevTools 在性能面板中引入了改进:
- 在时间线顶部加入了面包屑功能,允许设置面包屑并在它们之间跳转。
- 在主跟踪中显示启动器与后续事件之间的连接箭头。
3. 异步剪贴板 API 未经消毒的选择(Async Clipboard API unsanitized option) :新增了一个选项,允许应用和网站通过 read() 方法获得未消毒的 HTML 。如果不包括该属性,从剪贴板读取 HTML 时,内容会进行消毒处理。
4. CSS 和 WebGL 的新特性 :
- 包含不支持特性的容器查询永远不匹配。
- dataTransfer.clearData() 不会影响 File 对象,只删除文本类型对象。
- WebGL 的 drawingBufferStorage 允许绘制超过 8 位精度的内容,避免将渲染内容转换到默认绘图缓冲区像素格式时的额外复制。
#Chrome #新特性展开等人赞过46 - Google 宣布专为中国开发者服务的 Chrome for Developers 现已在 .cn 域名上线,让在中国的开发者更容易地访问相关内容。所有内容都在 .cn 域名下进行镜像,并提供所有支持的语言版本。
在这里,可以找到针对中国的 Chrome 开发者资源:developer.chrome.google.cn 。通过这个资源,开发者可以了解最新的 Chrome 稳定版和测试版的发布信息,发现 Chrome DevTools、浏览器扩展等丰富的文档资料。
此外,Google 还同时在中国推出了 web.dev 网站,以满足本地开发者对前沿技术资源的需求,访问地址为web.developers.google.cn。
这一举措是在 2023 年上海的 I/O Connect 事件中与中国开发者亲密互动后做出的决策。Google 希望这能够成为更好地支持中国开发者的一个良好开始。展开等人赞过2138 - 《JavaScript Sets 即将引入并集、交集、差集等功能》
目前,JavaScript 的 Set 对象已可执行基本操作,如创建、添加、删除和检测成员。但对于进行集合运算,比如合并(union)、交集(intersection)和差集(difference)操作,ES2015 规范的 Set 对象还不支持。TC39 委员会(负责 ECMAScript 规范的开发)已经在这方面取得了进展,一些浏览器实现了相关功能。
以下是新增加的几个 Set 方法及其意义:
1. union :创建两个集合所有元素的合集。
2. intersection :创建两个集合中共有元素的交集。
3. difference :创建在第一个集合中但不在第二个集合中的元素集。
4. symmetricDifference :创建仅存在于两个集合之一中的元素集。
5. isSubsetOf :判断一个集合是否为另一个集合的子集。
6. isSupersetOf :判断一个集合是否为另一个集合的超集。
7. isDisjointFrom :判断两个集合是否无交集。
目前,Safari 17 和 Chrome 122 已经支持这些新方法,Edge 也即将支持,Firefox Nightly 在标记后也支持了。
对于旧 JavaScript 引擎,可以使用 polyfills 来升级到符合规范的这些新功能。例如,core-js 或 es-shims 项目提供的独立功能包。
#前端 #新特性 #TC39展开等人赞过14 - Interaction to Next Paint(INP)将在 3 月 12 日成为核心 Web 指标(Core Web Vital)
文章内容:
- INP 的引入:INP 将在 3 月 12 日正式成为核心 Web 指标,并将取代首次输入延迟(FID)。Web Vitals 计划提供关键指标以帮助开发者衡量Web用户体验的重要方面,随着时间的发展,FID 不足以完全表达 Web 互动性,Chrome 团队于 2022 年 5 月引入了实验性指标 INP。去年 INP 成为一项待决指标,并宣布将在 2024 年 3 月晋升为稳定状态。
- 如何准备:首先,需要确保网站的 INP 在所有页面加载的第 75 百分位数中表现良好。可以使用 PageSpeed Insights(其中包含来自 Chrome 用户体验报告(CrUX)的数据)来查看网站在 INP 上的表现。如果已经与真实用户监测(RUM)提供商合作,考虑询问他们对 INP 的支持。如果网站的 INP 需要改进,提供了一系列资源和引导来优化 INP。
- INP 转变影响:FID 将不再是核心 Web 指标,并将官方弃用,并从程序中移除。在 Google 的各种工具中,FID 的信息将被移除并替换为 INP 的相关信息。PageSpeed Insights 和 CrUX 将提供 6 个月的弃用期,给开发者更新代码的机会。
- 未来的道路:过去两年来,INP 被纳入核心 Web 指标的计划已经仔细规划,这一步将推动 Web 互动性的提升。随着 INP 将成为核心 Web 指标的日期临近,开发者应该利用这个时间来理解和优化 INP 性能。
#前端 #性能 #INPweb.dev
展开等人赞过111