PhysicsArchitecturePerformanceCanvas API
自前物理エンジン180行の限界点 — Matter.jsを捨てた理由と、カバーできなかったこと
更新 2026年5月27日16 分で読める
このトピックを深掘りする
Canvas vs DOM・インタラクティブUI
CanvasとDOMの使い分け・CSSインタラクション・カスタム物理エンジン・ポートフォリオ設計
全5本中 4 本目。
次に読む記事
ブラウザで動く物理エンジンを自前で書いた話
ポートフォリオサイトにMatter.jsを使わず約180行の軽量物理エンジンをTypeScriptで自作した経緯と設計判断。バンドルサイズ300KBを4KBに削減しつつ60fpsを維持した手法を解説。
Canvas vs DOM — 203個のコンポーネントで選んだ基準と実測データ
203個のインタラクティブコンポーネントをCanvas APIとDOMに振り分けた判断基準を、実例と実測データで解説する。
203個のCanvas/DOMコンポーネントで踏んだバグ Top 10 — 実データから見えたパターン
203個のインタラクティブコンポーネントを開発する過程で実際に遭遇したバグをgit履歴から集計し、頻出パターンと修正手法をTop 10形式でまとめた。
シリーズ全体の流れを見ながら、次に読む記事へ進めます。 初めての方は /start →
よくある質問
- Q. Matter.jsの代わりに自作物理エンジンを使うメリットは何ですか？
- バンドルサイズが300KBから4KBに削減でき、Tree-shakingも可能になる。さらに挙動を完全に理解しているためデバッグが速く、コンポーネントごとの物理チューニングも容易。
- Q. 166行の物理エンジンでカバーできない機能は何ですか？
- 拘束ソルバー（二重振り子など）、摩擦、スタッキング安定性、連続衝突検出（CCD）、多角形衝突（SAT）の5つ。それぞれ20〜50行の専用コードで個別に対処した。
- Q. 自作物理エンジンで何体まで安定して動作しますか？
- O(n²)の全ペア衝突検出で100体程度まで問題なく動作する。1000体を超えるとボトルネックになるが、ポートフォリオの用途では100体を超えることがほぼない。