跪拜 Guibai
← All articles
Frontend · JavaScript · Programmer

The Frontend Architect's Real Job Is Saying No

By ErpanOmer ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

The frontend churn cycle burns engineering time on migrations that rarely improve business outcomes. A clear, testable rule — only adopt what fixes a P0 problem — and concrete fallback patterns give teams permission to stop chasing and start shipping.

Summary

Frontend fatigue has hit a breaking point. The cycle is predictable: Webpack gives way to Vite, Vite to Turbopack, React Hooks to Server Components, and teams rewrite working systems just to keep their resumes current. The result is rarely faster delivery — it's half-finished migrations, ecosystem gaps, and GitHub Issues becoming the only documentation.

A senior architect's primary skill isn't adopting new technology; it's refusing it. The litmus test is simple: if a tool only offers syntactic sugar and doesn't address a P0 business pain point, it doesn't ship. The article demonstrates this with a production-grade React hook that uses the native AbortController to cancel in-flight requests on unmount — zero dependencies, no state management library, just the platform.

Saying no carries obligations. Business logic must be extracted into framework-agnostic TypeScript so that UI layer churn never forces a rewrite. Multi-team micro-frontend ambitions get blocked in favor of strict iframe isolation with postMessage and CSP. Performance claims from new tools get countered with real FCP and LCP data collected through PerformanceObserver, proving that disciplined code and lazy loading still win.

Takeaways
Resume-driven development is the direct result of industry FOMO, pushing teams to refactor stable projects for new buzzwords.
Introducing beta frameworks or radical architectures like micro-frontends without a P0 business reason creates ecosystem gaps and maintenance nightmares.
The core test for any new technology: if it only provides syntactic sugar and doesn't solve a top-priority business pain point, reject it.
Native Web APIs like AbortController can handle request cancellation and race conditions with zero third-party dependencies.
Extract business logic into pure TypeScript classes or functions so that UI framework changes never force a rewrite of core systems.
Block complex micro-frontend setups in favor of iframe isolation with postMessage, strict CSP, and domain whitelisting.
Build a performance monitoring loop with PerformanceObserver to collect FCP and LCP metrics, proving that old architectures still perform when disciplined.
Conclusions

The argument reframes architectural conservatism not as fear of change but as a higher-order skill: the ability to say no and then deliver a boring, proven fallback is what separates senior engineers from framework tourists.

The AbortController example is deliberately unsexy — it demonstrates that the platform already solves problems teams reach for libraries to fix, and that production stability often lives in what's already shipped in the browser.

Resume-driven development is rarely called out this bluntly in English-language frontend discourse, where tooling enthusiasm is often treated as a virtue rather than a liability.

Concepts & terms
Resume-Driven Development
The practice of choosing technologies or initiating rewrites primarily to add fashionable keywords to one's CV, rather than to solve a genuine business problem.
AbortController
A native browser API that provides an AbortSignal object, allowing fetch requests and other async operations to be cancelled programmatically — useful for preventing race conditions and memory leaks when components unmount.
P0 Business Pain Point
A top-priority, mission-critical problem whose resolution directly affects revenue, user trust, or system availability. In this context, the threshold a new technology must clear to justify adoption.
Source: juejin.cn ↗ Google Translate ↗ Backup ↗