HTML5/JavaScript/CSS3 でクロスプラットフォームなデスクトップ GUI アプリを作れるフレームワークの決定版を見つけた（かもしれない）件
[追記 2015/05/19]
2015年時点では HTML5/JavaScript/CSS でデスクトップ GUI アプリを作るなら、Electron 一択でしょうね。electron.atom.io
[追記ここまで]
私はデスクトップアプリケーション開発歴はすでに20年近い老人ですが、数年前から「HTML5 でデスクトップ GUI アプリを開発するのが今後主流になるはず」と言い続けてきました。
最近になってやっと、その説をサポートしてくれてかつ人に紹介しても恥ずかしくなさそうなフレームワークに出会えたので（それも一気に 2 つも）、紹介したいと思います。
ちなみに、私のデスクトップアプリ開発に使ってきたフレームワークの遍歴は、以下のような感じです。（抜けてるのもあるかも）
他にも、大学の計算機の授業の課題で SunOS の上で生の Motif を書いたりしたし、趣味でいろんなフレームワークをつまみ食いしたりしてチュートリアル程度はやったというのを含めるとこのリストは倍くらいになるかもしれない。
で、一時期 Web アプリやモバイルアプリの開発なんかもやってみて思ったのが、結局どのフレームワークでも、コントロールやウィジェットと呼ばれる GUI 部品を座標とか大きさを指定したりレイアウトマネージャー的なものにそのへんを任せたりしつつ配置して、それぞれの部品のアクションに応じてイベントハンドラ書いたり、MVC モデルとか使ってデータが更新されたら見た目も更新する（もしくはその逆）みたいなことをしたり、結局はどれもこれも似たようなことやってるだけだなと。なのに、新しい環境が出てきたら毎回毎回新しい言葉を覚えて新しい習慣を身につけないといけないと。
WPF やってるくらいのころに、「もうこれ HTML でいいじゃん」とマイクロソフトを呪ったわけです。なんでまた新しいマークアップとかバインディングとか覚えないといけないのと。
たぶんそれが 2006〜2007 年くらい。
で、新しもの好きがたたって（？）一時期 Titanium Desktop とかに可能性を感じてみちゃったりしたわけです（結局 Appcelerator は Titanium Desktop を手放してオープンソース化されて Tide SDK ？とかになって細々とやってるのかな）。
AppJS っていうのを見つけたりしてこれもいいかもと思ったんだけど、実際使ってみるとどうも思ったとおり動いてくれない（Windows 64bit 環境だと起動もせずにクラッシュした。そのうち直るかもしれないけど）し、ドキュメントとかも圧倒的に足りてない感じ。→ 今は deskshell っていうプロジェクトに引き継がれているようですが、どうなることやら。
最近は Chrome App がいい感じかな〜とも思ったけど、お手軽さという意味ではいいんだけどやっぱりブラウザに縛られるというか普通にローカルのファイルを見に行けないとかそういう息苦しさみたいなものはある。作れるアプリが限定されちゃうというか。必要なデータは全部 Web からかき集めてきて、保存するときもクラウド、みたいな Web ネイティブなイマドキのアプリにはいいのかもしれない。（実際、2 つくらい自分用の実用的な小さなアプリを Chrome App で作ってみた）
前置きが長くなったけど、そんな中で見つけたのが node-webkit と Qt。
node-webkit
node-webkit は、数ある「WebKit と LL を組み合わせて見ました」系のフレームワークとは一線を画す感じで、ちょっと使ってみた感じでも商用アプリを作るのに耐える品質を備えているんじゃないかと思ったフレームワーク。開発も活発に続いている。ドキュメント等、情報も他のものに比べると十分そろっていると思う。（少なくとも、今までアプリを作ってて困ったことがあってぐぐったら全部答えが見つかっている）
少しだけ特徴をあげてみると、
- 作ったアプリをバイナリ単体で配布できる（Windows なら単一の .exe ファイルにできるし、Mac ならパッケージを作れる。Linux でも 1 つの実行ファイルにして配布できる）
- node.js で DOM をいじれる
→ これ結構気持ちのいいパラダイムシフト。サーバサイドの人もクライアントサイドの人も到達したことのない境地のはず。「サーバサイドとクライアントサイドの言語が統一できますよ」っていうの（一瞬うれしそうだけど全然嬉しくないやつ）のレベルじゃない。たとえば、AngularJS のコントローラの中で SQLite で直にファイルからデータを読みだしたりできるんだぜ？
→ CoffeeScript とか LESS とかソレ系のやつを grunt で毎回コンパイルしたりしなくてよい。GUI アプリとして実行される時にコンパイルすれば良いから。で、シングルページアプリケーションとして動かして DOM をグリグリいじって画面の更新をするようにすれば再読み込みが発生しないのでパフォーマンスにもインパクト小（起動時に一回だけコンパイルされるだけ）。どうしてもそれも許せないなら普通に事前に JS や CSS へとコンパイルしてもいい。
→ パフォーマンスは逆に悪化するらしいが、秘密にしたいコードを（若干ではあるが）隠せる。
などなど。
node-webkit を使って、これも 2 つくらいアプリを書き始めてみたところ。
Qt
Qt なんて、見つけたというか温故知新というか僕が今まで気づいてなかっただけで、C++ のごっつい旧世代のフレームワークくらいにしか思ってなかったんだけど、実は Webkit ベースで HTML5 アプリを作れて C++ の世界（QObject）とのインタラクションが快適そうなので急浮上してきた。
実際ちょっと使ってみたら、Qt って名前の通り結構キュートなやつなのな。クラスライブラリの設計とかもちゃんとモダンな標準に従っててエレガントな感じがしてさわり心地がいい。C++er としてはホント今まで気づいてあげられなくてごめんよという感じ。
node-webkit ほどの気持ちよさは無いけど、パフォーマンスを極限まで追求したいとかどうしてもシステムコール呼びたいとか、ポインタが無いと生きていけないとかそんな下寄りに行きたい、でもイマドキっぽいかっこいい GUI も欲しいとかいうようなときは（どんなときだよ）、今後は僕は Qt を選ぶと思う。（node-webkit + native extension に行っちゃうかもしれないけど）
一つ実験的に規模大きめの GUI アプリを書き始めてみた。
