JavaScriptをHTMLだけで置き換える

 (htmhell.dev)
24 ポイント 投稿者 GN⁺ 2025-12-29 | 5件のコメント | WhatsAppで共有
  • Webで JS依存の機能をHTML/CSSで置き換える 最新の方法を紹介
  • details・summary、datalist、popover などの標準要素を活用して、アコーディオン、自動補完、モーダル、オフスクリーンナビゲーションを実装
  • このようなアプローチは ダウンロード・評価・メモリ使用量を削減し、性能とユーザー体験を改善
  • 各機能ごとに CodePenの例、MDNドキュメント、ブラウザー互換性情報 も提供
  • JSは本当に必要な領域にだけ使い、HTML/CSSの進化した機能を積極的に活用すべき

HTMLとCSSでJS機能を置き換える

  • 長年にわたり JavaScript は、HTMLやCSSだけでは実装できない機能を担ってきた
    • しかしHTMLとCSSの機能が拡張されたことで、一部のJS機能は ネイティブなWeb技術で置き換え 可能になった
  • JSはダウンロード・展開・評価・メモリ保持が必要なため、置き換え可能な機能は HTML/CSSへ移す のが効率的
  • JSは複雑なロジックに集中し、単純なUI制御は HTML/CSSに委ねる 方向を提示

アコーディオン / 展開コンテンツパネル

  • details と summary 要素で、JSなしでもアコーディオンを実装可能
    • コンテンツをクリックして開閉でき、open 属性で初期状態を指定
    • 同じ name 属性を使うと 1つのパネルだけが開く
  • CSSでスタイリングしたり、JSで開閉を制御したりすることも可能
  • 関連資料: MDN details ドキュメント、CodePenの例、ブラウザー互換性表

自動補完候補入力欄

  • input と datalist の組み合わせで 自動フィルタリングされるドロップダウン を実装
    • 入力時に候補リストが自動でフィルタリングされる
    • テキスト以外にも number、time などさまざまな入力タイプをサポート
  • Firefoxは現在テキストベースの入力のみ対応しており、モバイルではアクセシビリティ上の制約がある
  • 関連資料: MDN datalist ドキュメント、SitePointチュートリアル、ブラウザー互換性表

モーダル / ポップオーバー

  • popover および popovertarget 属性で、JSなしのモーダル・ポップオーバーを実装
    • auto、hint、manual の3つのモードを提供
    • auto は外側クリックや ESC で閉じ、manual は手動でのみ閉じる
  • FirefoxおよびiOSは hint モードをサポートしていない
  • 関連資料: MDN popover ドキュメント、Chromeブログ、CodePenの例、アクセシビリティ関連動画

オフスクリーンナビゲーション / コンテンツ

  • popover 機能を活用して オフスクリーンナビゲーションメニュー を実装可能
    • nav 要素を使って意味づけし、CSS translate で画面内外へ移動
    • 外側クリックで閉じられ、popover="manual" で手動クローズ設定も可能
    • ::backdrop 疑似要素で背景を半透明にできる
  • 関連資料: MDN Popover API、Chromeブログ、CodePenの例

結論

  • JSの強力さは認めつつ、必要な場所にだけ使う べき
  • 最近のHTML/CSSの進化により JSなしの代替手段が多数登場
  • さらに多くの例は、著者のブログ記事「Replace JS with No-JS or Lo-JS Options」で確認可能
  • JS最小化と性能最適化 によるユーザー体験の改善を強調

関連記事

5件のコメント

 
labeldock 2025-12-29

こうした試みは、たまに自分がオーバーエンジニアリングしているのではないかと省みるきっかけにはなるが、要求事項が豊富な実務の観点では、ほとんど曲芸に近い。
 
skageektp 2025-12-29

> ** と ** 要素で、JSなしでもアコーディオンを実装可能

何か内容が途中で切れている気がします
 
xguru 2025-12-29

修正しておきました〜！
 
shakespeares 2025-12-29

限界があるのは明らかですし、AIが本格的に有効になった時点で……こういうリファクタリングをする必要があるのでしょうか？
JSコンテンツのブロックのような部分も考慮しているのでしょうか？
 
