Skip to content
Published on

韓国の開発ブログ名文キュレーション 4 — フロントエンド、直接開いて確認した14本

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
シェア
Authors

フレームワークの使い方ではなく、その下の層を扱う記事

フロントエンドは道具の入れ替わりがもっとも速い分野で、だから使い方の記事はすぐ古びます。このリストは意図的にその下の層を扱う記事で埋めました。言語の挙動、ブラウザの挙動、設計の判断といった、道具が変わっても残るものです。

選定方法はシリーズ全体と同じです。検索で候補を見つけたあと、記事を直接開いて確認し、そのなかから説明が具体的で再現可能なものを選びました。このリストは編集者の選択であり、ランキングではありません。 閲覧数や人気は測定していませんし、測定する手段もありません。

出典は個人ブログを優先しました。個人ドメインとGitHub Pagesのブログの比重が高いのは、この分野で長い呼吸の記事がそちらに集まっているからです。WoowacourseのTecobleから2本入れていますが、その2本はそれぞれ具体的な改善の記録とチーム単位の設計判断で、個人の記事では代えがたいものでした。

韓国国外の読者に一点。リンク先は韓国語です。 読むには韓国語が必要ですが、論旨の大半を支えるコード例はどの言語でも読み取れます。

リンクは2026-08-12に直接開いて確認しました。個人ブログの記事は消えたりURLが変わったりすることがあります。

言語と型 — フレームワークより長く残る層

Closure

  • ブログ · 著者: PoiemaWeb (이웅모)
  • 一行要約: クロージャを実行コンテキストの上で説明し、情報隠蔽や部分適用やカリー化といった実際の使いどころまでつなげます。
  • こんな人に: クロージャを面接用に暗記したが、なぜそう動くのかは説明できない人。

クロージャの解説記事の大半はカウンタの例で終わりますが、この記事はなぜ値が保たれるのかをレキシカル環境で説明します。クロージャは言語が提供する機能というより実行コンテキストの構造から生じる現象だ、という視点がこの記事の核です。だから読み終えるとクロージャだけでなくスコープ全般が整理されます。古い文書ですが扱う層が言語の基礎なので今も有効で、韓国語のJavaScript資料のなかでは参照文書として使うのにもっとも整っています。

자바스크립트는 왜 프로토타입을 선택했을까

  • ブログ · 著者: te-ing.log (velog)
  • 一行要約: プロトタイプベースの設計を、範疇と意味をめぐる哲学的な議論から始めて言語の挙動へつなげます。
  • こんな人に: プロトタイプチェーンは知っているが、なぜこの方式なのか腑に落ちていない人。

アプローチが独特な記事です。クラスとインスタンスという区分がどこから来たのか、その区分への反論が何だったのかを押さえたうえで、JavaScriptの選択をその文脈に置きます。この種の記事は気取りだけで終わりがちですが、後半でホイスティングとクロージャとスコープチェーンという具体的な挙動に着地するのでバランスが取れています。同意しなくても、言語設計を見る角度をひとつ得られます。技術書に疲れたときに読むのにも向いた種類です。

타입스크립트 타입 정복: Conditional Types

  • ブログ · 著者: Front J · JonghwanWon
  • 一行要約: 条件型とinferキーワードをジェネリクスと絡めて説明し、ネストした配列の平坦化のような実例で締めます。
  • こんな人に: ユーティリティ型を使うだけで、自分で作ったことのない人。

条件型はTypeScriptで難易度が急に上がる地点で、だから良い韓国語の説明は貴重です。この記事は三項演算子に似た構文から出発して、inferで型を取り出す段階まで階段を作っています。例が実際に書きそうなものなので、概念が抽象のまま残りません。標準ライブラリのユーティリティ型がどう作られているかを理解できるのも副産物です。

타입 시스템은 왜 증명처럼 동작하는가

  • ブログ · 著者: 문동욱 (Evan Moon)
  • 一行要約: 型検査がエラー検出ではなく論理的な証明として働くという視点を、カリー・ハワード対応まで踏み込んで説明します。
  • こんな人に: 型を面倒な検査器としか見ていなかったが、最近考えが変わり始めた人。

型が命題でプログラムが証明だという対応は、分かると型設計の見え方が変わります。この記事はその対応を関数とタプルとユニオンとジェネリクスという馴染みの構文にひとつずつ当てはめて説明するので、理論が日々書く構文と切り離されません。形式論理と集合論とラムダ計算に触れますが必要なぶんだけ取り出すので、敷居は高くありません。不可能な状態を型で塞ぐという実務の技法がなぜ強力なのか、その根拠もここで得られます。

