XMLUIの翻訳

309日前原文(blog.jonudell.net)

概要

XMLUI は、Visual Basic時代の コンポーネント指向開発 を現代Webに再現する新プロジェクト。
React や CSS の知識がなくても、XMLマークアップでアプリを構築可能。
再利用可能なコンポーネント、テーマ、リアクティビティを直感的に扱える設計。
スクリプトやカスタム処理 もシンプルなJavaScriptで拡張対応。
AI時代 に適応した、誰でも扱えるモダンWeb開発の新しい選択肢。

90年代のVBモデルを現代Webへ：XMLUIの登場

1990年代中盤、 Visual Basic と豊富なコンポーネントエコシステムにより、非エキスパートでも実用アプリ開発が可能。
Webコンポーネント は同じ体験を提供できず、React系は高度なコーディングスキルを要求。
XMLUI はReactやCSSをラップし、 XMLマークアップ でReactコンポーネントを組み合わせてアプリ開発を実現。
例： ロンドン地下鉄の運行状況アプリ も十数行のXMLで構築可能。
- SelectでAPIから路線一覧を取得
- DataSourceで選択路線の駅情報を取得
- Tableでデータ表示
- フィールドバインディングや動的URL生成も直感的に記述

コンポーネント再利用とユーザー定義

XMLUI には、UIコントロールやDataSource、APICall、Queueなど多彩なコンポーネントを用意。
ユーザー定義コンポーネント も簡単に作成可能。ネイティブコンポーネントや他のユーザー定義コンポーネントと自由に連携。
例： TubeStopsコンポーネント
- API呼び出し、結果変換、表形式表示、条件付きアイコン表示などをXMLで記述
再利用例 ：TubeStopsを横並びで2回呼び出し、可読性と保守性を高める設計
大規模化時はAIアシスタントと連携し、 リファクタリング も効率化

リアクティビティと宣言的開発

リアクティブバインディング ：Selectの選択変更がDataSourceやTableに自動反映
スプレッドシート的思考 で、値の変化が他の要素に伝播
Imperative（命令型）思考 から Declarative（宣言型）思考 への転換がポイント
例：検索ボックスの入力に応じて自動でAPI検索、結果を即時テーブル表示
Reactの複雑さはXMLUIが吸収、開発者は直感的な宣言型コーディングに集中

テーマとデザインの自動化

XMLUIのテーマシステム は、デフォルトで美しいデザインを自動適用
CSSやレイアウト指定不要 で、色や余白、マージンなどを論理名で一元管理
色指定はセマンティックロール（Surface, Primary, Secondary）ごとにパレット生成
- 例：color-primary, backgroundColor-Button など
デザイナーは詳細なカスタマイズも可能、開発者は基本的に手を加えず美しいUIを実現

スクリプティングと拡張性

簡易なJavaScriptスニペット で条件分岐やデータ変換も容易に実装
例：TubeStops内の条件付き表示やtransformResult関数によるAPIデータ整形
複雑な処理もLLM（AIアシスタント）で自動生成が可能
完全な宣言型ではないが、命令型部分は明確で習得しやすい

AI時代の新しいWeb開発体験

XMLUI はAIアシスタントとの親和性も高く、 LLM によるコード生成やリファクタリングが容易
ReactやJavaScriptの知識がなくても、業務アプリやダッシュボードを 直感的かつ効率的 に開発可能
JavaScriptインダストリアルコンプレックス に代わる、現代的な選択肢として注目

XMLUIは、 非エキスパートでも直感的にWebアプリを構築できる 新しい開発体験を目指すプロジェクトです。 コンポーネント再利用、リアクティビティ、テーマ、スクリプト拡張 など、従来のWeb開発の壁を乗り越える仕組みを提供します。 AI時代の開発者 に最適な、 次世代Webアプリ開発基盤 の選択肢となるでしょう。

Hackerたちの意見

XSLTのことは全然触れられてないね？あの頃からXMLの変換やスタイリングを考えてる人が少ないから、これとあれの大きな飛躍を理解したい人も多いと思うんだ。Jon Udellが以前にXSLTについて書いてたから、これは意図的な決定だったんだろうけど、ちょっと理解できないな。

└

イントロにはあんまり関係ないかもね。この投稿の目的は、現代の観客にとってこういうのがどんなに有益かを説明することだと思う。XSLTはここでの歴史の一部だけど、含めてもアイデアを売るのには役立たないだろうね。

└

利用可能なXSLT翻訳エンジンのパフォーマンスは、特にホットリロードの文脈で速いイテレーションをサポートするためには大きな考慮事項になると思う。

└

対象ユーザーが「市民開発者」、つまりVisual Basic（クラシック）なら、XSLTを導入するのはあまり良いアイデアじゃない気がする。

└

XSLTが使われているのを見たときは、いつも「元の作者以外は触れたくない髪玉」だった。技術に何があるのかはわからないけど、複雑な混乱に必然的に崩れ落ちるか、複雑さフェティシストを引き寄せるみたい。どちらにしても、OPが目指しているものには明らかに選ばれるべきものじゃないね。

