Lit - 高速で軽量な Web コンポーネント作成ライブラリ

 (lit.dev)
12 ポイント 投稿者 xguru 2025-09-05 | 4件のコメント | WhatsAppで共有
  • Web コンポーネント標準をベースに、リアクティビティ、宣言的テンプレート、最小限のボイラープレートのみを追加
  • 5KB級の小さなサイズと高速レンダリングにより、変更された UI 部分だけを更新してパフォーマンスと読み込み速度を最適化
  • すべての Lit コンポーネントはネイティブ Web コンポーネントであり、フレームワークに依存せず HTML が使えるあらゆる場所で再利用可能
  • Shadow DOMを活用してデフォルトでスタイルのスコープを制限し、CSS セレクタをシンプルにして他のスタイルとの衝突を防止
  • Reactive Propertyでコンポーネント API と内部状態をモデリングし、プロパティ変更時の効率的な再レンダリングをサポート
  • Tagged template Literalsベースのテンプレートで高速かつシンプル
  • 共有用コンポーネント、デザインシステム、ベンダーロックインを減らし保守性を高めたアプリ全体の構築まで、さまざまな Web プロジェクトで利用可能
  • チュートリアル を提供
  • GitHub

関連記事

4件のコメント

 
devstudyman7 2025-09-06

3年前から感じていますが、バニラのWeb Componentsをそのまま使うのに速く、過渡期のフレームワークのようにも感じます。遅いです..
 
cnaa97 2025-09-08

どういう意味ですか？
 
bluemir 2025-09-05

Web標準の Web Components と lit-html だけを使って運用ツールを開発していますが、把握すべき情報が最小限で済むのが良いです。lit-html で活用している機能も、event handler binding と loop templating 程度しか使っていません。（そのほかは Web 標準くらいで十分なので……）変更があると render を直接呼び出さなければならない不便さはありますが、むしろ変数の変更を自動で検知して非明示的な動作をするより、明示的な呼び出しのほうが助けになる面もあります。運用ツールということもあって、さまざまな環境への対応は優先度が低いため、そう感じているのかもしれません。
 
