tech-trend-watch

长期技术观察

数据来源

来源	更新频率	URL	衡量内容
State of JS	每年（秋季）	https://stateofjs.com	JS 库、框架、工具——使用率 + 满意度
State of CSS	每年（秋季）	https://stateofcss.com	CSS 工具、框架、特性——使用率 + 满意度
Thoughtworks Tech Radar	每季度	https://www.thoughtworks.com/radar	广泛的技术领域（语言、平台、工具、技术）——所属环

开始审查前，先获取每个来源的最新一期。State of JS/CSS 也提供公开的 JSON API：

https://assets.devographics.com/surveys/js<YYYY>/en-US/results.json
https://assets.devographics.com/surveys/css<YYYY>/en-US/results.json

步骤 1 — 梳理当前技术栈

列出 package.json 中所有重要依赖项：

jq -r '(.dependencies // {}) + (.devDependencies // {}) | keys[]' package.json | sort

重点关注：框架、打包工具、测试运行器、类型检查器、代码检查工具、CSS 工具、状态管理、路由、数据获取、动画。审查中排除底层实用工具和 polyfill。

步骤 2 — 对照 State of JS/CSS

针对当前技术栈中的每项技术，在 State of JS/CSS 结果中找到对应项。

满意度 × 使用率矩阵

                  Low usage        High usage
                ┌────────────────┬────────────────┐
High            │   EMERGING     │    STABLE      │
satisfaction    │  (consider     │  (keep, likely │
                │   adopting)    │   healthy)     │
                ├────────────────┼────────────────┤
Low             │   AVOID        │    LEGACY      │
satisfaction    │  (don't start) │  (plan exit)   │
                └────────────────┴────────────────┘

阈值（State of JS 调查）：高 ≥ 70%，低 ≤ 55%。55–70% 之间的值属于临界范围——查看同比趋势来判断。

稳定（高使用率 + 高满意度）：无需采取行动。生态系统健康。

新兴（低使用率 + 高满意度）：评估是否采用。检查：成熟度、生态系统完整性、从当前选项迁移的成本。

遗留（高使用率 + 低满意度）：安排迁移。高使用率意味着它仍在使用的唯一原因是惯性。检查：大家正在迁移到什么技术？

避免使用（低使用率 + 低满意度）：不要在新项目中使用。如果已经在用：计划移除。

其他信号

• 同比趋势：满意度是在上升还是下降？稳定技术的满意度呈下降趋势，是其可能沦为遗留技术的早期信号。
• 留存率与兴趣度：高留存率（用户持续使用）+ 高兴趣度（非用户希望使用）= 稳妥的选择。
• “不会再用”比例激增：最强的单一遗留技术信号。

步骤 3 — 对照 Technology Radar

针对每项技术，查看 Thoughtworks Tech Radar。所属环：

环	含义	行动
ADOPT	经验证、风险低、建议广泛使用	默认使用
TRIAL	值得尝试，已在特定场景中验证	在实际项目中试用并积累经验
ASSESS	前景可期，需探索其影响	仅用于 Spike / PoC，不用于生产环境
HOLD	谨慎推进，不要用于新项目	不用于新项目；如果已经在用，计划退出

如果某项技术出现在 Radar 上，记录其所属环和首次出现的日期。已处于 HOLD 环 2 年以上且未变动的技术，可考虑主动移除。

未出现在 Radar 上并不意味着技术不好——Radar 偏重企业/咨询领域的关注点，且对新兴 JS 生态工具的收录通常滞后 1–2 年。

步骤 4 — 交叉参考并确定优先级

综合各项信号，分为 4 个行动优先级：

优先级	State of JS 信号	Tech Radar 信号	行动
P0 — 立即迁移	遗留	HOLD	本迭代创建迁移 PR
P1 — 计划迁移	遗留或呈下降趋势	ASSESS 或 HOLD	安排在下个季度
P2 — 关注	留存率下降	未列入 Radar	在下一个年度周期监控
P3 — 无需行动	稳定	ADOPT 或 TRIAL	保持现状

对于新兴技术：除非当前工具属于 P0/P1，否则不要迁移。除非迫不得已，切换成本通常高于边际收益。

步骤 5 — 评估迁移候选项

针对每项 P0/P1，估算：

1. 迁移工作量：使用 grep 统计用法，估算所需工时
2. 目标替代方案：State of JS 中的“movers”迁移到了什么技术？
3. 共存期：迁移期间新旧方案能否并行运行？
4. 风险：是否涉及运行时（高风险）或仅涉及构建工具（风险较低）？

评估模板示例：

### jest → vitest

- Current usage: 47 test files (grep -r "from 'jest'" src/)
- State of JS signal: LEGACY (satisfaction dropped from 85% → 61% 2021→2024)
- Tech Radar: HOLD (Vol.30)
- Target: vitest (STABLE, Tech Radar ADOPT Vol.31)
- Effort: ~4h (config migration + minor API diffs, @testing-library compatible)
- Coexistence: no (different config, but can migrate per-file)
- Risk: build tooling only → low
- Recommendation: migrate in one PR

步骤 6 — 输出

撰写一份审查文档，包含：

## Tech Watch — <YYYY-QN>

### Data source versions
- State of JS: <year>
- State of CSS: <year>
- Tech Radar: Vol.<N> (<date>)

### Stack health summary
| Technology | Category | Signal | Priority | Notes |
|---|---|---|---|---|
| vitest | test runner | STABLE / ADOPT | P3 | — |
| tailwindcss | CSS | STABLE / ADOPT | P3 | v4 migration due |
| jest | test runner | LEGACY / HOLD | P0 | migrate to vitest |
| ... | | | | |

### P0 — Migrate now
- [ ] <package>: <brief rationale> → <target>

### P1 — Plan migration (next quarter)
- [ ] <package>: <brief rationale>

### P2 — Watch (next annual cycle)
- <package>: <signal to monitor>

### Newly emerged (consider adopting)
- <technology>: EMERGING, TRIAL — evaluate for <use case>

节奏

• 每年：与 State of JS/CSS 发布同步进行全面评审（通常在 11 月至 1 月）。
• 每季度：检查 Tech Radar 最新一期，了解现有技术栈条目是否有变化。
• 按需（采用新技术）：评估是否引入尚无现有替代方案的新库时，执行步骤 3（仅 Radar）。
• 按需（替换决策）：对当前工具和候选工具都执行步骤 2–5。省略步骤 1 的技术栈清单和步骤 6 的完整输出文档，改为生成一份迁移评估。当问题涉及现有工具时（例如“我们应该从 X 切换到 Y 吗？”或“我们应该添加 Y，还是继续使用 X？”），请采用此流程。

范围

• 此技能涵盖战略决策，而非实施。执行更新时，请使用 dep-lib-review。
• 不要仅依赖 Tech Radar——它对 JS 生态系统的反映有所滞后。务必交叉参考 State of JS/CSS。
• “大家都在迁移到 X”并非足以迁移的理由。应评估迁移成本与当前工具实际带来的困扰。

相关内容

• dep-lib-review — 执行实际更新（按 patch/minor/major 版本分批处理）
• frontend-review-deps — 依赖项运营审计，包含 CVE 分类和趋势监控脚本