└

XSLTについての言及はないの？うん、でも彼らは「AI」についての内容を半分作らなきゃいけなかったみたい（さもなければ誰も読まない？）。

└

僕が初めてXSLTに触れたのはsketchers.comだったな。https://thedailywtf.com/articles/Sketchy-Skecherscom 残念ながら、もう使ってないみたい。

└

どれだけ歴史を持ち込むべきか悩んだんだけど、過去を振り返るんじゃなくて、未来を見たいんだ。この発表の目的は、人々にツールを試してもらって、自分にとって生産的な方法かどうかを見つけてもらうことなんだ。

プログラマーとして、ノーコードやローコードのアプローチは思ったより早く崩れることが多いと感じてる。結局、データ取得やループ処理にはプログラミング言語そのものを使うことにして、テンプレート（俺の場合はリットHTML）にはデータ構造を渡すだけにしてる。

└

俺が思ってた以上に進んでる例も見たことあるよ。Excelでやってることのいくつかを考えてる。

└

すべての抽象化は崩れる。抽象化とそれが抽象するものとの間の表現力や複雑さの違いが大きいほど、崩れるのも早い。

└

いずれはそうなるだろうけど、ビジネス目的のフィットをテストするために、一般的なプログラミング言語よりもシンプルなものでプロトタイプやv1.0製品を作るのは本当に重要だよね。ユーザーがアイデアを持って、それを実現して試すことができるから、プログラマーを巻き込む必要がないのがいい。ワークフロープロセスの設計にもめちゃくちゃ価値があるし、もちろん問題を修正したり、扱いにくくなったときに気づけるプログラマーが一人いるとベストだよね。

見えない部分のことにすごくワクワクしてる！ここでのエンジニアリングの質はしっかりしてると思うし、WYSIWYGプログラマーへの配慮もあるはず。Visual Basicでの開発が、子供の頃にプログラミングを身近に感じさせてくれたんだ。C++や複雑なポインタの操作なしで、魔法のように簡単にできることがあったから、本当に感謝してる。このプロジェクトが、レスポンスやスムーズさを損なわずに初心者向けのウェブプログラミングを実現してくれることを心から願ってる。さらに興奮するのはこれだよ - https://docs.xmlui.com/mcp。これを使うと、Claudeみたいなツールが生成するコードの量を減らせるんだ（生成するトークンが少なくて済む）。今日から使い始めるつもり！

└

どうなるか教えてほしいな。

なんか、また同じことを繰り返してる気がする。HTMLやXHTML（拡張可能なハイパーテキストマークアップ言語）はXMLの直接のサブセットだし。関連することだけど、Mozilla FirefoxにはXUL（XMLユーザーインターフェース言語 - https://en.wikipedia.org/wiki/XUL）っていうのがあって、これを使えばFirefox/Geckoウェブエンジンで完全なデスクトップウェブアプリが作れたんだ（今はChromium Embedded Frameworkで人気だよね）。MozillaがXULのコードベースを放棄した後、フォークされてUnified XUL Platform（UXP）として維持されてるみたいだね - https://forum.palemoon.org/viewtopic.php?f=46&t=30840。

└

XULが出たときは魔法みたいに感じた。サンセットしたり何かあったときはちょっと悲しかったな。すごいものになれたはずなのに。

└

これがXHTMLの再発明だとは思わないな。XULに近い感じはするけど、再発明とは言えないほど違うと思う。特に新しいのは、現代のUIコンポーネントライブラリの構成的アプローチを取り入れて、たくさんの動作やロジックを宣言的に表現できる構成単位に凝縮しているところ。少なくとも一見すると、これはすごい成果だよね。技術的な能力という点では（それもすごいけど）、インタラクティブでデータ駆動のUIをモデル化するのを簡単にしているのが特に良い。

└

僕もすぐにXULを思い浮かべたよ。

└

XAMLとWPFを思い出すな。

僕の意見では、最も優れたGUIアプローチはやっぱりJUCEだね。すべてのUI要素がC++のクラスで、描画関数を持ってる。新しいUI要素は、他の要素を組み合わせて新しいC++クラスを作ることで生成できて、エディタが自動的にソースコードを生成してくれる。ボタンに関しては、描画関数の中に大きなif...else...のエリアがあって、ホバー状態や押された状態、アクティブ、無効などの異なる状態を処理するんだ。裏では、薄い描画ライブラリが必要に応じてMetal/OpenGL/DirectXを使ってる。すべてが命令的であるのが新鮮だと思う。どこにでもブレークポイントを置けて、いつ呼び出されるか、どのパラメータで、誰によって呼ばれるかがわかる。中間レンダリング状態をimdrawにエクスポートすることもできるし、すべてのプラットフォームでほぼピクセルパーフェクト（フォントのアンチエイリアスを除いて）だよ。ここで売られているXMLバリアントは、僕が普段避けようとしているものそのものだと思う：フレームワーク依存のマジック。3回フレームワークがアップグレードされたら、レイアウトが少しずれてくるのは100%確実だよ。だって、レイアウトを所有しているのは君じゃなくて、常にフレームワークに頼っているから。Electronでこの問題が少し緩和されるのは、古い技術を使っているからだね。CSS自体はもうあまり変わらないだろうし。

