2 ポイント 投稿者 GN⁺ 2025-07-21 | 1件のコメント | WhatsAppで共有
  • XMLUI は、Visual Basic のコンポーネント開発モデルをモダンなWebに適用し、React や CSS の知識がなくても Web アプリを簡単に開発できる
  • XMLUI はさまざまな コンポーネント を XML マークアップで手軽に組み合わせられ、リアクティブなデータバインディングテーマ管理スキーマ拡張 などをサポートする
  • Model Context Protocol(MCP) を通じて AI と協業し、開発効率の向上とコード保守性の改善が可能
  • XMLUI は複雑な React エコシステムを単純化することで、非専門家でも簡単に UI やアプリ開発ができる環境を提供する
  • デプロイと拡張が容易で、React や CSS に不慣れな開発者でも多様な Web プロジェクトや CMS 実装を行える

紹介と概要

XMLUI プロジェクトは、1990年代の Visual Basic に見られた直感的なコンポーネント組み合わせ方式を Web 環境へ持ち込もうとする試みである。当時の Visual Basic では、専門プログラマーでなくてもさまざまなコンポーネントをつなぎ合わせて有用なソフトウェアを簡単に作ることができた。一方、Web 環境ではそのレベルの使いやすさやエコシステムは実現されてこなかった。XMLUI は React コンポーネントと CSS をラップし、XML 形式のマークアップだけで Web アプリを開発できるようにする。

以下は数行の XMLUI コード例である:

<App>
  <Select id="lines" initialValue="bakerloo">
    <Items data="https://api.tfl.gov.uk/line/mode/tube/status">;
    </Items>
  </Select>
  <DataSource
    id="tubeStations"
    url="https://api.tfl.gov.uk/Line/{lines.value}/Route/Sequence/inbound";
    resultSelector="stations"/>
  <Table data="{tubeStations}" height="280px">
    <Column bindTo="name" />
    <Column bindTo="modes" />
  </Table>
</App>

このように 12 行ほどの XML だけでも、次のような処理を表現できる:

  • API 呼び出しによって Select の選択肢を自動で埋める
  • Select の値を使って 別の API からデータを取得する
  • API の結果から特定フィールドだけを抽出し、それを表形式でバインドする

XMLUI は モダンなコンポーネントベースかつリアクティブ(reactive) な特性を持ちながら、利用者は React や CSS の内部知識なしで開発・保守を行える。この点が、従来の JavaScript エコシステムが持つ障壁を下げる重要な差別化要因になっている。

コンポーネントエコシステム

過去と現在

Visual Basic の時代には、チャート、ネットワーク、データアクセス、メディア再生など多様な 構成要素(コンポーネント) を簡単にアプリへ組み込むことができた。しかし、そのような生産的なコンポーネントエコシステムは Web へ完全には移行されなかった。現在の Web では React ベースのコンポーネントが主流だが、依然として専門開発者の力量が求められる。XMLUI はこれらの React コンポーネントをラップし、誰でも簡単に使えるようにする。

ユーザー定義コンポーネント

XMLUI は 多彩な組み込みコンポーネント だけでなく、自分でコンポーネントを定義し、必要に応じて組み合わせたり再利用したりできる。たとえば、ロンドンの地下鉄駅情報を表示する TubeStops コンポーネントは次のように定義できる:

<Component name="TubeStops">
  <DataSource ... />
  <Text variant="strong">{...}</Text>
  <Table ... >
    <Column ... />
  </Table>
</Component>

TubeStops は路線名ごとに API からデータを取得し、表形式で表示する。実際のマークアップを見ると可読性が高く、100 行を超えるようになればコンポーネントへリファクタリングすることで保守しやすくなる。最近では LLM(大規模言語モデル) の支援により、コンポーネントのリファクタリングやコード保守もさらに柔軟になっている。

リアクティブバインディングと宣言的開発

XMLUI では データと UI の値の変化が自動で連動する(Reactive Data Binding)。たとえば Select コンポーネントの選択が変わると、それを参照する API アドレス(DataSourceurl)も自動で更新され、新しいデータを再取得する。この方式は Excel のセル参照に似ている。

従来型の命令的開発ではなく、宣言的(Declarative) 開発パラダイム に慣れる必要はあるが、慣れれば高速かつ直感的な開発体験が得られる。たとえば検索機能を実装する際、ボタンなしで入力ボックスの値の変化だけを使ってデータをリアルタイムに連動させ、表へ反映する構造を簡単に作れる。

