windows原生开发之界面疑云
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平台的原生开发需要门槛高企？
