世界を動かす技術を、日本語で。

Lit: 高速で軽量なウェブコンポーネントを構築するためのライブラリ

概要

  • Lit はWeb Components標準に基づき、最小限の拡張で開発効率を向上。
  • 5KB程度 の軽量ライブラリで、高速レンダリングを実現。
  • カスタムエレメント として、どんなフレームワークやHTML環境でも利用可能。
  • スコープドスタイルリアクティブプロパティ など、便利な機能を標準搭載。
  • デザインシステムや大規模アプリ構築にも適した 拡張性と保守性

Litの特徴とメリット

  • Web Components標準 の上に構築され、余分なボイラープレートを削減。
  • リアクティブなデータバインディング宣言的テンプレート をサポート。
  • 機能ごとに設計が洗練 されており、将来のウェブ標準進化にも対応。
  • 圧倒的に軽量 な設計(約5KB、minified & gzipped)。
  • UIの動的部分のみを更新 するため、仮想DOMの差分処理が不要。
  • Web Components として、どのHTML環境やフレームワークでも利用可能。
  • デザインシステム再利用可能なコンポーネント 開発に最適。
  • 保守性・拡張性 を重視した設計。

基本的な使い方

  • import文html, css, LitElementなどを利用。

  • @customElement デコレーターでカスタム要素を定義。

  • @property デコレーターやstatic propertiesでリアクティブなプロパティを宣言。

  • renderメソッド でテンプレートを返す仕組み。

    • サンプルコード例:

      import {html, css, LitElement} from 'lit';
      import {customElement, property} from 'lit/decorators.js';
      
      @customElement('simple-greeting')
      export class SimpleGreeting extends LitElement {
        static styles = css`p { color: blue }`;
        @property() name = 'Somebody';
        render() {
          return html`<p>Hello, ${this.name}!</p>`;
        }
      }
      
    • もしくは、customElements.defineによる登録も可能。

      import {html, css, LitElement} from 'lit';
      
      export class SimpleGreeting extends LitElement {
        static styles = css`p { color: blue }`;
        static properties = { name: {type: String}, };
        constructor() {
          super();
          this.name = 'Somebody';
        }
        render() {
          return html`<p>Hello, ${this.name}!</p>`;
        }
      }
      customElements.define('simple-greeting', SimpleGreeting);
      
    • HTMLでの利用例:

      <simple-greeting name="World"></simple-greeting>
      

Litの主な機能

  • Custom Elements として、ブラウザが標準要素と同様に扱う。
  • スコープドスタイル をShadow DOMで自動適用、CSSの競合を防止。
  • リアクティブプロパティ でAPIや内部状態を直感的に管理。
  • 宣言的テンプレート は、タグ付きテンプレートリテラルを活用。
  • ビルド不要、カスタム構文不要、シンプルなHTML+JS記述。

利用シーンと拡張性

  • どんなサイトやアプリにも インタラクティブな機能 を追加可能。
  • デザインシステム として全チームで共通利用できるコンポーネント群を構築。
  • 静的サイトの段階的な拡張大規模アプリの部分的なリファクタ にも最適。
  • Web Components の採用で、フレームワーク依存を最小化し、長期的な保守性を確保。

コミュニティ・学習リソース

  • ライブチュートリアル で、インストール不要ですぐに体験可能。
  • Lit Discord で開発チームや他ユーザーと交流。
  • Bluesky で最新情報をチェック。
  • GitHub でイシュー提出やコード閲覧・コントリビュート。
  • Stack Overflow で質問・回答による知見共有。

まとめ

  • Lit はシンプル・高速・拡張性を兼ね備えたWeb Componentsライブラリ。
  • 保守性や共有性が高いUI構築 を目指すプロジェクトに最適な選択肢。

Hackerたちの意見

もう3年もLitを使ってるけど、ウェブコンポーネントAPIの中ではこれが一番だと思うよ。

