Tailwind PlusにVanilla JavaScript対応を追加

 (tailwindcss.com)
1 ポイント 投稿者 GN⁺ 2025-07-27 | 1件のコメント | WhatsAppで共有
  • Tailwind PlusのUIブロックが、今やVanilla JavaScriptだけで完全に動作可能に
  • ReactやVueなどのフレームワークなしでもインタラクティブなコンポーネントを利用可能に
  • @tailwindplus/elementsというカスタムエレメントベースのライブラリが新たに提供開始
  • さまざまなプラットフォームおよびフレームワークとの互換性を備えた使いやすさを強調
  • すべてのTailwind Plus顧客が今すぐこの機能を利用可能

Tailwind PlusでVanilla JavaScript対応を導入

Tailwind Plusの多くのUIブロック（たとえばダイアログ、ドロップダウン、コマンドパレット）は、実際に使うにはJavaScriptが必要だった。これまではReactまたはVueの利用者でない場合、こうしたUIブロックのインタラクションのために自分でJavaScriptを書く必要があった。

しかし今では、すべてのUIブロックが完全な機能、アクセシビリティ、インタラクティブ要素を備え、プレーンなHTMLのサンプルでもすぐに動作する。つまり、JavaScriptフレームワークに依存せずに、ドロップダウン、コマンドパレット、ダイアログ、ドロワーなど、さまざまなインターフェースブロックをプロジェクトのどこでも活用できる。

@tailwindplus/elements: 中核ライブラリ

この変化を可能にしたのが、@tailwindplus/elementsライブラリだ。このライブラリはTailwind Plus顧客向けの専用パッケージで、ヘッドレスなカスタムエレメントのコレクションとなっている。

  • カスタムエレメントは、HTMLコードに<script>タグを1行追加するだけでどこでも適用可能
  • 複雑なインタラクション、フォーカス管理、キーボードアクセシビリティ、ARIA属性の付与などを自動処理
  • スタイリングはTailwind CSSユーティリティクラスや手書きのCSSで自由にカスタマイズ可能

主な活用例

  • ドロップダウン: <el-dropdown>, <el-menu>などのカスタムエレメントで構成し、追加のJavaScriptなしで動作
  • セレクト: <el-select>, <el-options>, <el-option>エレメントで高度な選択コンポーネントを実装可能
  • コマンドパレット: <el-command-palette>, <el-command-list>などの構成で完全な機能を実現

これらのカスタムエレメントは、ARIA属性、フォーカス移動、キーボードナビゲーションを自動処理し、Webアクセシビリティも強力に支援する。

フレームワーク統合とプラットフォーム依存性の最小化

  • HTMLのみを使う環境はもちろん、Svelte、Rails(Ruby on Rails)、Reactなどさまざまな環境と統合可能
  • Svelteの例: <el-autocomplete>に双方向バインディングを追加する例を提供
  • Railsの例: フォーム送信時にネイティブフォームコントロールのように<el-select>の値がサーバーへ送信される
  • Reactの例: 既存のHeadless UIやReact Ariaと異なり、フレームワーク依存なしで利用可能

最新のWeb標準とブラウザ互換性

  • Elementsは最新のWebプラットフォーム機能（Web Components、Custom Elementsなど）を積極的に活用し、軽量な構成とネイティブな体験を提供
  • 必要に応じてpolyfillも自動でバンドルし、Tailwind CSS v4と同じブラウザサポート範囲を確保
  • Web標準が広く普及するほど、Elementsの容量も自然に軽くなっていく見込み

真の汎用性: 「HTMLこそが最小公倍数」

HTMLはすべてのWebフレームワークの「最小公倍数」であり、Elementsを使えばTailwind PlusのHTMLベースUIブロックがどんな環境でも一貫して動作する。

  • Svelte、Rails、Reactなどでの実際の活用例とコードも提供

リリースと利用案内

まとめ

Tailwind Plusユーザーなら今後は、どんな環境であっても、複雑なJavaScriptを書かずに強力でアクセシブルなUIを簡単に実装できるようになる。

関連記事

1件のコメント

 
GN⁺ 2025-07-27
Hacker News のコメント

  • `` のような長くて階層的な Tailwind の class 命名を見ると、CSS だけでなく別の階層構造システムまで学ばなければならない状況になったと感じる

    • 大規模な Tailwind プロジェクトを開くたびに、1 行にとてつもなく長い class 属性の一覧が出てくるのを見ると、いつも感心してしまう

      
