Frontend & Runtime

How stack, microtasks, timers, and execution order actually fit together.

How to separate the main thread, event loop, I/O, libuv, and worker threads without repeating a sentence that hides the real behavior.

How to understand references, lifecycle, mutation, and leaks without turning the topic into a compiler lecture.

A simple way to decide what should be real state, what can be derived, and what should not exist at all.

In frontend interviews, a strong answer does not stop at debounce. It talks about request concurrency, UI states, client-side cost, and experience trade-offs.

How to use effects without turning synchronization, fetches, and side effects into hard-to-predict behavior.

How to decide where work should happen without turning the architecture into a blurry mix.

How to use HTML and interface structure to improve navigation, reading, and understanding without treating accessibility as a visual detail.

How to design keyboard navigation and focus flow that stay clear and reliable across the interface.

How to build interactive React components while preserving semantics, focus, and native behavior.

A lot of frontend architecture degrades when different kinds of state get treated as if they were the same thing.

A lot of frontend trees get confusing because the responsibility of each layer was never actually defined.

A good custom hook encapsulates recurring behavior. A bad hook only moves the mess to another file.

Good modularization reduces blast radius and improves understanding. When it turns into folder theater, it only increases navigation cost.

Large frontends rarely improve through a broad rewrite. The safer path is usually reducing real pain in parts, improving boundaries, and migrating progressively.

A useful design system does not try to control everything. It standardizes what reduces friction and leaves open what still needs room.

What actually helps is being clear about what is feature-local code, what is shared, and what has become a stable contract.

How to leave the shallow bundle-size conversation behind and see the full cost of downloading, parsing, executing, and competing for the main thread.

How to understand the real cost of updating interface in the browser without treating everything as a React, CSS, or JavaScript problem in isolation.

How those resources enter the page at different times and with different weights, and why that changes painting, blocking, and perceived speed.

How to separate what is HTML coming from the server, what is activation in the client, and what really only comes to life in the browser.