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平台的原生開發需要門檻高企？