windows桌面開發，介面始終是最大的困惑。我們對前端工具的要求，其實只有窗體設計器、訊息對映，過分點的話自適應螢幕、模型繫結。能夠免於手工書寫，其實這個問題並不複雜，但VS不實現、QT語法怪異、wtl同樣，甚至第三方工具也無，wxWidgets也沒有。
一、各種Html方案：
1、node-webkit：
有一個叫light-table的IDE專案複雜些，但看起來效能未必很好。不過，與webstorm之類java做的ide區別，效能上似乎也並沒有多大的差距。目前來看，簡單的通過調整初始url，可以直接將服務端應用轉為客戶端，這意味著一個能夠全屏、置頂的瀏覽器。
需要帶十幾兆的包，這是比較討厭的事情。
最初的疑問是：node-webkit使用require之類語法，在前端呼叫node模組。這種開發實際上比較麻煩的，好像在哪種IDE下都不好工作...那麼,很簡單的思維，既然node就在本地，那麼使用本地資源為何不直接用node做服務端，而前端用REST呼叫？這樣兩個好處：1、前端是純粹的前端專案，不同的是自帶瀏覽器。後端為純粹的node專案。兩方面來看，各種編譯器都支援。2、桌面和Web應用的程式碼將完全一致，不同的只是前者自帶瀏覽器。
不過後來發現這個不是問題，node-webkit可以通過設定啟動url直接的使用服務端專案。
類似node-webkit的，首先是CEF3，這個有一些應用，看起來歷史更早，但據說其追隨新版chrome比較麻煩，在node-webkit上也有一個分支名為CEF。網易的Hex是典型的中國式專案，只發布了簡要的文件和二進位制包，據說要開源但目前還沒有，用hex做的有道詞典，效能還不錯，據說是分析過node-webkit，覺得不易商用才自行處理的，但作者重新造輪子、敝帚自珍的心態很明顯，幾乎是不能考慮的。
2、htmllayout
另一種選擇，是個600k左右的dll，不開源。使用html處理佈局，使用css的特性呼叫c++的功能，當然這不是html5，也不是完整的html解析，只是針對窗體佈局的子集。
3、EA-Webkit：
是對Webkit而非chrome核心的剪裁，只有4M，但顯然也是很冷的...其本身的目標應該是在桌面應用中顯示網頁，沒有呼叫c++、訪問本地資源的能力，那麼就不能說是介面方案。當然，用wtl結合它，應該能做些簡單的工作。
開源的頁面在：http://gpl.ea.com/ 丟一堆的程式碼，沒有文件。
這是極少的例子中的一個：用duilib和eawebkit製作的瀏覽器，當然，用起來令人崩潰：
4、htmlview
mfc提供了基於ie核心的htmlview，這個，由於使用者端機器的ie版本不同，也是頗為要命的事情，這會帶來多大的工作量呢？國內頗多產品，近年將對ie的依賴轉向chrome，不是沒有原因的。
5、tc/tlk方案
看看git的官方windows介面就知，這是很古老的東西，醜陋的不成。介面使用所謂tlk檔案，並沒有太好的設計器，其主要的意圖是跨平臺，而非簡化設計。
二、Direct ui方案
國內還存活的大約只有DuiLib，金山自己都不用自己的介面庫，迅雷的各種複雜，其他都比較小眾，而且這個話題，所謂的less window在2010年後似乎提及的也不多。
以duilib來說，窗體設計器非常簡陋，許多bug，經常崩潰。更別提模型繫結、事件繫結了。我將其在vs2013下編譯通過，仔細看了下程式碼並與其中一個開發者討論過，設計比較紊亂，自願者的組織也相當鬆散。
三、Mfc和wtl：
確實很麻煩。使用資原始檔描述窗體，和使用xml、html沒什麼區別。有簡陋的對話方塊設計器和ribbon設計器，訊息對映可以使用類助手來略麻煩的處理。從這個角度來說，html方案並不佔優。wtl則在進入vs2012之後，wtl helper沒人維護，訊息對映需要手工書寫。如果介面簡單，或可使用wtl，"小"是優勢。
四、QT和wxwidgets
QT相對比較成熟，業界應用也廣泛，但比較龐大，且寫法怪異，需要類似mfc一般的深入瞭解所謂"框架"。wxwidgets實際上是類似mfc的做派，同樣也比較大。兩者都跨平臺，事實上桌面應用，跨平臺到mac、linux的需求少得可憐。
其他小眾的介面庫，甚至都沒有深入瞭解的願望。
實際上，當年Delphi的介面設計，今天在windows裡，各種方案都做不到。我相信微軟、谷歌這些公司肯定能做到的，但是，是否每個公司都本能的希望，win平臺的原生開發需要門檻高企？