ブラウザとバンドル — コードが実行されるまで

브라우저 렌더링 과정 (리플로우와 리페인트)

  • ブログ · 著者: Minjae Kim
  • 一行要約: HTMLとCSSがパースされてレンダーツリーになる過程と、何がリフローを呼び何がリペイントで終わるのかを整理します。
  • こんな人に: アニメーションがカクつく理由を説明しなければならないのに、根拠を出せない人。

レンダリングパイプラインの解説はよくありますが、この記事は最適化の地点までつなげます。どのプロパティを変えるとレイアウトの再計算が起きて、どれが合成の段階で処理されるのかを区別してくれるので、コードで何を変えるべきかが明確になります。長さがちょうどよくチームのウィキにリンクを貼っておくのに向き、新入社員のオンボーディング資料としても使えます。フレームワークに依存しない層なので有効期間が長いのも利点です。

React 효율 개선을 위한 Fiber Reconciler

  • ブログ · 著者: Jason Kang
  • 一行要約: スタックリコンサイラの限界とFiberがそれをどう変えたかを、中断可能な作業単位という概念を中心に説明します。
  • こんな人に: Reactがレンダリングを先延ばしにすると聞いたが、何をどう先延ばしにするのか分からない人。

同期的な再帰レンダリングがなぜ問題だったのかから出発するので、Fiberの設計が必然として読めます。作業を分割し優先度を付け中断して再開するという三つがどう噛み合うか、そして現在のツリーと作業中のツリーを二重に持つ理由まで扱います。Reactの並行機能がなぜあの形なのかを理解するには、この層を一度は見ておく必要があります。分量が重すぎないので出発点として適しています。

차세대 번들러 비교 및 분석 (feat. webpack, rollup, esbuild, vite)

  • ブログ · 著者: bepyan blog · Edward Kim
  • 一行要約: バンドラ四種を機能比較ではなく、それぞれが登場した理由の順で説明します。
  • こんな人に: バンドラを選ばなければならないのに、何がどの問題を解こうとして作られたのか分からない人。

系譜で説明するというのがこの記事の決定的な長所です。タスクランナーから始めて各ツールがどんな不便への応答として出てきたのかを順に見せるので、比較表を暗記しなくても判断できます。ツールが変わり続ける分野で、こういう構造で書かれた記事は新しいツールが出てもその位置に嵌めて理解させてくれます。2023年の記事なので最近のツールは入っていませんが、枠組み自体は今も使えます。

useLayoutEffect를 활용한 산발적 마커 렌더링 최적화

  • ブログ · 著者: Tecoble (Woowacourse) · 5기_센트
  • 一行要約: 地図のマーカーが途切れ途切れに描かれる問題を、フックの実行タイミングの違いで説明して解決します。
  • こんな人に: useEffectとuseLayoutEffectの違いは知っているが、実際に分かれる場面を見たことのない人。

二つのフックの違いはドキュメントで読むと抽象的ですが、この記事には目に見える症状があります。マーカーが一度に描かれず分かれて現れる現象で、原因はブラウザが画面を描く前か後かという実行タイミングの違いでした。代案として検討した別の方法と、それを採らなかった理由まで書かれていて、判断の過程が残っています。性能改善の記事が備えるべき形式を備えた記事です。

設計 — 何を状態として置くか

フロントエンドの複雑さの大半は、状態の取り方を誤るところから生まれます。この節の4本はその地点をそれぞれ違う角度から扱います。

선언적 프로그래밍에 대한 착각과 오해

  • ブログ · 著者: 문동욱 (Evan Moon)
  • 一行要約: 特定の構文やライブラリを使うから宣言的になるのではない、ということを複数の例で繰り返し示します。
  • こんな人に: 配列メソッドをチェーンして宣言的に書いたと言ったことのある人。

この記事が狙う誤解は正確です。ループをmapに置き換えるのは構文の交換であって思考の転換ではない、ということです。代わりにデータ変換のあいだの論理的な関係を表現することが宣言的だという定義を立て、JSXとユニオン型とデータパイプラインをその定義で読み直します。不可能な状態を作れないようにモデリングすることまで宣言的な思考に含める箇所が、この記事の到達点です。読み終えると自分のコードで何が宣言的で何がそうでないかの区別がつきます。

