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制作的瀏覽器，當然，用起來令人崩潰：

    項目地址：https://code.google.com/p/duibrowser/

    簡介：http://blog.csdn.net/achellies/article/details/6550050

 

 

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：

四、QT和wxwidgets

    QT相對比較成熟，業界應用也廣泛，但比較龐大，且寫法怪異，需要類似mfc一般的深入了解所謂"框架"。wxwidgets實際上是類似mfc的做派，同樣也比較大。兩者都跨平臺，事實上桌面應用，跨平臺到mac、linux的需求少得可憐。

    其他小眾的界面庫，甚至都沒有深入了解的愿望。

 

    實際上，當年Delphi的界面設計，今天在windows里，各種方案都做不到。我相信微軟、谷歌這些公司肯定能做到的，但是，是否每個公司都本能的希望，win平臺的原生開發需要門檻高企？