- HTML、CSS、JavaScriptのみを使った基本的なWeb開発技術の説明
- ビルドツールやフレームワークなしで、標準的なWeb技術だけでサイトやアプリケーションを実装する方法を紹介
- Web ComponentsやモダンなCSS機能を活用した構造化とスタイリングの方法を扱う
- フレームワークの複雑さや保守負担なしに、シンプルな開発環境と長期的な利点を追求
- すでにWeb標準技術を習得している開発者を主な対象とするチュートリアル
Plain Vanilla Web 概要
Web開発において、ビルドツールやフレームワークなしで、標準的なWeb技術だけを使ってサイトやアプリケーションを作るための主要な手法の概要
- エディタ、ブラウザ、Web標準だけを活用する環境を説明
- 初期設定やサーバーサイドロジックなしで本番環境へデプロイできる構成を紹介
扱うトピック
1. コンポーネント(Components)
- Web Componentsを使って、HTML、JavaScript、CSSだけで高水準の構成要素として組み合わせる方法
- ReactやVueのようなフレームワークのコンポーネントアプローチを置き換える方法
2. スタイリング(Styling)
- 最新のCSSの強力さを活用し、CSS Modules、PostCSS、SASSが提供する利便性を置き換える方法
- 古典的なCSSから一歩進んだ、構造的でモジュール化されたスタイル構成の概念を提供
3. サイト(Sites)
- Web ComponentsベースでWebプロジェクトを構成し、ビルドツールやサーバーサイドなしでデプロイする方法
- 実用的でシンプルなデプロイワークフローを提示
4. アプリケーション(Applications)
- シングルページWebアプリケーションをバニラ手法だけで作る方法
- ルーティング、状態管理の方式を説明
推奨対象
すでにHTML、CSS、JavaScriptをある程度扱える開発者を対象とする
- Web開発を初めて始める人には、Odin ProjectやMDNのような基礎学習ルートを推奨
なぜバニラ方式なのか
現代のフレームワークは構造的で強力な機能を素早く提供する一方で、ツールやフレームワークの複雑性の増大と継続的な保守負担を伴う
- プレーン・バニラ方式は、短期的な利便性の一部を手放す代わりに、シンプルさと事実上ゼロメンテナンスという長期的な利点を提供
- 今日のブラウザは優れたWeb標準サポートを備えており、このアプローチは現実的に可能
1件のコメント
Hacker Newsの意見
私はもう「バニラかフレームワークか」という議論から離れて、『そもそも本当にWebサイトが必要なのか？』という視点で考えるようになった
Webアプリ、特にB2B SaaSの分野で本当にそうしたWebが必要なのかと懐疑的になり始めると、ブラウザに手を入れなくてもビジネスをかなり先まで進められることに気づく
私がWebサイトやアプリを作るのに費やしてきた時間の大半は、管理用UI/UX、つまり管理者がデータベースのフィールドを変更してアプリケーションが顧客の期待どおりに動くようにする部分に集中していた
多くの場面では、ビジネスに単純な設定テンプレート（Excelファイルなど）を渡し、その結果をSQLテーブルに直接挿入・マージするほうが、はるかに速く簡単で、無駄な作業も少ない
Webは1つのUI/UXのやり方しか提供しない。メールやプレーンテキストファイルのほうがむしろ柔軟だ
特に政府機関など、買い手側がよく分かっておらず、しばしば過大な費用を払ってしまう問題がある
購買担当者は何が必要なのかについてもっと教育を受ける必要がある
現実の納骨壺店舗にカートがないのに、なぜ仮想店舗には必要なのか
特殊な木工工具をオンラインで購入したときも、単にフォームに入力して部品を請求書と一緒に受け取っただけで、望むならその場で支払わなくても問題なかった
オンラインでもオフラインでも多様な商取引の形が存在しており、興味深いやり方で暮らしている人たちを注意して見れば、あちこちで見つかる
少しでも保守の能力があるなら、Excelテンプレート＋簡単なカスタムスクリプトのほうがずっと柔軟になる。
最終利用者が結局は生データを扱えるレベルのユーザーなら、非常に効果的だ
そして今でもB2Bの99%はこの方式に従っている
私はフレームワークに反対しているわけではない。ただ、多くの場合は不要だと感じる
コードを1行も書く前に、なぜ100KBのJSを追加しなければならないのか、いつも不思議だった
私たちのチームは https://restofworld.org を何のフレームワークも使わずに作った
アンケート、アウトリーチ、メールでのフィードバックはいずれも、使いやすさや読む体験の面で非常に好意的だった
後からフレームワークを使うこともできるが、今のところは単なるバニラJSがとてもうまく合っている
一方には30人以上のチームで大規模なWebアプリを作っている人たちがいて、彼らはフレームワークなしで作ると言われると、すぐに大規模で必須の機能をどう処理するのか疑問を投げかける
だが答えは、その機能自体が必要ないし、ブログのような用途なので、そもそもフレームワークの必要性がないということだ
逆に、大規模Webアプリの経験がほとんどない人は、「なぜみんなフレームワークを使うのか」と考える
Webは本当に多種多様なソフトウェアの集合体だ。
だからフレームワークについて論じるときは、対象がどんな種類のソフトウェアなのかを明確にすべきだと思う
この場合、これはWordPressブログだ
WordPressという大型フレームワークを使っていて、単に静的レンダリングしているだけだ
TFAが言っているのは、ビルドツールすら使わず、最新のWeb標準だけを使うことだ。エディタ、ブラウザ、Web標準だけを使うということだ
私が働いてきた企業向けアプリでは、100KBの心配などまったく不要だった
ほとんどが複数チームで作る大規模アプリで、Reactなどを使っていた。
LOB/B2Bでは初回ページロードを気にする人は誰もいない
ユーザーは毎日そのアプリを使い、大半はブラウザキャッシュからすぐに静的アセットを利用できる
Next.jsのような賢いフレームワークを使えば、ルート単位で内容がimmutableなchunkに分割される
初期レンダリングは静的HTMLなので、ユーザーにとってハイドレーションも目立たない
ただ、バニラ vs フレームワーク論争でこういう例がいつもニュース／記事サイトなのを見ると、複雑なアプリではないのだから「自分でも最初からフレームワークは使わなかっただろう」と思ってしまう
結局、実用例としてはもっとインタラクティブなアプリが必要だ
最近はフレームワークと一貫したパターンだけを使い、ほかの依存関係は最小限にするやり方を好んでいる
iPhoneでは、戻ったときに毎回ページ全体が再読み込みされるのがあまりにも当たり前になっていた
しかし開発者は、面白半分でローディング画面、ハイドレーションされたコンポーネント、過剰なアニメーション、苛立たしいモーダルなどに執着する
また、無限スクロールはスクロールバーの位置で自分がどこにいるかを把握しにくくするので、使い勝手に致命的だ
構築に関わったことを称賛する
Mithrilなら、すべての機能を10KB gzippedで実現できる
検索機能付きのリアクティブなテーブル、ラベル・検証・エラー表示がきちんとしたフォーム、そうした振る舞いを自分で実装するくらいなら、SvelteのUIライブラリと25KBのオーバーヘッドでよくできた検証済みの製品を使えるのに、なぜわざわざ自作するのか
それにWordPressもフレームワークだ
フレームワークを使っても遅くはならない。WordPressでも何でも
速すぎる
開発者の生産性のためだ（理屈の上では）。
実際には、あまり役に立たないことも多い
このアプローチに鋭い問題点があったのか気になる
約2,000人のユーザー向けのシステムを開発しているが、彼らはリアクティブなUIをまったく気にしない
モノリスを作り、ページのリロードも気にせず、ただ仕事を片づけることに集中するのが一番だ
その動機は大きくは技術的なものではなく、ネイティブアプリの配布コストが高すぎるからだ
Webはアプリ配布の標準を安価に提供するが、UI技術としてはいまだに今ひとつだ
過去にはX11、Java、Flashなどさまざまな中途半端な試みがあり、いつかもっと快適なWebアプリ開発の方法が生まれてほしい
https://developer.mozilla.org/en-US/docs/Web/CSS/@view-transition
ほとんどのソフトウェアは120年前の機械式装置よりはるかに遅く、反応も悪い
npmパッケージを読み込む必要はないバックエンドは express/node で、コード全体は一緒にあるのに、開発環境ではサーバーがReactの基本サーバーで動き、本番デプロイでは別の形で動くので、結局おかしなビルド・運用方式が必要になり、開発サーバーの利便性（ホットリロードなど）が台無しになる
RedditやX（Twitterなど）のような大企業のSPAですら、モバイルではとても不安定だった
Twitter級でもなければ、あるいはAPIベースのプラットフォームでもなければ、そこまでSPAにこだわる必要はないと思う
何十億ドル企業を含め、誰もまともに構築できていないものを、自分ならもっと上手くやれると過信すべきではない
すべてをReactに作り直す必要はない
元記事の著者が言う高度なSPA風機能は、あくまでオプションだ
離脱した人まで調査したのだろうか
こういう世界に住みたい
私はフレームワーク以前の時代から来たが、当時はまだ未成熟で、jQueryしか知らない人も珍しくなかった
今では、post-query selector時代のフレームワークが、そのコストに見合う効果を持っているとは思えない（テストフレームワークは別で、とても良い）
私たちはReactというフレームワーク監獄に閉じ込められており、あらゆる失敗はスパゲッティ化した複雑性の結果だ
state machine はハードコードで絡まり、翻訳・圧縮・トランスパイルされた成果物は見分けがつきにくい
ソースマップも保守のための複雑性をさらに1層増やしている
フレームワークが作られた理由は認めるが、新しいエンジニアにとって、バニラJSよりフレームワークを学び続けるほうが簡単だとはとても思えない
HTMLはテキストのレンダリングを少し楽にするためのマークアップにすぎず、HTTPも同様だった
昔はtext-to-markup比率が高くあるべきだったが、今では完全に逆転している
それでも私たちは、この上にアプリ開発のすべてを載せるのが未来だと信じていたし、Reactの内部を見ても、何十年にもわたる小細工とトリックの塊だ
昔なら、Excel+VBでアプリを作ったり、PDF+PostScriptの組み合わせでアプリを作るような、無茶な試みに見えただろう
そうしてきたのだから、JSが数MB、何メガバイトも消費するのを過剰だと感じる
データの変更にUIが即座に反応することで、これを手動でリスナーを作り、diff更新をして、イベント解除までやると、ほとんど手動メモリ管理のような感覚になる
jQuery時代がそうで、ミスも多かった
コンポーネントベースで、ビューを宣言的にモジュール化できるようになったら、そのとき初めてバニラJSに戻るが、今のところは絶対に無理だと思う
決定的な要素が足りない
ReactやAngularはES2015以前には確かに意味があった
その後はフロントエンドフレームワークの変化にうんざりした
Reactの中でさえ、componentのやり方や状態管理の方法が変わり続けている
私はWeb Componentsにはまだ賛成できない
特に @scoped や import {type:css} など最近の機能があっても、単に要素を静的にレンダリングしてから、最新のJSで動的に更新するほうがずっと意味があると思う
Web Componentsのやり方の大半には懐疑的で、ReactやSvelteのようなフレームワークの外側で革新し続けるべきだと信じている
Web Componentsが自分の運営する複数のサイトで役立つと感じたことはない
Shadow DOMについて各ページで何十回も言及されるが、それは導入したことで生じた問題の解決が大半だ
自分のアプリ専用コンポーネントなら、Shadow DOMの問題もない
Web Componentsではバックエンド側でこれをどう処理するのか気になる
独自タグに追加メソッドを付けたり、更新ロジックをコンポーネント内部にカプセル化したりできる
軽量ライブラリ中心、あるいは自分で書ける実践方法が必要だ
HTMXには良い部分もあるが、それでもなお script タグのように振る舞うし、URL/メソッドはHTMLにだけ明示し、
hx-targetのようなものはJS側でdata-attribute として指定するだけで十分だ使わないHTMX機能まで全部含まれるのは望まない
私はWeb Componentsが、他のフレームワークでコンポーネントと呼ばれるものの代替だとは思わない
複合値（Object、Arrayなど）を属性に入れられず、ボイラープレートが多すぎて、リアクティビティもない
私は signals[1] 方式でバニラJS系のコーディングをしている
すべてのW3C標準が正解ではなく、XHTMLの失敗例を参考にすべきだ
[1] https://wrnrlr.github.io/prelude/
http://youmightnotneedjs.com
これは趣味でWebページを作る人にはよく合うアプローチのように思える
フレームワークは標準化、ベストプラクティスを組み込んだ設計、そして素早く開発を始めるためのものだ
Webサイト自体に本質的な価値があるわけではなく、その内容をどう効率よく公開し、期限どおりに正しく開発するかが重要だ
そういう意味でフレームワークは現在と将来のコストを下げてくれる
実際の大企業では意思決定が流行・慣習・人気フレームワークに対する防衛的意識に左右され、複雑性増大による生産性低下は追跡されず、むしろ誤った意思決定のほうが個人やチームのインセンティブに合ってしまう
つまり、「合理的選択であるはずだ」という論理だけでフレームワーク選定を正当化することはできない
そもそもフレームワークを使ったからといって自動的にベストプラクティスが守られるわけでもなく、むしろさらに肥大化して遅いシステムができることもある
本当に素晴らしい資料だ
Webを作るなら、基礎技術の原理をきちんと理解し、Webプラットフォームを最大限活用できるべきだと思う
その上で、ビルドシステムやフレームワークを使うかどうかは、トレードオフだけ理解したうえで自由に選べばよい
個人的にRemix(/React-router v7+)が好きなのは、Web標準の哲学とつながっているからだ
つまり、より少ない開発でより多くのことができる（サーバーデータの変更をHTML formだけでも可能にできる）
また https://every-layout.dev も勧めたい。ブラウザネイティブのCSSだけで実現する、高性能・アクセシビリティ・柔軟性を備えたレイアウトのさまざまなテクニックを学べる
私は1998年からプロとしてWeb開発に携わっている
先週、完全にバニラだけで小さなプロジェクトを実装したが、とてもうまく動いている
Mastodonの長いスレッドを書くためのWebツールだ
作っている間ずっと、「フレームワークなしで、自分は何か間違ったことをしているのでは？」と感じていた
ほかの人たちはみんなフレームワークを前提にしている雰囲気だ
Splinter, splinter.almonit.club, 興味がある人は参考にしてほしい