└

JUCEの名前は聞いたことがなかったけど、JUCEはウェブプラットフォームそのものに近い（juce::ComponentはDOMやキャンバス要素のようなもの）らしい。一方で、XMLUIはJUCEの上に構築された宣言型UIシステム（GUI Magic、JIVE、VITROなど）と比較するのが適切だと思う。宣言型と命令型のUIアプローチは相反するものではなく、両方を活用するソフトウェアはよくある（例えば、SwiftUIやUIKit）。

└

JUCEはまだ試してないけど、Qtの中ですべてがC++クラスだった頃が懐かしい。みんなテンプレート言語を求めてるけど、こういう感じだよ：class MyButton extends QObject { … $button = new Button(); $button->color = “blue”; $icon = new Svg(); $layout = new QtHorizontal(); $layout->push($icon, $button); $this->layout = $layout; … } これの方が、ファイルをまたいでスタックされたり埋め込まれたりしたマスタッシュ/XML構文をいじるよりもずっと読みやすいと思う。テンプレート言語は、コードを理解する上で一つのユニークなことだけを保証するんだ：「私のモジュールは正しい親モジュールの下に埋め込まれているのか？」

└

JUCEに切り替えたんだ。完全なクロスプラットフォームのGUI/高性能な一般アプリ開発環境として、音楽の分野で7年間使ってきた結果、何でもこれでやっても大丈夫だって気づいたんだ。CMakeの調整もそんなに難しくないし、少なくとも一つはまともなJUCE -> CIパイプラインが動けば、どんどん視野が広がっていくよ。とはいえ、JUCEのGUIコードをLazarus風のフロントエンドに入れて、LUAをその部分に使うのが楽しそうだなって、だんだん考えるようになってきた。

僕は7年間Qt C++をKDEのオープンソース貢献者として書いてた。この話を聞くと、QtWidgetsの.uiファイルを思い出す—特定のスキーマに従ったカスタムXMLファイルだね。その後、QtはQMLを導入したけど、個人的には直感的じゃなくて、時間が経つにつれてQt自体に興味を失ってしまった。でも、UI定義にXMLを使うのは意味があると思うし、いくつかの大きな環境がそれを使い続けるのも理解できる。

└

まだC++と.uiファイルだけでQtを使ってプログラミングしている人もいるよ。QMLに切り替える気にはならなかった。努力する価値があるほどの利点があるとは思えなかったから。

XAML（特にSilverlightのバージョン）は、正しく使えばめちゃくちゃ楽しかったよね。でも、間違った使い方をすると本当に大変なことになる。多分、HTML5以外の理由で使われなくなったのはそのせいだと思う。いいツールは初心者を成功の道に導くけど、XAMLは全然そうじゃなかったからね。

VBを参考にするのは間違ってる気がする。Visual BasicやDelphiの魅力の多くはUIビルダーにあったからね。ボタンをクリックするだけで新しいプロジェクトが作れて、すぐにウィンドウが用意される。コンポーネントをドラッグ＆ドロップして、ボタンをクリックして機能をつなげる。全体の敷居がすごく低かったから、XMLファイルを編集するのはその使いやすさからは遠い感じがする。ただ、Visual Basicも本当にひどいプログラムを作ることがあったけどね。

└

ComposeがAndroidアプリ開発の新しい方向性になった前は、Android StudioのデザイナーIDEはVB6スタイルのデザイナーで、コンポーネントをドラッグ＆ドロップできたんだ。基盤となるUIファイルはXMLベースだったけどね。コールバックの生成はVBほど簡単じゃなかったし、異なる電話サイズに対応するためにリサイズしなきゃいけなかった（VBアプリは普通それを気にしなかったけど）。でも、体験自体は結構良かったよ。最近では、Gambasが無料でオープンソースのVBとしてあって、ひどい言語も含まれてるけど、僕の経験では、あるデスクトップ環境でデザインして、別の環境でアプリを実行すると見た目がちょっとおかしくなるんだよね。

└

VBがあのひどいプログラムを作ったわけじゃない、俺が作ったんだ。

「ハハ、HTMLを再発明したぜ、笑」と「実際、これはすぐに役立ちそうだな」という、まるで正反対の立場にいる気分だ。人間っていろんな面を持ってるよね。

└

美しい表現だね。結局大事なのは、これが「使えるかも」と思ってる人たちにとって、すぐに役立つかどうかだよね。

これは、react-adminやRefineのようなReactアプリケーションフレームワークに似てるね。const App = () => ( ) const PostList = () => ( ); 記事ではXMLに触れてるけど、真の革命はJSXそのもので、これを使うことであらゆるロジックをReact要素として記述できるようになるんだ。これで、PythonのようにあらゆるもののためのDSLを作る可能性が広がるよ。

ハクソク