同じく。実際、外部依存を避けたい環境で手動でいくつかウェブコンポーネントを作ったことがあるんだけど、その要件がなくなったら、LitElementに変換するのがすごく簡単で、使いやすさも全然違った。シャドウDOMも取り入れたけど、デフォルトではあるものの、正直言って面倒なことも多い。今はシャドウDOMなしでLitElementを使ってるけど、それでも全然問題ないよ。

Litのメンテナーだよ。そろそろ寝る時間なんだけど、質問があれば答えるよ!今夜Litがフロントページに出てきた理由はわからないけどね :)

どのウェブプラットフォームの機能が欠けてるせいで、ウェブコンポーネントがReactと競争できないのか、気になるな(アプリ開発の話ね、ウィジェットじゃなくて)。

こんにちは!質問じゃないけど、感謝のメッセージを送りたい。フルの「Lit」パッケージはあまり使ってないけど、「lit-html」はめちゃくちゃ便利。ほとんどの個人サイトで使ってる。使わないと半分を再発明する羽目になって、最初から使っておけばよかったって気づくんだ。このコマンドはほとんどのプロジェクトで使ってるよ:curl -L https://cdn.jsdelivr.net/npm/lit-html@3/lit-html.js -o ${project}/lit-html.js フレームワークを使ってる感じは全然しないし、バニラJSや有効なHTMLから逸脱することもないから、普通の文字列テンプレートやJavaScript関数を使うのと同じくらいの認知負荷で済むんだ。他のフロントエンドツールにはそういうのは言えないね。Litのもう一つ好きなところは、CDNバンドルを使えば、ビルドステップなしで簡単に実験したり、機能を使ったりできるところ。

Litみたいなのがウェブコンポーネントの標準に組み込まれる噂はある?ウェブコンポーネントはブラウザネイティブだからいいけど、リアクティビティをサポートしてないのが、振り返ってみると大きな見落としだと思う。これが普及を妨げてるんだよね。Litはウェブコンポーネントからの進化がすごくわかりやすいからいいよ。

プロパティはリアクティブなの?例の中でdocument.querySelectorを使ってnameを再割り当てできる?

すごい仕事ありがとう。再レンダリングと状態を持つサードパーティコンポーネントの相互作用について、はっきりした情報が見つからないんだ。状態を持つデータテーブルのウェブコンポーネントをテンプレートで使っているとしたら、テンプレートが再レンダリングされるたびに再作成されてしまうの?(内部状態が失われるの?)

ここにいるのは、Litに感謝を伝えたくて!シンプルな使い方から複雑な使い方まで、本当に使いやすいです。時々、なんでもっと広まってないのか不思議に思いますね…

ここに来てくれて嬉しいし、Litという素晴らしいツールに感謝!フレームワークに邪魔されることなく、フレームワークから求めるものが全て揃ってる。もう完全に気に入ってて、仕事や個人のアプリは全部これで作ってるし、何年もそうしてるよ。2022年に書いたこの記事を読んでみてね:「Web Components & Litの始め方」 https://medium.com/gitconnected/getting-started-with-web-com...

自分が投稿したわけじゃないけど、誰かが昨晩言及してたよね。 https://news.ycombinator.com/item?id=45107388 誰かが調べて、気に入って投稿したんだと思う。

ちょっと気になるのは、Litに関するサーバーサイドレンダリング(SSR)の進展があるかどうか。これが今Svelteを試してる理由の一つなんだ。自分にとってLitはReactの非効率さを解消してくれる存在だったけど、Svelteもそのギャップを埋めてる気がするし、SSRもあるし、他にも良いところがたくさんある。でも、LitとWeb Componentsの哲学は好きなんだ。時々、SvelteみたいだけどLitを裏で使ってるフレームワークがあったら、両方の良いところを兼ね備えてるように思う。

