- Posts About the Layer Underneath, Not Framework Usage
- Language and Types — The Layer That Outlasts Frameworks
- Browser and Bundle — Getting Code to the Point of Running
- Design — Deciding What Belongs in State
- Layout and Readability — On Screen and in Code
- Related Posts and Tools on This Blog
- Other Posts in This Series
Posts About the Layer Underneath, Not Framework Usage
Frontend has the fastest tool replacement cycle of any specialty, which means how-to posts age quickly. This list is deliberately filled with writing about the layer underneath — how the language behaves, how the browser behaves, and design judgment — the parts that survive a tool change.
The selection method is the same across the series. I found candidates by searching and then opened each post directly to check it, keeping the ones whose explanations were concrete and reproducible. This list is an editorial pick, not a ranking. I did not measure views or popularity and have no way to.
I gave priority to personal blogs. Personal domains and GitHub Pages are heavily represented, because that is where the long-form writing in this field concentrates. Two entries come from Woowacourse's Tecoble, and each is either a specific improvement log or a team-level design decision that a personal post could not substitute for.
A note for readers outside Korea: every linked post is written in Korean. You will need Korean to read them, although the code samples that carry most of these arguments are readable regardless.
All links were opened and checked directly on 2026-08-12. Personal blog posts can disappear or change addresses.
Language and Types — The Layer That Outlasts Frameworks
Closure
- Blog · Author: PoiemaWeb (이웅모)
- One-line summary: Closures explained on top of execution context, carried through to real uses like information hiding, partial application, and currying.
- Read this if: You memorized closures for an interview but cannot explain why they behave as they do.
Most closure explainers stop at a counter example; this one explains why the value persists, in terms of the lexical environment. The central perspective is that a closure is less a feature the language provides than a phenomenon arising from the structure of execution contexts. As a result you finish with scope as a whole clarified, not just closures. It is an older document, but the layer it addresses is language fundamentals, so it still holds — and among Korean-language JavaScript material it is the most orderly thing to use as a reference.
자바스크립트는 왜 프로토타입을 선택했을까
- Blog · Author: te-ing.log (velog)
- One-line summary: Prototype-based design traced from philosophical arguments about categories and meaning, then connected to how the language actually behaves.
- Read this if: You know the prototype chain but have never been convinced why it had to be this way.
This one takes an unusual route. It examines where the class-and-instance distinction came from and what the objections to it were, then places JavaScript's choice in that context. Writing like this easily collapses into affectation, but the second half lands on concrete behavior — hoisting, closures, the scope chain — which keeps it balanced. Even if you disagree, you gain one more angle from which to look at language design. It is also good reading when you are tired of straight technical material.
타입스크립트 타입 정복: Conditional Types
- Blog · Author: Front J · JonghwanWon
- One-line summary: Conditional types and the infer keyword woven together with generics, closing on practical examples like flattening nested arrays.
- Read this if: You have used utility types but never written your own.
Conditional types are where TypeScript's difficulty curve turns sharply upward, which makes a good Korean explanation valuable. This post builds steps from the ternary-like syntax up to extracting types with infer. The examples are things you would plausibly write, so the concept does not stay abstract. Understanding how the standard library's utility types are constructed comes along as a side benefit.
타입 시스템은 왜 증명처럼 동작하는가
- Blog · Author: 문동욱 (Evan Moon)
- One-line summary: The view that type checking works as logical proof rather than error detection, taken as far as the Curry-Howard correspondence.
- Read this if: You have treated types as a nuisance checker and recently started to change your mind.
Once you see the correspondence between types as propositions and programs as proofs, type design looks different. This post maps that correspondence onto familiar syntax — functions, tuples, unions, generics — one at a time, so the theory never separates from the syntax you write daily. It mentions formal logic, set theory, and lambda calculus but takes only as much as it needs, keeping the barrier low. It also supplies the underlying justification for why making impossible states unrepresentable is such a powerful practice.
Browser and Bundle — Getting Code to the Point of Running
브라우저 렌더링 과정 (리플로우와 리페인트)
- Blog · Author: Minjae Kim
- One-line summary: How HTML and CSS get parsed into a render tree, and what triggers a reflow versus what stops at a repaint.
- Read this if: You have to explain why an animation stutters and cannot produce the evidence.
Rendering pipeline explainers are common, but this one carries on to the optimization points. It separates which properties force layout recalculation from which are handled at the composite stage, which makes it clear what to change in the code. The length is right for pinning as a link in a team wiki, and it works as onboarding material too. Because the layer is framework-independent, it has a long shelf life.
React 효율 개선을 위한 Fiber Reconciler
- Blog · Author: Jason Kang
- One-line summary: The limits of the stack reconciler and how Fiber changed them, organized around the idea of interruptible units of work.
- Read this if: You have heard that React defers rendering but do not know what it defers or how.
Starting from why synchronous recursive rendering was a problem makes Fiber's design read as inevitable. It covers how splitting work, assigning priority, and pausing then resuming interlock, and why there are two trees — the current one and the work-in-progress one. To understand why React's concurrency features have the shape they do, you have to look at this layer at least once. The length is not intimidating, which makes it a good starting point.
차세대 번들러 비교 및 분석 (feat. webpack, rollup, esbuild, vite)
- Blog · Author: bepyan blog · Edward Kim
- One-line summary: Four bundlers explained not as a feature comparison but in the order of why each one appeared.
- Read this if: You have to pick a bundler and do not know which problem each was built to solve.
Explaining by lineage is this post's decisive advantage. Starting from task runners and showing in sequence what discomfort each tool was a response to means you can judge without memorizing a comparison table. In a field where tooling keeps turning over, writing structured this way lets you slot in new tools as they arrive. It is from 2023 so the most recent tools are absent, but the frame itself still works.
useLayoutEffect를 활용한 산발적 마커 렌더링 최적화
- Blog · Author: Tecoble (Woowacourse) · 5기_센트
- One-line summary: Map markers appearing in stutters, explained and fixed through the difference in when two hooks run.
- Read this if: You know the difference between useEffect and useLayoutEffect but have never seen a case where it actually mattered.
The difference between the two hooks reads abstractly in documentation; here there is a visible symptom. Markers were appearing in fragments rather than all at once, and the cause was execution timing relative to the browser paint. The alternative approach the author considered and the reason for not adopting it are both written down, so the reasoning survives. It has the form a performance improvement post ought to have.
Design — Deciding What Belongs in State
Most complexity in frontend comes from getting state wrong. The four posts here approach that point from different angles.
선언적 프로그래밍에 대한 착각과 오해
- Blog · Author: 문동욱 (Evan Moon)
- One-line summary: Repeatedly demonstrating, across several examples, that using particular syntax or libraries does not make code declarative.
- Read this if: You have described chained array methods as writing declaratively.
The misconception this targets is precisely identified: replacing a loop with map is a syntax swap, not a shift in thinking. In its place the post defines declarative as expressing the logical relationships between data transformations, then rereads JSX, union types, and data pipelines through that definition. Where it arrives — folding modeling that makes impossible states unrepresentable into declarative thinking — is the payoff. Afterward you can tell which parts of your own code are declarative and which merely look it.
상태에서 관계로: 선언적 오버레이 패턴(Declarative Overlay Pattern)
- Blog · Author: 문동욱 (Evan Moon)
- One-line summary: Handling modals and confirmations as functions that return a value rather than as several state variables.
- Read this if: Every additional modal in your codebase adds two or three more boolean flags.
Read it as the previous post's principle applied to a specific problem. Keeping open state, result, and loading as separate variables produces invalid combinations; the point of the pattern is to make those combinations unconstructible in the first place. The analogy to the browser's built-in confirmation dialog makes it click quickly. It uses one library as its example, but the pattern itself transfers regardless of tooling.
동일성은 왜 프로그래밍에서 가장 어려운 문제인가
- Blog · Author: 문동욱 (Evan Moon)
- One-line summary: Four cases where reference equality, structural equality, and domain identity collide at system boundaries and produce bugs.
- Read this if: You have needed to explain why memoization is not taking effect, or why the same object is treated as different.
The central perspective is that sameness is not a property of the data but a contract the developer declares each time. In frontend this shows up daily in dependency arrays, cache keys, and list keys, so it is not somebody else's problem. It also compares how several languages have tried to surface the distinction in their type systems, which widens the view. Being recently written, the examples are close to the tooling in use now.
공식 팀에서의 에러 헨들링
- Blog · Author: Tecoble (Woowacourse) · 4기_자스민
- One-line summary: Consolidating error handling scattered across components into ErrorBoundary plus a custom error code scheme.
- Read this if: try and catch are repeating in every component and you want to clean it up.
The core is a design that splits error handling into replacing the UI and executing specific logic. That split is what lets components go back to concentrating on rendering, and this kind of boundary-setting is only learnable from someone who actually did it. There is also a custom hook for handling async errors declaratively, which makes it useful at implementation level. The classification into server, runtime, API, and network errors is worth lifting directly.
Layout and Readability — On Screen and in Code
[CSS] 성배 (Holy Grail) 레이아웃 (Flexbox, Grid)
- Blog · Author: Engineering Blog by Dale Seo
- One-line summary: The classic header-footer-sidebar layout implemented twice, once with Grid and once with Flexbox, and compared.
- Read this if: You assemble CSS layouts by feel and end up writing them differently every time.
Building the same result two ways and comparing is what makes this good. Why the Grid version is more concise and where the Flexbox version is still the right call are contrasted in code, which gives you a selection criterion. Touching on the table-and-float era also helps you understand what today's syntax actually solved. Short and practical — the kind of thing you reopen when you need it.
우리는 왜 어떤 코드를 읽기 쉽다고 느낄까
- Blog · Author: 문동욱 (Evan Moon)
- One-line summary: Readability explained through working memory and chunking rather than personal taste.
- Read this if: You want to say "this is hard to read" in a code review and back it up.
Readability arguments turn wasteful because neither side can produce evidence. This post builds that evidence by drawing on research into working memory capacity, how experts recognize patterns as chunks, and how visual structure affects comprehension. The definition of good code as code that leaves only the problem's inherent complexity and removes the rest works directly as a review standard. It is not frontend-specific, but it is especially useful when setting criteria for splitting components, which is why it is on this list.
Related Posts and Tools on This Blog
- Web performance and Core Web Vitals
- CORS errors actually explained
- How browsers work — the rendering pipeline
- Web performance optimization and Core Web Vitals
- Tools: CSS quiz · regex tester · JSON formatter