yiyibooks.cn
Levix
前端打杂
|
Null
获得徽章 16
- AI 提示工程（prompt engineering）的衰落和新发展。提示工程是编写查询语句的技巧，目的是改善大型语言模型（LLM）或 AI 艺术抑或视频生成器的输出或规避保护措施。
主要内容：
1. 自从 ChatGPT 在 2022 年秋季问世后，许多人尝试了提示工程技巧。
2. 商业领域中，许多公司正在使用 LLM 和提示工程师来建立产品副驾驶、自动化繁琐工作、创建个人助理等。
3. 新研究表明，最好由模型本身来完成提示工程，而不是由人类工程师来做。
4. VMware 的 Rick Battle 和 Teja Gollapudi 进行了研究，发现不同提示策略对于 LLM 解决小学数学问题的影响差异很大。
5. 他们提出，没有一个确定的趋势。对任何给定的模型、数据集和提示策略，最好的做法可能特定于手头的特定组合。
6. 他们鼓励使用自动化工具来发现输入到 LLM 的最佳短语，并且这些自动生成的提示往往比通过试错法找到的提示要好。
7. 优化的自动生成提示往往很奇怪，不太可能由人类想出。强调了语言模型的数学特性，而不是人性（如语言）的特性。
发展和挑战：
1. 图像生成算法也可以从自动生成的提示中受益。
2. Intel Labs 的一支团队开发了一个名为 NeuroPrompts 的工具，它可以自动增强输入提示，以产生更好的图片。
3. Lal 和他的团队希望通过这些优化调研，最终将它们整合到基础模型中，从而无需进行复杂的提示工程步骤。
对行业未来的预测：
1. 即使自动化提示成为行业标准，提示工程师在某种形式下的工作不会消失。
2. AI 的应用需要更复杂、多阶段的适应，而人类仍将在可预见的未来参与其中。
3. 新的职位名称可能会出现，如大型语言模型操作(Large Language Model Operations, LLMOps)。
4. 所有这些角色和工作仍将继续迅速发展，而且在当前混沌的形势下，不会很快消失。
5. 特别是在行业的初期阶段，似乎没什么确定的规则，就像"野蛮的西部"一样。
#AI #Prompt展开12 - LayerDiffusion：一种使大规模预训练的潜在扩散模型能够生成透明图像的方法。该方法允许生成单个透明图像或多个透明层。该方法学习“潜在透明度”，将 alpha 通道透明度编码到预训练潜在扩散模型的潜在流形中。它通过将增加的透明度调节为潜在偏移量，对预训练模型的原始潜在分布进行最小的更改，从而保持了大型扩散模型的生产就绪质量。通过这种方式，任何潜在扩散模型都可以通过调整后的潜在空间进行微调来转换为透明图像生成器。我们使用人机交互收集方案收集的 1M 透明图像层对来训练模型。我们表明，潜在透明度可以应用于不同的开源图像生成器，也可以适配到各种条件控制系统，以实现前景/背景条件层生成、联合层生成、层内容的结构控制等应用。一项用户研究发现，在大多数情况下 （97%） 用户更喜欢我们原生生成的透明内容，而不是以前的临时解决方案，例如生成和抠图。
#AI #论文
中英文对照版本：
yiyibooks.cn 展开12 - 《调试 INP》
文章详细讨论了如何调试和改善网站性能中的一个重要指标——交互到下次绘制（Interaction to Next Paint，简称 INP）。INP 将在 3 月 12 日成为核心网络指标（Core Web Vital）。这一指标衡量页面对用户交互诸如点击、敲击或按键等交互的响应速度，测量从交互到浏览器下一次屏幕绘制（painting）的耗时。
INP 分为三个子部分：
1. 输入延迟：交互处理程序等待执行的时间。
2. 处理时间：交互处理程序执行的时间。
3. 展示延迟：浏览器执行任何工作来绘制由交互处理器触发的更新所需要的时间。
由于页面可能有多个交互，RUM 产品和其他工具（如 Google 搜索控制台和 Chrome 的 UX 报告（CrUX））报告的 INP 时间通常是第 75 百分位最差（最高）的 INP 时间。
为了改善 INP，文章提供了一系列调试步骤和策略：
1. 识别有问题的交互。可以使用 CrUX 提供的高级视图或通过工具如页面速度洞察进行检查。
2. 配置 Chrome DevTools 和移动仿真，将页面加载和记录分析。使用 DevTools 的性能面板记录和停止记录，并分析主线程活动。
3. 分析交互。确定导致 INP 时间延长的原因，并探究减少这些时间的方法。
4. 提出改进方案。包括延迟次要活动、优化代码、减少必要工作和在合适的时机把控制权交还给主线程。
文章中举了三个实际网站的例子，说明了如何基于这些步骤改善具有高 INP 时间的交互：
1. H&M 的移动网站菜单打开事件。
2. John Lewis 的菜单打开事件。
3. Wales Online 接受同意对话框事件。
改善建议包括：
1. 推迟执行不太重要的活动。
2. 优化代码并减少执行量。
3. 把长任务和繁重的处理移出主线程。
4. 使用 setTimeout 和 requestIdleCallback 将长任务拆分。
作者强调使用真实用户监控（RUM）可以帮助快速识别具有高 INP 的页面和交互，但即便没有 RUM 数据也可以开始提升 INP。不过，这可能会导致你无法调试最有影响力的交互。
INP 的测量不是一个完美的科学，可能会遇到一些非常规情况。文章建议逐渐尝试和改善，即使是小的递增变化，也会累积起较大的整体性能提升。展开评论1 - #前端开发现状# JSR （JavaScript Package Registry）是由 Deno 团队新推出的 npm 包注册仓库平台，旨在解决 npm 存在的限制，并提供多项改进。以下为概要总结：
Deno 团队背景
1. Deno 是 Node.js 创始人 Ryan Dahl 在承认 Node 早期设计决策的遗憾后，推出的一个运行时项目，旨在提供更快、更安全的 JavaScript 运行环境。
2. 2021 年成立 Deno Land 公司，得到 Shasta Ventures 和 Mozilla Corporation 资助。后续，Deno 在 Sequoia Capital 领投的 A 轮融资中获得 2100 万美元资金。
JSR 特点
1. 强调为 TypeScript 提供更高效的支持。
2. 提升性能和易用性，有集成工作区和无缝的 NPM 集成。
3. 通过 HTTPS 提供安全和可获取的模块。
4. 开源和社区驱动的项目。
5. 防止包名占用和废弃模块占位，支持语义化版本控制。
开发者对 JSR 的看法
1. 部分开发者已获早期访问权限，其余人等待访问；反馈包含对其架构决策的认可。
2. Deno 的 TypeScript-first 环境让 TypeScript 开发者发布包更加顺畅。
3. 尽管 Deno 和 JSR 带来一定改进，JSR 是否能够替代 npm 还有待观察。
4. Deno 相对于 Node.js 和 npm 的改进点可能被视为细微和具有破坏性的，如果被采用将会对现有系统构成显著变化。
JSR 应对生态系统分化的挑战
1. 为确保不加剧生态系统分化，Deno 团队承诺要实现与 npm/Node 的兼容性。
2. 有关方面，包括 Socket，在关注 JSR 的发展，希望在其获得更广泛的社区接受时提供支持。
目前，具体获取 JSR 的权限计划尚未面向等待名单公布。对于如何说服社区采用 JSR，Deno 团队需要投入努力，这将最终决定 JSR 作为有效竞争者的可行性。展开评论2 - 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 - 《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 - 《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 - Graphize —— 支持在浏览器中可视化查看并下载 JSON / YAML / XML 内容。
#Tools评论1