ここにはシャドウDOMについてのコメントがたくさんあるから、私の意見をまとめておくね。はい、LitはデフォルトでシャドウDOMを使ってる(良い理由があると思う!)し、コンポーネントごとにオフにすることもできるけど、それにはいくつかの課題があるよ。シャドウDOMは基本的に、コンポーネントの内部DOMの詳細のためのプライベートなDOMツリーの枝なんだ。フレームワークは、コンポーネントのテンプレートで定義されたDOMと、子として渡されたDOMの違いを暗黙的に持ってるけど、その違いは他のコードやブラウザ、CSSには見えない。これは良い面も悪い面もある。別のツリーがあることで得られる最大の利点は、「子」ノードが何かを識別できることだよ。それがライトDOMの子たちなんだ。子を内部から分けられるようになると、スロットを作れる。スロットは、内部の穴で、子がレンダリングされる場所だよ。シャドウDOMのようなものがないと、スロットは持てないし、スロットがないと相互運用可能な構成ができないし、実用的なコンテナ要素も持てない。子を要素に配置する方法が必要なんだけど、それがその要素のDOMと混同されないようにしないといけない。だから、私にとっては、カプセル化やスタイルのスコープよりも、相互運用可能な構成が最も重要な機能だと思う。それがLitがデフォルトでシャドウDOMを使う理由なんだ。これがなかったら、特別な.childrenプロパティが必要になって、Litのコンポーネント構成が他のものと互換性がなくなっちゃう。だけど、スタイルのカプセル化は開発者にとって大きな痛手になることが多い。特に、既存のシステムにウェブコンポーネントを統合しようとすると、全ページのスタイルシートがあるからね。これが多くのデザインシステムがウェブコンポーネントに移行するのを妨げてる理由の一つだよ。だから、私は「オープンスタイル可能なシャドウルート」っていうものを提案したんだ。これがあれば、外側のスコープからスタイルがシャドウルートにカスケードできるようになる。スタイルのカプセル化を壊しつつ、スロットを維持できる方法なんだ。これが必要だってブラウザのベンダーを納得させるのは難しいけど、早く進展があることを期待してるよ。

フロントエンドの仕事をしてた時、Litは本当に神のような存在だった。コンポーネントやアプリを作るのに邪魔にならないし、すごく助かる。比較すると、Angularは化け物だし、Reactは古いブラウザの機能に合わせて作られてて、今は惰性で残ってるだけって感じ。

どの古いブラウザの機能を指してるの?もう少し詳しく言ってくれるか、リンクを貼ってくれる?

だからこそ、Aureliaフレームワークが好きなんだ。コンポーネントモデルが直感的で、カスタム要素やデコレーターみたいな標準を取り入れてるのがいい。AngularのボイラープレートやReactのフックのゴチャゴチャと比べると、AureliaはもっとシンプルなJS/HTMLに近いコードが書ける。Aureliaが大手フロントエンドの名前ほど注目されなかったのは残念だけど、開発者体験は本当にしっかりしてるよ。

「Reactは古いブラウザの機能のために設計されていて、今は慣性で残っているだけで、本質的な品質によるものではない。」これを聞くと年を感じるし、ReactがInternet Explorerをサポートしてることで有名なのも納得だわ(笑)。

もうLitは必要ないかな。最近はライブラリなしでウェブコンポーネントをそのまま使ってる。サーバー上でJSXみたいなテンプレートシステムがあると、めっちゃ楽だよね。ウェブコンポーネントを使う理由の一つは、ただのJavaScriptだからってこと。アップグレードや非推奨のことを考えなくていいしね。もちろんサーバー上ではそういうのもあるけど、管理が楽なのがいい。

個人的には、litは自分で実装することになる機能をうまく抽象化してくれると思う。コード全体に手動で書かなくて済むし、DOMに追加するための処理も楽になるからね。

ウェブコンポーネントの素晴らしいところは、自分に合った方法で作れるところだよね。でも、ネイティブのウェブコンポーネントAPIは多くの人が期待するような開発者体験はないんだ。すごく低レベルだからね。Litはその上に宣言的なリアクティビティを提供してくれる。

「html」タグ付きテンプレートリテラルとJSXを書くことの間に、実際的な違いはあまりないと思う。JSXにはコンパイルステップもあるしね。