상태에서 관계로: 선언적 오버레이 패턴(Declarative Overlay Pattern)

  • ブログ · 著者: 문동욱 (Evan Moon)
  • 一行要約: モーダルや確認ダイアログを、複数の状態変数ではなく値を返す関数として扱うパターンを提案します。
  • こんな人に: モーダルがひとつ増えるたびに真偽値の状態が二つ三つ増えるコードを持っている人。

前の記事の原則を具体的な問題に適用した事例として読むとよいでしょう。開いているかどうかと結果とローディング状態をそれぞれ変数に置くと有効でない組み合わせが生まれますが、その組み合わせをそもそも作れなくするのがこのパターンの要旨です。ブラウザ標準の確認ダイアログと同じ使い心地になる、という喩えが理解を速めます。特定のライブラリを例に挙げますが、パターン自体は道具に関係なく移せます。

동일성은 왜 프로그래밍에서 가장 어려운 문제인가

  • ブログ · 著者: 문동욱 (Evan Moon)
  • 一行要約: 参照の同一性と構造的な同一性とドメインの識別子がシステムの境界で衝突して生むバグを、四つの事例で扱います。
  • こんな人に: メモ化がなぜ効かないのか、なぜ同じオブジェクトが別物として扱われるのかを説明する必要があった人。

同じであることはデータの性質ではなく開発者が毎回宣言する契約だ、という視点がこの記事の中心です。フロントエンドではこの問題が依存配列とキャッシュキーとリストのキーとして毎日現れるので、他人事ではありません。複数の言語がこの区別を型システムで表に出そうとした試みまで比較するので視野が広がります。最近書かれた記事なので、例もいま使っている道具に近いところにあります。

공식 팀에서의 에러 헨들링

  • ブログ · 著者: Tecoble (Woowacourse) · 4기_자스민
  • 一行要約: コンポーネントのあちこちに散らばっていたエラー処理を、ErrorBoundaryとエラーコードの体系にまとめた過程を記録します。
  • こんな人に: tryとcatchがコンポーネントごとに繰り返されていて整理したい人。

エラー処理を画面を差し替えるものとロジックを実行するものに分けた設計が、この記事の核です。その区分のおかげでコンポーネントが描画に集中できるようになるのですが、この種の境界の引き方は実際にやった人の書いた記事からしか学べません。非同期のエラーを宣言的に扱うためにフックを作った部分まであって、実装レベルの参考になります。サーバーエラーとランタイムエラーとネットワークエラーを分けた分類体系も、そのまま持ってきて使えます。

レイアウトと可読性 — 画面とコードの両方

[CSS] 성배 (Holy Grail) 레이아웃 (Flexbox, Grid)

  • ブログ · 著者: Engineering Blog by Dale Seo
  • 一行要約: ヘッダーとフッターとサイドバーのある古典的なレイアウトを、GridとFlexboxの二通りで実装して比較します。
  • こんな人に: CSSのレイアウトを勘で合わせていて、毎回違う書き方になってしまう人。

同じ結果を二つの方法で作って比べる構成が、この記事を良くしています。Grid側がなぜ簡潔なのか、Flexbox側がどんな状況でなお有効なのかがコードで対比されるので、選択の基準ができます。テーブルとfloatで作っていた時代に触れているのも、いまの構文が何を解決したのかを理解する助けになります。短く実用的で、必要なときにまた開くことになる種類です。

우리는 왜 어떤 코드를 읽기 쉽다고 느낄까

  • ブログ · 著者: 문동욱 (Evan Moon)
  • 一行要約: 可読性を好みではなく、作業記憶とチャンキングという認知の構造で説明します。
  • こんな人に: コードレビューで読みにくいと言うのに、根拠を添えたい人。

可読性の議論が消耗的になるのは、双方とも根拠を出せないからです。この記事は作業記憶の容量、熟練者がパターンを塊として認識する仕方、視覚的な構造が理解に与える影響といった研究を引いて、その根拠を作ります。良いコードとは問題そのものの複雑さだけを残して残りの負担を減らしたコードだ、という定義はレビューの基準としてそのまま使えます。フロントエンドに限った内容ではありませんが、コンポーネントの分割基準を決めるときに特に有用なのでこのリストに入れました。

このブログの関連記事とツール

シリーズの他の記事

Discuss on Twitter • View on GitHub