index.htmlで済むなら、それが一番強いと思っている
2026年6月26日
小さなWebアプリを作るとき、自分はかなりの頻度で index.html だけで済ませようとする。
もちろん、何でもかんでも素のHTML/CSS/JavaScriptで作るべきだと思っているわけではない。実際、このポートフォリオはAstroで作っている。ページ数が増えたり、コンポーネントを分けたくなったり、Markdownで記事を管理したくなったりすると、フレームワークや静的サイトジェネレータを使う意味はかなり大きい。
ただ、自分用の小さなWebアプリや、研究・学習のためのちょっとしたツールを作るときは、話が少し変わる。
その規模なら、index.html で済むならそれが一番強い、と思っている。
技術選定でまず考えること
Webアプリを作るとき、普通は「どのフレームワークを使うか」「どこにデプロイするか」「データベースは何にするか」みたいな話になりがちだと思う。
でも、自分が小さなWebアプリを作るときは、まず逆のことを考える。
どの技術を足すかではなく、何を持たずに済ませられるか。
サーバーを持たずに済むか。
データベースを持たずに済むか。
認証を持たずに済むか。
ビルド環境を用意せずに済むか。
ネイティブアプリとして作らずに済むか。
あとから保守し続けなくても、普通に開ける形にできるか。
小さな道具を作るときに大事なのは、必ずしも高機能にすることではない。作り切れること、使い始められること、しばらく放置しても壊れにくいことの方が大事な場面がかなりある。
index.html は、とにかく開きやすい
index.html で作る一番のメリットは、単純に楽なことだ。
ブラウザで開けば動く。
開発サーバーを立てなくていい。
Node.jsのバージョンを気にしなくていい。
依存パッケージをインストールしなくていい。
ビルドコマンドを覚えていなくてもいい。
もちろん、最近のフレームワークは便利だし、きちんと作るならその恩恵は大きい。ただ、自分用の小さなツールでは、フレームワークを導入することで削減できる工数より、環境や依存を増やすコストの方が気になることがある。
さらに最近は、AIのコーディング補助もある。素のHTML/CSS/JavaScriptで書くときの面倒くささは、以前よりかなり下がった。ちょっとしたUIや状態管理なら、フレームワークを入れなくても十分に書き切れることが多い。
だから、自分はまず index.html でどこまで行けるかを考えがちだ。
これは「フレームワークを使わない方が偉い」という話ではない。小さいものを小さいまま作るために、あえて構成を増やさない、という話に近い。
配布しやすいことは、思ったより大事
index.html の強さは、作るときだけではない。配るときにも強い。
ファイル一式を渡せば、基本的にはブラウザで開ける。相手に開発環境を用意してもらう必要がない。自分の別PCで開くときも楽だし、少し手直ししたいときも中身を追いやすい。
自分が作る小さなWebアプリは、本格的なサービスというより、道具に近いことが多い。研究用の解析補助、学習用の単語帳、ちょっとしたタスク管理、UIの実験。そういうものは、壮大なアーキテクチャより、すぐ開けることの方がうれしい。
半年後にまた使おうとしたとき、リポジトリを開いて、依存関係を復元して、ビルドして、エラーを直して、という流れになると、それだけで少し使う気が削がれる。
その点、index.html はかなりしぶとい。
PWAは、ネイティブアプリを持たないための選択肢
スマホで頻繁に使うものなら、PWAにすることも多い。
ここでPWAを選ぶのは、何かを大きく足したいからというより、ネイティブアプリとして作らずに済ませたいからだ。
iOS用、Android用、macOS用、Windows用にそれぞれ作る。
アプリストアに出す。
プラットフォームごとの差分を見る。
配布や更新の仕組みを考える。
自分用の小さな道具で、そこまで背負うのは重い。
でも、ブラウザのブックマークから開くのと、ホーム画面やDockから開けるのとでは、体感がかなり違う。Webページとして「見に行く」ものから、アプリとして「使う」ものに少し近づく。
PWAは、その中間に置けるのが良い。
Webのまま作れる。
GitHub Pagesにも置ける。
スマホのホーム画面やPCのDockから起動できる。
必要ならオフラインでもある程度動かせる。
ネイティブアプリほどの作り込みや互換性対応は持たない。でも、ただのWebページよりは道具として呼び出しやすい。このくらいの軽さが、自分の作る小さなWebアプリにはちょうどいいことが多い。
GitHub Pagesに置ける構成が好き
公開するなら、GitHub Pagesに置ける構成が好きだ。
静的なHTML/CSS/JavaScriptだけなら、そのままGitHub Pagesに置ける。無料で公開できるし、リポジトリと紐づくので管理もしやすい。サブドメインとはいえ、URLの中に自分の好きな文字列を入れられるのも地味にうれしい。
昔は無料サーバーを使っていたこともある。けれど、一定期間ごとの更新が必要だったり、サービス側の都合に左右されたりすると、個人の小さな制作物を置いておく場所としては少し不安がある。
小さなWebアプリは、作ったあとに何年も頻繁にメンテナンスするとは限らない。だからこそ、なるべく安定した場所に、なるべく単純な形で置いておきたい。
GitHub Pagesで公開できる、という条件は、自分にとってかなり大きい。
データベースは、なるべく持たない
自分は、データベースが必要になるWebアプリをなるべく作らないようにしている。
理由はいくつかある。
まず、GitHub Pagesだけでは完結しなくなる。バックエンドや外部サービスが必要になり、急に構成が重くなる。無料枠のあるサービスを使うこともできるけれど、アカウント管理、料金体系の変更、利用制限、サービス継続性など、気にすることが増える。
それに、データベースが必要なアプリは、個人情報やユーザーデータを扱うことが多い。自分はセキュリティにものすごく詳しいわけではない。だから、リスクの高い情報を預かる構成にはできるだけしたくない。
自分用のツールなら、自分の端末の中だけで完結する方が気楽だ。人に使ってもらう場合でも、サーバーにデータを送らない設計にできるなら、その方が安心して公開しやすい。
localStorageで済むなら、それでいい
その結果、データ保存はlocalStorageに寄りがちになる。
もちろん、localStorageが万能だとは思っていない。端末をまたいだ同期はできないし、ブラウザのデータを消せば消える。大事なデータや機密情報を入れる場所でもない。
でも、暗記状態、ちょっとした設定、表示モード、タスクの一時的なメモのように、消えても致命的ではない個人用データなら、localStorageで十分なことが多い。
むしろ、そこに収まる範囲に設計を寄せることで、アプリ全体が軽くなる。
「全端末で同期したい」「複数人で共有したい」「ログインして使いたい」と思い始めると、途端に考えることが増える。それが必要なものも当然あるけれど、自分が作る小さな道具では、そこまでしない方がちょうどいいことも多い。
技術選定は、作り切るための設計
自分にとって技術選定は、流行っている技術を選ぶことではない。
そのアプリを作り切れるか。
使い始められるか。
半年後にも開けるか。
人に渡したとき、相手が困らないか。
自分が面倒を見きれる範囲に収まっているか。
そういうことを考えた結果、index.html、PWA、GitHub Pages、localStorageという構成に寄ることが多い。
もちろん、必要ならフレームワークも使う。Astroも使うし、もっと大きなものを作るならバックエンドやデータベースも選択肢に入る。
でも、小さなWebアプリを作るときは、まずこう考える。
index.html で済むなら、それが一番強い。