仕事でプロジェクトにlitを使ってたけど、もうそれを扱わなくていいのは最高だね。実際のアプリケーションのために別の重いコンポーネントフレームワークがあるから、誰かが履歴書を最適化したいからって理由で二つも使うのは面倒だった。理論上はすごく良さそうに見えたけど、シャドウDOMが悪化させる一つのことはA11yで、要素のIDがスコープされちゃって、他の要素にリンクすべきもののdescribe-byやlabel-forが欠けてるのが本当に面倒。もちろん、これはスキルの問題でもあるけどね。

LitではシャドウDOMはオプションだから、コンポーネントごとに無効にすることもできるよ。

これらのウェブコンポーネントをReactのコードベースに統合するのはかなりひどかった。Litの問題というより、ウェブコンポーネント全般の問題だと思う。特定の重要なこと、例えばフォントサイズを除いて「スコープ付きスタイル」があるから、古いReactのコンポーネントをウェブコンポーネントに置き換えると、ちょっとした不具合がたくさん出るんだ。DX的にも、かなり失ったと思う。ツールがもっと良くなるか、私たちがもっと理解できるようになると思うけど、今のところは本当に面倒だね。

Lit用に軽量な状態管理ライブラリを作ったんだけど、これも258行で直感的なんだよね。自分で複雑なウェブアプリを作るときに、たくさんの(ネストされた)コンポーネントが相互にやり取りするのに使ってる。なんでLitがもっと人気が出ないのか理解できないんだ。自分にとっては、基本的にReactみたいだけど、ブラウザにもっとネイティブで、ボイラープレートが少なくて、レンダリングも速いから。慣れるまでに少し時間がかかるけど、慣れたら全然制限されないよ。

Litを基本から再実装するのは、どうやって動いているかを学ぶのにすごく良い方法だよ!コア機能は意外とシンプルで、主にプラットフォームのAPIに頼って重い処理をやってるから、テンプレートの解析とかね。昔、litに積極的に貢献してた頃に、研究用に使えるlit-htmlの代替実装を作ったんだ。 https://github.com/ruphin/lite-html このスレッドを見てると、みんな自分の実装を持ってるみたいで、それを聞けて嬉しいよ。誰でも再現できるくらいシンプルな解決策には価値があると思う。

大きなフロントエンドプロジェクトでLitコンポーネントを使ったけど、楽しかったし、自分の選択に満足してるよ。シャドウDOMは全く使ってない。プロジェクトはConverse.jsというXMPPチャットクライアントで、2013年にBackbone.jsで作られた古いプロジェクトなんだ。最初にlit-htmlを聞いたときに、全てのテンプレートを置き換えて、その後lit-element(今は「lit」)が出たときにプロジェクトをそれに書き換え始めた。このアプリは、Reactなどの他のフレームワークに依存する多くの異なるウェブサイトに統合されていて、Converse.jsがウェブコンポーネントだからこそ、これが簡単になるんだ。興味があれば、GitHubリポジトリはこちらだよ: https://github.com/conversejs/converse.js デモはここでできるよ: https://chat.conversejs.org/ XMPPアカウントが必要だから、プロバイダーはここを見てね: https://providers.xmpp.net/

2年前にブログの小さなコンポーネントにLitを使ったんだけど、その後はほとんど無視してたんだ。最近、新しい機能を追加する必要があって更新したんだけど、いつもみたいに「バージョンがめちゃくちゃ古い」ってことがなかったのがすごく嬉しかった。

混乱してるんだけど、過去10年間で2年ごとに新しいメジャーバージョンが出てるよね。(2015年にPolymer 1、2017年にPolymer 2、2019年にLit 1、2021年にLit 2、2023年にLit 3。)

ウェブコンポーネントを直接使って、普通のHTML要素のように操作することもできるよ。フレームワークを追加する必要はないし、シャドウDOMを使う必要もない。Typescriptは、CustomElementRegistryを拡張することで「customElements.get」にインテリセンスを追加することもできるよ。

数年前にプロジェクトでLitを使ったんだけど、すごく気に入った。ReactコンポーネントやシャドウDOMとの相性にちょっとした問題があったけど、基本的にはシンプルだったと思う。私が気に入った点の一つは、独自のものを再発明するのではなく、標準を通じてWebComponentsを実装・使用することに焦点を当てていたことだね。