LabHub

ブログ

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

한국어English日本語

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

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

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

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

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

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

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

Closure

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

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

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

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

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

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

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

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

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

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

React 효율 개선을 위한 Fiber Reconciler

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

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

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

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

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

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

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

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

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

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

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

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

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

공식 팀에서의 에러 헨들링

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

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

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

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

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

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

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

シリーズの他の記事

コメント

まだコメントはありません。

ログインするとコメントできます