GN⁺ 2025-12-29
Hacker Newsの意見
  • すべての例をインラインで入れていないのが惜しい
    CodePenのリンクの代わりに、HTMLの代替例をページ内に直接載せていたら、ずっと説得力があったと思う
    • 完全に同感。FooMaker v1.0みたいなものをクリックすると、肝心の一般的な使用例はなくて、的外れな例外ケースだけ見せられることがよくある
    • 最初は25年前の記事かと思った。ディザリングされたGIFが完全にレトロな雰囲気
    • 自分もインライン例がなくて少しもどかしかったけれど、これがゲストブログ記事ならある程度は理解できる
  • <details> / <summary> タグの可能性は本当にすごい
    ほとんど何でもできるのに、たいていのコンポーネントライブラリはこれを無視している
    aria属性も不要で、アクセシビリティも最初から備わっている
    • 昔はcmd+f検索で閉じたdetails内のテキストを見つけられないのが欠点だったが、今は**hidden="until-found"**属性とイベントで解決できる
    • ただしアニメーション処理は厄介。display切り替えのトランジションをブラウザが標準ではサポートしていない
    • ctrl+fで検索するとdetailsが自動で開く機能もある
    • <details> はGitHubのようなMarkdownベースのサイトでも動く。長いログを折りたたんで見やすく投稿できる
    • 純粋なCSSだけでも実装できる。例としてGo101ドキュメントでは「+」を押して展開できる。さらにタブパネルのデモもある。Modern CSSの力を見せている
  • 要点は「no JavaScript」ではなく、HTMLがすでに忘れられた機能（フォーム、ダイアログ、検証、ナビゲーションなど）を扱っているということ
    本“You Don’t Need JavaScript”を書いていて感じたのは、JSは新機能を追加するというより、プラットフォームの既存機能を補完することが多いということ
    • こういう本がもっと増えてほしい。単にフレームワークを学ぶのではなく、問題解決中心の本が必要だ
    • 昔はブラウザ対応が不十分で開発者が回避策を作り、それが標準のように定着したのだと思う。最近はCSS機能のリリース速度が上がっていて、masonryレイアウトも実験段階に入っている
  • ほとんどのHTML機能は素晴らしいが、<input> と <datalist> は実用面では不十分
    ユーザーはタイプミス許容、補助テキスト、モバイルUXなどを期待するが、datalistはそれを満たせない
    • datalistで表示テキストと実際の値（value）を分けられないのがいちばん不便
    • 多くの場合はselectの方が適しているが、selectには検索機能がない
    • デフォルトスタイルがあまりに無骨で見栄えが悪い
    • Androidではドロップダウン自体が表示されない
    • デバイスごとに挙動が違うので、結局JSを追加する必要がある。HTMLだけでは互換性地獄にはまる
  • 最近いくつかフロントエンド面接を受けたが、相変わらずReact中心のJSスキルしか評価されない
    HTMLのセマンティックな使い方やアクセシビリティはほとんど重視されていない
    • チームがReactを使っているなら、DOM APIを直接使う人はチーム適合性の面で落とされるかもしれない
    • 別のCSSファイルを使うとコンポーネントはずっとすっきりする。Tailwindは悪くないが、面接で使いたいとは思わない
    • HNの外ではHTML純粋主義に関心のある人はほとんどいない
  • CodePenのリンクだけ貼って、例をページ内に直接入れていないのが気になる
    「HTMLだけで実装しよう」という記事なのに外部サービスに依存しているのは矛盾しているように感じる
    • 個人的には問題ないと思う。CodePenはブックマークとシンタックスハイライトが便利。ただし**リンク切れ（link rot）**のリスクはある
    • それでもインライン例とCodePenリンクを両方提供してくれたらよかったと思う
    • HTMLだけを強調しながら2MBのCodePen UIを読み込ませるのは、UX的に逆説的だ
  • カスタマイズ可能なselect機能がまもなく登場する予定で期待している
    WHATWG stage 3にあり、JSベースのドロップダウンの悪夢のような実装を置き換えられそう
    Chromeブログの記事参照
  • 純粋なHTMLは慣れていて気楽だが、今日の機能的なWebアプリを作るには限界がある
    HTMXやPhoenix LiveViewのような代替も使ってみたが、完全な解決策ではない
    結局、現代的なJSを受け入れるのが現実的だという気がする
    • JSを少し使うだけでも、HTMLだけのときよりずっと先まで行ける。今のWebはJSの乱用で使い勝手の悪化が深刻だ
    • HTMXを必要以上に複雑に考えているように思う。サーバー状態を基準にhx-select / hx-targetを使えばシンプルに保てる
    • <marquee> タグはECサイトの横スクロール実装に向いていたのに、今はJSで無理やり実装している。HTMLがもっと多くのUIパターンを標準でサポートしてほしい
    • Reactでmarquee効果を実装しようとしてトークンをかなり浪費した。完全なループでもなく、ただのアニメーションの小細工だった
    • ElixirとPhoenixを使うならGleamも検討に値する。JSにコンパイルされる
  • HTMLとJSは目的の異なるツールだ
    複雑なWebアプリにはJSが必須だが、HTMLだけで可能な領域も多い
    • Google EarthのようなものにJSが必要なのは当然だが、Gmail程度ならHTMLでも可能だと思う。ブラウザベンダーのトレンドや誇大宣伝がHTMLの発展を妨げている
    • htmxはJSと補完関係にある。JSONの代わりに構造化ハイパーテキストをやり取りするのが核心だ。実際、htmx + 少しのJSでかなり複雑なアプリをすばやく作れた
    • HTMLはもっと多くの機能を標準搭載すべきだ。たとえばHTTP verbsのサポート、入力コントロールの改善など
    • JS-heavyなサイトの多くは、実はhtmxで十分置き換え可能だ。道具の選択は習慣の問題でもある
  • 「JSがアコーディオンやナビゲーションメニューを管理する必要はない」という意見に共感する
    しかしJSは今やデータ収集と広告トラッキングの中核ツールになってしまった
    JSなしでもビッグテックが同じレベルの監視と広告サービスを実装できるのか気になる
    結局、JSへの反感は単なる技術問題ではなく、広告エコシステムへの不信から来ている