纵观这几年，界面库的发展可谓风声水起，讽刺意味的是：大家对PC上的界面重视程度，来源于手机界面的发展。当苹果出现时，彻底让人们对界面的需求，提高了一个台阶。随之而来的是粗糙界面的塞班界面的没落。
过去。人们不太重视软件界面。把很多其它的精力放到程序功能上。
如今人们越来越意识到。一个好的界面对产品的成功有时起着关键性作用。这是好现象，在产品同质化严重的今天。一个好的界面，就会让产品脱颖而出。
界面库的分代
在VC++开发上，界面大致经历了这么几代：第一代Win32原生态界面：包括对它进行封装的MFC、ATL等。
由于它足够兼容、足够稳定、足够淳朴，一直到如今还占有大量的市场。只是它逐渐被压缩到一些专业软件上。在IM、播放器、杀毒等领域，已经不能想像一个原生态界面会是什么样子了。
第二代Hook换肤库：这是为了解决Win32原生态界面“淳朴”外观而诞生的。
以SkinMagic、SkinPlusPlus、SkinSharp等为代表。它有一个看起来漂亮、又特别唬人的特性：一句代码换肤。是的，它能做的也仅限于此了。由于它不介入界面开发，所以不会提高界面开发效率；由于你仅仅调用了它一行代码。所以。Hook换肤库里有不论什么bug，你都无法绕开。除非你凝视掉这行代码。不用它，而bug差点儿是一定有的。由于Hook界面库仅仅认识控件类型。不认识详细控件，也就是说。换肤后，全部同类型控件。都会长一个样，非常难做到个性化。兼于种种原因，所以Hook界面库早已光荣退休了。
第三代DUI界面库：dui是Directui的简称，也称作windowless，意思是无句柄,以duilib为代表。前两年，大家都搞dui。dui着实火了一阵儿。当初产生dui，当中一个原因是自绘某些win32控件特别困难，与其花大力自绘这些win32控件，还不如干脆自己开发一个得了。另一个原因是他们自觉得dui比win32控件安全，实际上全然不是的。
随着这两年使用的深入，dui的各种弊端都逐渐暴露出来了。
dui控件是比照着win32控件来实现的，这句话的潜台词是：win32控件是标准，是被模仿的对象。
尽管理论上，dui能够完整的模拟出一个win32控件。但一个比較糟糕的现实是：国内做dui的程序猿。差点儿没有人知道一个完整的win32控件应该是什么样、具有什么功能。所以他们仅仅能模仿他们看到的部分。dui界面库尽管相对于win32原生态控件，提供了控件贴图的功能、但却失去了很多其它本来应有的功能，变成了一朵艳丽的假花儿。我们知道。win32控件是windows操作系统提供的基础控件。windows能够保证它一直拥有着最新特性。举个样例，我们在windows xp上，制作了一个界面，界面上有个Tree控件。
当把这个编译好的exe放到装了Win8系统且带多点触摸屏的电脑上执行时，Tree控件会自己主动具有惯性滑屏的功能，尽管xp不支持多点触摸。
当我们打开系统的界面朗读功能时，用键盘在Tree控件上操作，系统会自己主动依据您所选的Item，正确朗读出来。（这正是Accessibility法案的一条要求。对于出口到欧美国家的软件。Accessibility法案是强制规定。所以，眼下还没有不论什么一个国产的dui库做的界面，达到这一强制规定）。当将来的Win9、win10等系统有新功能时，这些Win32控件，会自己主动拥有这些功能。
这一点是dui界面全然不具备的。
如今另一种界面库,为了区分,暂称之为DirectHWND技术吧：以LibUIDK为代表。
它从原生win32控件派生，保留了win32控件全部特性、拥有完整的消息机制、与win32控件全然一样的编程思想（意味着差点儿忽略不计的学习和维护成本、更小的风险，假设是dui库。你得按它的方式来调用。它封装成com，你就得懂com）、又提供了dui界面的自绘功能。是win32控件与dui的完美组合。
下图能够表示win32控件、dui控件和HWND-DirectUI控件三者的关系。