...

    • Tailwind 以前は、出会うたびにほぼすべての Web デザイナーがこういうシステムをそれぞれ独自のやり方で作っていた CSS は理論上は十分に強力で、Tailwind なしでも十分可能だ ただ実際には CSS には大きな欠点がある。真価を発揮するには意味論的なモデルを別途設計しなければならないが、デザイナーは文書構造や情報設計以上に、雰囲気や感情の表現に集中することが多い こうした感情的な概念を論理的な規則としてマークアップするのは非常に難しいか、不可能ですらある Tailwind は、もともと皆がやっていたこと、つまり「意味」に対する抽象的なモデリングの代わりに、bold や red のようにすぐ適用できる規則を公式化したにすぎない

    • こういうコードを見て「わあ、これは本当にきれいなコードだ！」と言える人がどうやって生まれるのか不思議に思う Tailwind がどうしてここまで人気になったのかわからないし、純粋な CSS を学ぶほうが本当に良いと思う 最近の CSS は本当にずっと良くなっている

    • 実際のプロジェクトでは、class を読みやすいようにグループ化して使うようになる たとえば、

      こんな感じでコーディングする 今は手動で分類しているが、こういうフォーマットを自動化してくれるツールがあればいいのにと思う

    • Tailwind はもともと utility class スタイルの CSS フレームワーク、いわば「Bourbon on Steroids（強化版 Bourbon）」のような発想から始まったように見える ところが人々はサンプルコードを予想以上に素直に受け入れ、そのまま積み上げて使うようになった 2018 年に新しい大規模プロジェクトで Tailwind を採用してみたが、以前は .button、.button-primary のように Tailwind utility をベースにクラスを積み上げれば保守しやすく HTML もきれいだった しかしチームで実際に使ってみると、最初から用意されている utility class をそのまま積み上げるほうがずっと速くて簡単だった コードの優雅さを気にしなければ、デザインの一貫性も保てるし、Photoshop で見たとおりにそのまま実装できた Bourbon 参考

  • Web 標準ベースの Web Components を使った方式だ ブラウザ標準対応なので JS フレームワークなしでも動作する 開発者が Web Components を多く活用するようになったのはうれしい Web Components とは？ (MDN)

    • 長いこと待ち望んでいた変化だ 以前は互換性を気にしなくていい個人プロジェクトで Web Components をいじっていたが、今ではメインストリームのライブラリでも採用されるのが本当にうれしい

    • 12 年間 Web Components の必要性を言い続けてきたが、React、Angular、Svelte などのフレームワーク陣営の反応は鈍かった Web Components とスコープ付き JS/TS と bundler（vite や rollup くらい）で十分で、Shadow DOM や全体再レンダリングのような無駄なオーバーヘッドは必要ない

    • 2014 年ごろ Polymer を触っていたとき、「transclusion」という用語が印象に残った 当時は何だかすごいものに思えたが、今では意味もよく覚えていない

    • 会社の広告コード用 hook で Web Components を試してみたが、個人的には少し期待外れだった コード実行のトリガーは簡単だが、API 自体はあまり良くない

  • 人気 UI コンポーネント界隈を見ていると、なぜベースがどれも「headless」ではなかったのか疑問だった Web Components はずっと前からあったのに、こうしたアプローチが一般的でなかったのが不思議だった フレームワーク別（SHADCN など）のライブラリは、バージョン互換性に応じてそれぞれ別々にドキュメントも用意し、特定環境に縛られるわりに実際の完成度も低い Headless UI をベースにしておいて、必要ならフレームワークごとのラッパーを作る方式のほうがよい気がする もちろんもっと複雑な事情が多いのはわかるが、そんな世界を夢見てしまう

    • React、Vue、Svelte などの人気フレームワークでは、Web Components はバンドルサイズやランタイム負荷の面で単なるオーバーヘッドだ 特に React では世界観の不一致のせいで機能や使い勝手を犠牲にするか、あるいは精巧なバインディングを作る必要があり、そもそも Web Components を使う理由がなくなる SSR のような高度な機能でも問題が起きることが多い React が支配的な状況で、あえて Web Components を使いたいとは思わない それに Headless 方式は、実装が複雑だったりオーバーヘッドが大きかったりすることも多い

  • 誰かが Tailwind チームに十分な資金を提供してくれたら、金銭面を気にせず Tailwind エコシステム全体が無料提供されて、世界はもっと良くなるのではと想像してしまう Tailwind Plus のようなさまざまな場所との深い統合の機会があまりにも多く失われたのが惜しい 昔 37signals が Jeff Bezos から投資を受けて VC の心配から解放された例を思い出す

    • Tailwind チームはすでに想像以上に成功している さらに多くを作って拡張しようとするのは、お金が必要だからではなく自然な野心のためだ 私の印象では、Tailwind（オープンソース）はビジネス全体の一部であり、収益の出る別のプロジェクトも作っていきたいのだと思う Laravel とも比較できそうだ

    • 正直、最近は AI で Tailwind コンポーネントを簡単に生成できるので、Tailwind Plus のような有料コンポーネントをわざわざ買いたい気持ちは薄れている 昔の Tailwind UI の時代には実際にお金を払って買ったが、今はむしろ Claude のような AI に直接 UI を作ってもらえばライセンスの心配もなくて楽だ これからどんなビジネスモデルが通用するのか気になる

    • 37signals に関して言えば、個人的には創業者が誰かに報告しながら働くほうが、むしろ良かったのではないかと思う

    • 実際には「Tailwind のすべての体験」はすでに無料で提供されている 足りない深い統合というのが何を指すのか疑問だ Tailwind Plus（商用製品）は、単に既製のテンプレートとビルド済みコンポーネントのセットにすぎない すばやく始めたい開発者には便利だが、結局のところ Tailwind さえあればすべて自分で作れる

    • 具体的にどんな統合を意味しているのか気になる

  • 今あまり興奮しすぎないほうがよさそうだ 以前は Vue もサポートしていたのに、今では事実上見捨てられたように見える

    • これこそが Vue サポートだ フレームワークがあまりにも多いので、すべてに合わせたカスタムラッパーを作るのはほぼ不可能だ Web Components を使えば一度開発すればどの環境でも動作し、結局はフレームワーク側が Web Components 対応（つまりまもなく HTML 対応）をしっかり行えば十分だ

    • Vue の Web Components サポートは非常に良く、React 19 もついにしっかり対応し始めた Web Components のエコシステムが混沌としているのは事実だが、こういう形で「すべてのフレームワークで再利用できるコンポーネント」を提供するのこそ Web Components の真のキラーアプリだ これを「バニラ JavaScript 向け」ではなく「ついに全フレームワーク対応」と宣伝しないのが不思議だ

    • 彼らは Figma デザインライブラリも運営していたが、今はなくなっている デザイナーと協業するうえではかなり残念な事例だ

    • 名前のとおり tailwindcss を志向している

  • custom elements のこうした活用例は面白いと思ったが、Tailwind ではこれが有料機能なのは少し驚きだ 感覚としては custom elements は無料で、フレームワーク連携だけ有料のほうが自然に思える Tailwind Plus の価格設定

    • 約 $250,000 をかけてこのライブラリを開発したので有料なのだろう 無料で提供して保守まで続けるのは不可能だったはずで、優秀なエンジニアには正当な報酬が支払われるべきだ

    • Tailwind Plus は UI コンポーネントとテンプレートを集めた有料コレクションだ TailwindCSS 本体は Bootstrap のようなスタイリングツールにすぎない

    • もうひとつの有料機能としては SSO なども有名だ なぜ有料なのか直感的には納得しにくいが、導入の意思決定時期を意図的に遅らせるための戦略だ

    • こういうものを有料で売るのは少し変だ 無料が前提の Web 開発の世界で、フレームワークを一生使うためにサブスクリプション料金を払う構造なら違和感がある まるで Postgres が月額料金を要求するようなものだ ただ、価格体系を見ると一生使える買い切り型ではある この方式がどれほどうまくいくのか気になる

  • Alpine.js が tailwindcss plus の custom block elements から消えたようだ コード例にもう alpinejs が出てこないのを見てがっかりした 今は

    こんなふうに置き換えられている Alpine を使っていた立場としては、コピペ用のサンプルをそのまま使えなくなって残念だ

  • この機能は tailwind 無料ユーザーにもぜひ開放してほしい とても興味深くて一度試してみたいのに、無料では体験すらできないのが残念だ それでもオープンソースは常に資金援助が簡単ではないとわかっているので、tailwind には感謝している いつかオープンソースに寄付し、貢献する側になりたい

  • `` のように Elements で高度なコマンドパレットのようなものも作れると言っているが、実際にはその機能をそのコンポーネント自体に直接追加しているからこそ可能になっている

  • 最近 Tailwind をもっと使うようになって、その利便性と、デザインシステム設計の煩雑さを抽象化してくれる強みは認めるようになった ただ長期的に見れば、自前のデザインシステムとコンポーネントライブラリに投資するほうが、DX、柔軟性、美的言語、依存関係の面でずっと充実した解決策になる