ハクソク

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

XMLUIの翻訳

2025年7月20日原文(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製品を作るのは本当に重要だよね。ユーザーがアイデアを持って、それを実現して試すことができるから、プログラマーを巻き込む必要がないのがいい。ワークフロープロセスの設計にもめちゃくちゃ価値があるし、もちろん問題を修正したり、扱いにくくなったときに気づけるプログラマーが一人いるとベストだよね。

Hacker Newsで議論の続きを見る