GN⁺ 2025-09-05
Hacker Newsの意見
  • 会社のプロジェクトでLitを使っていたことがあるが、今は使わなくなって本当に気が楽になった
    すでに重いフレームワークを使っていたのに、誰かが履歴書に一行追加したいがためにLitを入れたのが大きな負担だった
    Shadow DOMは特にアクセシビリティ（A11y）の問題をさらに深刻にした
    idのスコープが分離されることで、label-forやdescribe-byのような関連付けが壊れてしまい、かなり苦労した
    もちろん、ある程度はチームの    スキル不足    の問題でもあった
    • ReactコードベースにWeb Componentsを統合する過程は本当に大変だった。Litというより、Web Components自体の問題だと思う
      スタイルはスコープされるが、フォントサイズのような重要な部分は例外なので、差し替えるたびに小さな回帰バグが出続けた
      DXもかなり落ちたし、ツール群が改善されることを期待しているが、今はただただ疲れる状況だ
    • LitではShadow DOMはオプションなので、コンポーネント単位で無効化できる
    • 誰かが単に履歴書を埋めるために技術を導入するケースが本当にそんなに多いのか疑問がある。
      実際には、ただ新しいものを試してみたくて、特に合理化もせず導入するほうがよくある気がする
  • 私はLit向けの状態管理ライブラリを自作した（258行、https://github.com/gitaarik/lit-state）
    複雑なアプリでネストしたコンポーネント同士が相互作用する場合にもうまく動き、Reactに似ているが、はるかにブラウザネイティブで、ボイラープレートが少なく、レンダリングも速い
    なぜLitがもっと人気にならないのか理解できないほどだ
    • 私もLitの内部動作を理解するために、基本から再実装してみたことがある
      中核機能は意外と単純で、ほとんどがプラットフォームAPIに依存している
      だから誰でも自分で実装できるし、この単純さこそ大きな価値だと思う
      ちなみに私が作った代替実装は https://github.com/ruphin/lite-html
  • 私はLitのメンテナーだ。今日なぜ急にHNのトップに来たのかは分からないが、質問があれば答えられる
    • lit-htmlは本当に便利で、ほとんどすべての個人プロジェクトで使っている
      CDNから直接読み込めて、ビルドステップなしで試せるのも大きな利点だ
      他のフレームワークのように重くなく、ただVanilla JS + HTMLを書いている感覚なので、認知負荷がほとんどない
    • Shadow DOMについての話が多いので、自分の考えを整理してみる
      Shadow DOMは基本的に、コンポーネント内部のDOMを分離するプライベートツリーだ
      これによってスロット（slot）の概念が可能になり、本当に合成可能なコンポーネントを作れる
      問題は、スタイルのカプセル化が既存システムと統合する際の大きな障壁になる点だ
      そこで私は      Open Styleable Shadow Roots      という提案をした。外部スタイルが内部へ流れ込めるようにしつつ、スロットは維持する方式だ。まだブラウザベンダーを説得しているところだ
    • Litはフレームワークが邪魔をしないクリーンなツールなので、私は個人用・業務用を問わずすべてのアプリをLitで作っている
      関連して私が書いた記事もある: https://medium.com/gitconnected/getting-started-with-web-com...
    • Litのおかげで、単純なケースでも複雑なケースでも開発が楽しい
      ときどき、なぜもっと広く使われていないのか不思議に思うこともある
    • Web Components標準にLitのような機能が含まれる可能性はあるのか、という質問がある
      • Web Componentsはネイティブである点が良いが、リアクティビティが欠けているため、採用が遅いのも事実だ
      • Litはその空白を埋める自然な拡張線上にある
  • 私はConverse.jsというXMPPチャットクライアントのプロジェクトでLitを使った
    もともとはBackbone.jsベースだったが、lit-html → lit-element → lit という順で段階的に置き換えた
    今では <converse-root /> というWeb Componentとして提供されており、Reactのような他のフレームワークとも問題なく統合できる
    GitHub: https://github.com/conversejs/converse.js / デモ: https://chat.conversejs.org/
  • 最近はLitは不要だと感じている。単に素のWeb Componentsで作業するほうが楽だ
    サーバー側でJSXのようなテンプレートシステムを使えば十分快適だし、クライアントは単なるJSなのでアップグレードの心配もない
    • Web Componentsの利点は、好きなやり方で作れることだ
      ただしネイティブAPIはあまりに低レベルなのでDXに欠け、Litはその上に宣言的なリアクティビティを載せてくれる
    • 私はLitが反復的な `` 処理とDOM接続をうまく抽象化してくれると思う
      自前で実装すると面倒な部分をきれいに解決してくれる
    • 個人的には、LitのhtmlテンプレートリテラルとJSXの間に大きな違いは感じなかった
      むしろJSXはコンパイル段階が必要なので、より面倒だ
  • 私は3年間、本番環境でLitを使っている。Web Components APIの上にある最良の抽象化レイヤーだと思う
    • 私も似た経験がある
      最初は依存関係のない環境で自前のWeb Componentsを作っていたが、後でLitElementに移るとはるかに楽になった
      ただしShadow DOMはデフォルトだが、むしろ問題を増やすこともあり、今はShadow DOMなしでLitElementを使っている
  • 私は2020年から本番環境でLitを使っているが、まったく後悔していない
    最大の利点は、安定した基盤の上にあることだ
    ネイティブWeb Componentsはすべてのブラウザで安定してサポートされているので、フレームワーク入れ替えのリスクなしに開発へ集中できる
    もっと多くのチームに試してみてほしい
    ちなみにLitを扱ったHTTP 203動画もおすすめだ
  • フロントエンド作業では、Litは本当に救世主のような存在だった
    Angularは重すぎるし、Reactは古いブラウザの制約に合わせて設計されたので、今では惰性だけで残っているように感じる
    • どの古いブラウザ機能のことを言っているのか、もう少し具体的に聞きたい
    • 私はAureliaフレームワークが好きで、標準によく従っており、コードも簡潔だ
      AngularのボイラープレートやReactのフックの複雑さに比べると、はるかに直感的だ
      ただ、人気が出なかったのが残念だ
    • Reactが古いブラウザ対応のおかげで有名になったという話を聞くと、急に自分が年を取った気がする
  • 私はlit-html単体のレンダリングライブラリは好きだが、Lit全体の必要性は感じなかった
    実質的には + Web Components の組み合わせで十分だと思う
  • 私はVue 3の大規模プロジェクトで作ったコンポーネントを別のサイトでも再利用するため、Web Componentsとして配布しようとしている
    しかし、Vueの代わりにLitで作り直すことにどんな利点があるのか気になっている
    • 私はVueとLitの両方を使ったことがあるが、個人的にはVueのほうが少し良かった
      Vue 3のref/reactive状態管理は強力で、DOM依存なしにテストできる
      Litのリアクティビティはウィジェット単位なので、更新トリガーを自分で管理する必要がある
      Vueはライフサイクルが単純だが、Litでは複数のコールバックに気を配る必要があり、バグが入りやすい
      特別な理由がないなら、機能開発に集中するほうがよく、技術スタックの入れ替えはユーザーにほとんど影響しない
    • 利用者の立場では、VueでもLitでも成果物はWeb Componentsなので違いはない
      Vueはフレームワークなので機能が多く、LitはネイティブAPIにより近い形で実装する
      Vueはビルドが必要だが、Litはランタイム読み込みが可能だ
      Vueは他のターゲットにもコンパイルできるが、LitはWeb Components専用なのでよりクリーンだ
      結局のところ、チームがより慣れている技術を使うのが一番重要だ
    • 実際のところ最も現実的なアプローチは、単にWeb Componentsバンドルを作って公開し、内部は好きなように実装することだ
      利用者は内部実装には関心がなく、重要なのはサイズとAPIだけだ
      どうせ他の人たちは自分の環境に合わせてアダプターを作って使うことになる