tech-trend-watch

Long-Term Technology Watch

Data Sources

Fetch the latest edition of each before starting the review. State of JS/CSS also publish a public JSON API:

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

Step 1 — Inventory current stack

List all significant dependencies from package.json:

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

Focus on: frameworks, bundlers, test runners, type checkers, linters, CSS tooling, state management, routing, data fetching, animation. Exclude low-level utilities and polyfills from the review.

Step 2 — State of JS/CSS mapping

For each technology in the current stack, locate it in the State of JS/CSS results.

Satisfaction × Usage matrix

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

Thresholds (State of JS survey): high ≥ 70%, low ≤ 55%. Values between 55–70% are borderline — check year-over-year trend to break the tie.

STABLE (high usage + high satisfaction): No action. Healthy ecosystem.

EMERGING (low usage + high satisfaction): Evaluate for adoption. Check: maturity, ecosystem completeness, migration cost from current choice.

LEGACY (high usage + low satisfaction): Schedule migration. High usage means inertia is the only reason it's still there. Check: what are people migrating to?

AVOID (low usage + low satisfaction): Do not start new projects on this. If already used: plan removal.

Additional signals

• Year-over-year trend: Is satisfaction rising or falling? A falling trend in STABLE is an early LEGACY signal.
• Retention vs interest: High retention (users stick with it) + high interest (non-users want it) = safe bet.
• "Would not use again" spike: Single strongest LEGACY signal.

Step 3 — Technology Radar mapping

Check the Thoughtworks Tech Radar for each item. Rings:

If an item appears on the radar, note the ring and the date of first appearance. Items that have been HOLD for 2+ years without movement are candidates for active removal.

Items not on the radar are not necessarily bad — the radar skews toward enterprise/consultancy concerns and lags emerging JS ecosystem tools by 1–2 years.

Step 4 — Cross-reference and prioritize

Combine signals into a 4-level action priority:

Newly EMERGING tech: do not migrate unless the current tool is P0/P1. Switching costs > marginal improvement unless forced.

Step 5 — Migration candidate evaluation

For each P0/P1 item, estimate:

1. Migration effort: grep for usage count, estimate hours
2. Target alternative: what did State of JS "movers" migrate to?
3. Coexistence period: can old and new run side-by-side during migration?
4. Risk: does it touch runtime (high risk) or build tooling only (lower risk)?

Example evaluation template:

### 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

Step 6 — Output

Write a review doc with:

## 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>

Cadence

• Annual: Run full review aligned with State of JS/CSS release (typically November–January).
• Quarterly: Check Tech Radar new volume for changes to existing stack items.
• On-demand (new adoption): Run Step 3 (Radar only) when evaluating whether to add a new library with no existing incumbent.
• On-demand (replacement decision): Run Steps 2–5 for both the current tool and the candidate. Omit Step 1 stack inventory and Step 6 full output doc — produce a single migration evaluation instead. Use this path when the question has an incumbent ("should we switch from X to Y?" or "should we add Y or keep X?").

Boundaries

• This skill covers strategic decisions, not implementation. For executing updates, use dep-lib-review.
• Do not use Tech Radar alone — it lags the JS ecosystem. Always cross-reference with State of JS/CSS.
• "Everyone is migrating to X" is not sufficient reason to migrate. Evaluate migration cost vs. actual pain with the current tool.

Related

• dep-lib-review — executes the actual update (patch/minor/major batching)
• frontend-review-deps — operational dependency audit with CVE triage and trend-watch scripts