テーマシステム

当初はテーマシステムへの関心はそれほど高くなかったが、XMLUI の テーマ管理機能 は非常に強力である。CSS を書かなくても、各 コンポーネントの色、背景、余白、フォントなど を変数ベースで一貫して管理できる。たとえばボタンの色をコンテキストや状態(hover など)に応じて変えて指定できる。

テーマは color-primarybackgroundColor-Button などの形で細かく制御でき、全体の UI カラーパレットを簡単に定義して、グローバルにも個別にも適用できる。

スクリプト活用

XMLUI は完全に宣言的というわけではない。Visual Basic のように、簡単なスクリプト(主に JavaScript)を部分的に導入でき、たとえば API 応答の加工(transformResult)や条件付きレンダリングなどに活用できる。これは高度な専門性がなくても、一般的な開発者であれば十分に扱える難易度である。

Model Context Protocol(MCP) と AI 協業

「いまや LLM が React アプリをそのまま作ってくれるのに、XMLUI にどんな意味があるのか?」という問いに対して、筆者は コードのアクセスしやすさ、保守性、協業しやすさ の観点から XMLUI の価値を強調している。

MCP(Model Context Protocol) は、LLM などのエージェントが XMLUI のコード・文書・サンプルを検索、理解、引用できるサーバーを提供する。 これにより、AI と開発者が同じ意味空間で対話しながら、コードの段階的な自動生成や修正を調整できるようになる。

  • 例: 特定機能の使い方、サンプル、文書、利用箇所について LLM と即座に質疑応答しながら開発を進められる

LLM と適切に協業するためのガイドラインも提供されている。たとえば、コード提案の前に事前に議論すること、文書化されたサンプルだけを使うこと、不必要なスタイリングを制限することなどである。 また、ドキュメントサイトには「How To」セクションがあり、MCP 連携によって AI からも容易にアクセスできる構造が整えられている。

コンテンツ管理と CMS への適用

XMLUI を使えば Web サイトや CMS の構築も容易で、React や Next.js の知識がなくても 日常的なページ修正や保守をしやすい。実際に XMLUI 公式サイト、デモ、ドキュメント などはすべて XMLUI で制作・保守されている。

コード、説明、リアルタイムデモを 1 つの文書でまとめて提供できるため実用的である。

拡張性

基本的に XMLUI はさまざまな React コンポーネントをラップするが、新しい外部コンポーネントのラッピングも容易である。 例として、高機能ドキュメントエディタ Tiptap を XMLUI の TableEditor として簡単にラップしている。実際に Markdown 編集で難しい部分(テーブル作成など)を、ビジュアルエディタで簡単に解決できる。

このように、これまではコンポーネント開発者とソリューション開発者の役割が明確に分かれていたが、XMLUI によって一般の開発者でも有用な UI コンポーネントを自分で拡張・組み合わせできるようになる。

デプロイ

XMLUI アプリのデプロイは 非常に簡単である。

  • 最小構成: Main.xmlui、index.html、XMLUI JS ファイルだけでよい
  • どのような静的 Web サーバーでも利用可能で、AWS S3 バケット上でもそのまま動作する
  • 複雑なサーバー環境は必須ではなく、必要に応じて追加のローカルサーバーや CORS プロキシなども構成できる

すべての人のための Web 開発

XMLUI の創設者である Gent Hito は、/n software、CData などで開発環境の参入障壁を下げることに注力してきた。

  • /n software: ネットワークコンポーネントの簡単な利用
  • CData: データアクセスの簡素化
  • XMLUI: UI 開発の簡素化

ここ 20 年ほどで Web の UI 開発はますます専門化・複雑化してきたが、XMLUI は専門家でなくてもソリューション開発者が自分自身の UI やアプリを簡単に作れるよう設計されている。 実際に CoreSSH 関連のダッシュボード UI など、さまざまな例へすぐに適用できる。

より簡単な Web アプリ制作環境を求めるすべての開発者、とくに非専門のソリューションビルダー、ジュニア開発者、バックエンド中心の開発者に強く勧められる。

