talkDOM：DOMへのメッセージ転送を提供する小さな実行環境

現代のフロントエンド開発では、多くの場合、インタラクティブウェブインタフェースの構築には重いJavaScriptフレームワークが必要とされています。年月が経ち、フレームワークはより複雑になりつつあり、コンポーネント、状態管理システム、ビルドプロセス、そして大きな実行雑多を導入しています。<https://github.com/eringen/talkdom> だが、ウェブにはすでに優れたプラットフォームがあります：HTML + DOM + HTTP。talkDOMの意欲はシンプルで、「要素間メッセージポリシーとは何か」である。htmlは小さなメッセージ交換言語であり、要素は送信用と受け取り用とを表現します。これは、javascripthandlerで何回も繋げることはなく、デリケートに動作しません。ボタンが押されたときにポストデータの通信メッセージ:posts get:/posts アップデートリストの適用:内内容としてコンテンツの代替は、多くの操作がpipelineデザインと関連します。ポリシーの設計には、Unixパイプ、Smalltalkキーワードメッセージ、およびメッセージ転送システムの影響を受けていることがわかります。UIの複雑な動作を非常に少ないコードで表現できるという話題です。「トースト」全体に対するメッセージは各要素に投げられます。リスナはオペレーションに承認する操作のみを選択できます。これにより、DOMの更新には最小のセキュリティが付加されます。talkDOMは、HTTP通信やDOM更新など、必要とする機能を提供しています。<GET>/<POST>/PUT/<DELETE>等のリクエストタイプと更新として<インナー適用>:内等の操作は含まれています。サーバーからのレスポンスヘッダーのX-TalkDOM-Triggerを使用して、JavaScriptコードを埋め込むことなくUI要素を修正することも可能です。<ポスト>/<リスト>/apply:INNERなどと操作が複数つながることで、パイプラインに友好的であり、UI動作としてはプログラミング言語に近づいていることを示しています。このソフトウェアは少数ですが数十行のJavaScriptのみです。talkDOMには何らかの理由で多くのフロントエンドフレームワークを代わりません。それはサーバーサイドからのリスアウトとダッシュボード、管理パネル、や遅延エンハンションがベストプラクティックであることを示しています。

Modern frontend development often assumes that building interactive web interfaces requires a heavy JavaScript framework. Over the years, frameworks have grown increasingly complex, introducing components, state management systems, build pipelines, and large runtime bundles. https://github.com/eringen/talkdom But the web already has a powerful platform: HTML + the DOM + HTTP. The idea behind talkDOM is simple: What if DOM elements could send messages to each other? Instead of wiring JavaScript handlers everywhere, HTML becomes a small message-passing language. Elements act as senders and receivers, and interactions are expressed declaratively. The result is a tiny runtime (only a few kilobytes) that enables fetching data, updating DOM fragments, composing pipelines, polling endpoints, and controlling navigation — all from HTML. In talkDOM, elements communicate using Smalltalk-style messages. A sender contains a sender attribute: Load Posts And somewhere in the page there is a receiver: When the button is clicked: A message is sent to posts A GET request is performed The response is piped to list The list's content is replaced This message: posts get:/posts | list apply:inner can be read almost like a sentence: "Posts, get /posts, then list apply the result as inner content." One of the key features of talkDOM is message pipelines. Multiple operations can be composed using |: posts get:/posts | transform apply:json | list apply:inner Each step can return a value (or a promise), which is passed to the next step in the pipeline. This design is inspired by: Unix pipes Smalltalk keyword messages message passing systems Pipelines allow complex UI behaviors to be expressed with surprisingly little code. Receivers are simply DOM elements with a receiver attribute. Receivers can also belong to multiple groups: Messages sent to toast will target all matching elements. Receivers can optionally restrict what operations they accept: This adds a small layer of safety to DOM updates. talkDOM provides built-in methods for HTTP requests and DOM updates. Example: Load Supported request methods: get: post: put: delete: And update operations: inner append text outer Servers can trigger client-side actions using a response header: X-TalkDOM-Trigger Example response header: X-TalkDOM-Trigger: toast apply:"Saved!" text This allows the server to instruct the client to update UI elements without embedding JavaScript. Receivers can automatically poll an endpoint. This will fetch /posts every 5 seconds and update the receiver. Polling stops automatically if the element is removed from the DOM. talkDOM also supports history-aware navigation. Posts When clicked: The request is executed The content is updated The URL is pushed to browser history Back/forward navigation replays the same message chain. Receivers can optionally persist their content in localStorage. After page reload, the content is restored automatically. talkDOM emits lifecycle events after operations: talkdom:done talkdom:error Example: document.addEventListener("talkdom:done", e => { console.log("operation finished", e.detail); }); This makes it easy to hook into the runtime when needed. Projects like HTMX, Unpoly, and Turbo have shown that many interactive interfaces can be built without large frontend frameworks. talkDOM explores a slightly different direction. Instead of attribute-based APIs like: hx-get="/posts" hx-target="#list" hx-swap="inner" talkDOM uses a message syntax: posts get:/posts apply:inner This makes interactions: composable pipeline-friendly closer to a programming language HTML becomes a small DSL for UI behavior. talkDOM was built with a few goals in mind: Tiny runtime No build step Progressive enhancement Composable interactions Minimal JavaScript The entire runtime is just a few hundred lines of JavaScript. talkDOM is not trying to replace full UI frameworks. It is best suited for: server-rendered applications dashboards admin panels progressively enhanced pages Where the server remains the primary source of truth. The web already provides a powerful programming model: documents events HTTP the DOM Sometimes the best tool is not another abstraction layer, but a small runtime that lets the platform speak for itself. talkDOM is an experiment in that direction: turning HTML into a tiny message-passing language for building interactive interfaces. The project is available on GitHub: https://github.com/eringen/talkdom