跪拜 Guibai
← All articles
Frontend · JavaScript · Programmer

Front-End Judgment: Built From Production Incidents, Not Interview Questions

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

Skipping these failure modes leads to subtle, hard-to-debug production breakages: lost edits, blank screens, and data corruption that only show up under real network conditions and device quirks. This is the judgment gap that tutorials and AI assistants can't close on their own.

Summary

Front-end technical judgment is the ability to run a mental failure simulation over any proposed design: will it die on weak networks? Will concurrent tabs corrupt data? Does Safari behave differently? This reflex isn't taught in courses or interview prep. It comes from having been burned in production, often at 3 a.m. while fixing an outage.

A personal incident log, a Markdown file with over 100 entries documenting each failure's phenomenon, root cause, lesson, and related context, becomes the engine for this pattern matching. Design reviews and code reviews then turn into a search over that personal database for what can break. Reading other people's postmortems, like the danluu/post-mortems collection, offers a shortcut.

Five concrete scenarios illustrate the skill: localStorage multi-tab overwrites and Safari private-mode exceptions, optimistic UI rollback that hangs under weak networks, API fields that are null for legacy users, front-end Excel export that only works for demo-sized data, and autosave that needs debouncing plus a beforeunload fallback. What separates a 3-year from an 8-year front-end engineer is the number of incidents they've seen, not code polish.

Takeaways
— localStorage writes from multiple tabs to the same key overwrite each other; Safari private mode throws on write and requires try/catch.
— Optimistic UI rollback under weak networks can leave UI stuck for seconds and corrupt subsequent state if the user keeps interacting.
— API fields promised to always exist can be null for legacy, third-party, or never-uploaded records; fallback values and onError handlers are required.
— Front-end Excel export with SheetJS is fine for small datasets; exporting more than ~1000 rows should move to the backend.
— Autosave with setTimeout alone breaks under interruptions; debounce, a request queue, and a beforeunload fallback are needed, plus product alignment on save guarantees.
— GitHub star counts and README screenshots don't predict production health; review open issues, release cadence, and source quality.
— A personal incident log (phenomenon, cause, lesson, context) with 100+ entries becomes the data source for design reviews.
— Reading external postmortems, like the danluu/post-mortems repository, accelerates pattern recognition without living through each failure.
— The distinguishing factor between a 3-year and an 8-year front-end engineer is how many production incidents they have seen, not stylistic code.
Conclusions

The advice to keep an incident log and read other people's postmortems undercuts the earlier claim that judgment only comes from first-hand failure, suggesting a deliberate learning loop can substitute for direct pain.

All five scenarios share a common failure class: edge cases that only appear under real-world constraints like weak networks, multi-tab concurrency, legacy data, and browser quirks, which demos and standard test suites rarely expose.

Defining seniority as a function of incidents seen, not code elegance, implies that teams should deliberately expose engineers to production incidents and postmortem reviews to speed up judgment formation.

Source: juejin.cn ↗ Google Translate ↗ Backup ↗