1件のコメント

 
GN⁺ 2025-07-21
Hacker Newsの意見
  • Jonは長年この業界にいて、私は彼のファンだ。彼は豊富な経験を積んだベテランであり、その話には耳を傾ける価値がある。私はWeb Componentsのファンだが、Reactが主流になった理由は、かつてVisual Basicコンポーネントをうまく活用していた開発者にとって近寄りがたい環境だったからだと思う。この点こそがこの記事で最も重要な部分だ。技術的な説明も重要だが、なぜこうした試みが必要なのかという本質を突いている。XMLUIがそうした開発者に適した抽象化を提供できるかは見守る必要がある。それでも、こうした挑戦を見るだけで楽しい

    • 現在のコードはJS evergreenブラウザでしか動かない。昔のVBがWindowsと特定のDLLが入った環境でしかまともに動かなかったのと似た感じだ
  • 2014年ごろ、Polymerでもこれに近い試みがあった。たとえば <iron-ajax> のようなコンポーネントでネットワークリクエストを実装していた iron-ajaxリンク。また、Adobe Flexが大流行していた時代もあり、今はApache Royaleとして残っている Apache Royaleリンク。MicrosoftにもXAML、NetUI、FlexUIがあり、Office 2007 UIもそのように作られていた。理論上はどれも素晴らしかったが、実際にはこうしたマークアップベースの抽象化は、初心者にとってもJSXのようなコード優先のアプローチより効果が低かったと感じた

    • Coldfusionもあった(思い出して身震いする)
  • 私は「私たちはHTMLをまた再発明している」という思いと、「これは今すぐ自分の役に立ちそうだ」という感覚を同時に抱いている。人間とはもともと多面的な存在だ

    • Walt Whitmanという詩人とその作品を紹介してくれてありがとう。「私は自分自身に矛盾しているのか? それなら私は喜んで矛盾する者であろう」
    • 本当に共感できる表現だ。結局重要なのは、これが実際に君が必要だと想像している人たちにとって、すぐ役に立つかどうかだ
  • 私はQt C++でKDEに7年間オープンソース貢献をしていた。このやり方はQtWidgetsの .ui ファイル、つまり特定のXMLスキーマに従うカスタムUIファイルを思い起こさせる。後にQMLが出たが、私には直感的でなく興味を失った。ただ、UI定義にXMLを使うのは今でも理にかなっていると思うし、大規模環境で今も使われているのも理解できる

    • 今でもC++と .ui ファイルだけでQtを使っている人はいる。QMLに移行する十分な理由を感じなかったのだ
    • BlizzardのゲームランチャーもQTを使っていると聞いたが、BlizzardソフトウェアのUI完成度はいつも非常に高いと思う。ほかにおすすめのQtプロジェクトがあれば気になる
    • wxWidgetsやgladeファイルも同じ文脈だ
  • 私の考えでは、最高のGUIアプローチはJUCEだ。すべてのUI要素がC++クラスで、描画関数が別にある。新しいUI要素はほかの要素を組み合わせて別のクラスとして作れ、エディタがソースコードを自動生成する。ボタンなどは状態別(hover、pressed、active、disabledなど)の描画処理のためのif…else領域が大きい。内部的にはMetal/OpenGL/DirectXなどの薄い描画ライブラリを使っている。こうした完全に命令型(imperative)の方式は新鮮だ。どこにでもブレークポイントを置けるし、どのパラメータでどう呼ばれているかすぐ確認できる。レンダリング途中の結果をimdrawに出力するのも簡単だ。フォントのアンチエイリアシングを除けば、ほぼすべてのプラットフォームでピクセル単位に正確なレンダリングだ。ところが、ここで紹介されているXML方式は、私がいつも避けたいフレームワーク依存の魔法だ。あと3回も更新されればレイアウトが少しずつずれていくと確信している。ユーザーが自分でレイアウトを制御するのではなく、フレームワークの慈悲を請うことになる。Electronは古い技術(CSSなど)の上にあるので、こうした問題を多少は避けられるが、そうでなければレイアウト制御でいつも苦労することになる

    • JUCEは使ったことがないが、昔のQtですべてがC++クラスだった時代を懐かしく思うことはある。テンプレート言語が主流だが、クラスとオブジェクトの組み合わせのほうがずっと読みやすいと感じる。テンプレートの最大の利点は「このモジュールは親の下に正しく入ったか?」くらいに思える
    • JUICEとアクセシビリティについての使用経験を共有してくれる人がいるとありがたい
    • JUCEには詳しくないが、JUCE::ComponentはDOM/canvas要素に近く、Webプラットフォームと比べられそうだ。XMLUIはむしろJUCE上の宣言的UIシステム(GUI Magic、JIVE、VITRO)と比較されるべきだ。宣言的UIと命令的UIは両立不能ではない。SwiftUIとUIKitのように両方使う環境も一般的だ
    • JUCEは使ったことがないが、命令型は実装が大きくなっても起きていることをすべて明確に把握できるので制御しやすい。宣言型は常に脱出口が必要だが、その脱出口はいつも自作するか通り抜けにくい
    • オーディオ開発の分野で7年間使っていて、最近はあらゆるクロスプラットフォーム高性能GUI/一般アプリにJUCEを使っている。一度でもまともなJUCE -> CIパイプラインが構築できれば、本当に無限の可能性が開ける。ただ、ときどきJUCEのGUIコードをすべてLazarusに似たフロントエンド、たとえばLUAで書いてC++と混ぜ、Lua-C++の怪作を作るのも面白そうだと想像することがある
  • XSLTに触れていないのが残念だ。昔、XMLのスタイリングや変換を考えていた人たちにとって、現在の進歩がどれほど大きな飛躍かを説明するうえで重要な要素だと思う。Jon UdellがXSLTについて書いていたことを考えると 参考リンク、今回は意図的に外したのかもしれないが、その理由はよくわからない

    • XSLTが使われていた現場のほとんどは、「元の作者以外は誰も触るのが怖い複雑な髪の毛の塊」だった。この技術には奇妙なことに、複雑性の罠にはまったり、複雑性フェティシストを引き寄せたりする傾向がある。いずれにせよ、OPが目指す目的には向いていない選択肢だと思う
    • 歴史的な参考は必要だが、今回の記事の目的は過去に焦点を当てることではなく前に進むことだ。このツールを実際に使ってみて、UI構築に生産的かどうかを評価するのが記事の目的だ
    • この記事ではXSLTはそれほど重要ではない。現代の読者に、なぜこうしたツールが有用なのかを説明するのが主眼だ。XSLTは歴史的には関連しているが、ここで触れてもアイデアの伝達に役立つとは思えない
    • oleh kiselyovのSXML/SSAXを知って以来、XSLTは完全にやめた。SSAXは私が使った中で最高のXMLパーサだ
    • 私の最初のXSLT体験はsketchers.comだった Sketchy Skechers.com。残念ながら、今はもう使っていないようだ
  • 私は最近、HTML、web components、signalsをベースに似たものを作っている。Heximalというプロジェクトだ Heximalリンク。HTMLに式、テンプレート、リアクティビティ、コンポーネント構造を重ねて、非常にモジュール化され宣言的なアプリやページを作ると、優れた基盤になると思う。HTMLに追加される多くの機能も標準化できる

    • アイデアは興味深いが、モバイル(Android+Firefox)ではサイトがうまく表示されない
    • サイトが読みにくい。HNアプリでもほかのコメントがあまり見えないので、ほかの人も同じ問題に遭っているのかわからない。モバイルFirefoxでの話だ
    • モバイルではテキストが一部切れて見え、拡大しても解決しない。参考にしてほしい
    • このアプローチが主流になる可能性はあると思う。C++が主流になったように、後方互換性が強力だという点が本当に大きい
  • RJSFのuiSchemaは、jsonSchemaモデル定義を補完するプレゼンテーションレイヤーとして良い方向性を示したと思う uiSchema Referenceリンク。印象的な設計だったが、広く普及しなかったのが意外だった記憶がある

  • 私はまだ見えていない部分に特に期待している。堅実なエンジニアリングに加え、WYSIWYGプログラマー(直感的にUIを組み立てる開発者)への配慮がしっかりしていそうだ。子どものころVisual Basicのおかげでプログラミングに触れられたと思っている。C++の複雑なポインタなしでも簡単で魔法のように多くのことができ、この流れがWebプログラミングにも初心者優先のアプローチとしてつながり、反応性や滑らかさを犠牲にせず、現実的な妥協がうまくなされることを願う。さらに興味深いのは https://docs.xmlui.com/mcp だ。ClaudeのようなツールがUX/ダッシュボードコードを生成するときに必要なトークン数を減らし、より簡潔なコードを作れる。今日からさっそく使ってみるつもりだ

    • 使用感をぜひ教えてほしい
  • XAML(特にスコープの狭いSilverlight版)は、うまく使えば本当に楽しいツールだった。しかし、最も簡単で明白な(同時に非効率な)方法で使うとひどいものにもなった。おそらくHTML5やツール不足のせいで忘れられたのだろう。優れたツールは初心者でも成功に導くべきだが、XAMLはその点で不十分だった