BUI的定位
如今前端的UI框架琳琅满目，那为什么我们要编写BUI，为什么推荐您使用BUI？
从公司内部的环境来看，大多数前端团队只关注前端业务的实现，对于富客户端的开发，以及大量开发人员如何使用前端控件、开发自己的后台UI框架毫无兴趣。但是从作者经历过的一些项目和接触的一些开发人员总结来看，后台系统也是需要很好的体验同时由于开发人员在前端领域的效率低下，这也让我萌发了，将积累的前端的一些知识，解决方案化，将一个一个的解决方案提供给开发者。首先我们面临着下面的一些问题：
- 能够满足业务需求的成熟的兼容性良好的html、css和Javascript
- 易于使用，功能完善的控件库
- 典型的成熟的解决方案，下载即用的应用
- 大量精细的demo和丰富的文档
- 易于修改和扩展的应用
为了解决这些问题，我做了以下这些工作：
- 在bootstrap基础上整理出一套全兼容的html和css，作为DPL开放给开发人员。参看详情
- 基于jQuery和seajs，同时又兼容Kissy，开发完成了BUI控件库
- 将当时自己支持的后台项目打包提供了完整的解决方案，封装成一个应用。
- 对于大多数开发者来说便于复制代码的demo，是必不可少的，目前的demo数量大概有300多个，还在不断的更新中。
BUI的开发过程中一直遵循着以下原则：
- 扩展性：在开发者了解了控件的机制后，可以方便的扩展出自己需要的功能。
- 复用性：提供大量的扩展（mixin）控件之间的代码复用做到极致。
- 完备的单元测试：目前BUI处于快速迭代的状态，功能的增强和细节的调整，需要完备的单元测试做保障。
- 易用性：使得接口统一，便于理解，遵循一致的约定，使得用户的学习成本降到最低。
BUI目前的问题
BUI控件库目前有下面的一些问题：
时间短，功能不完善。从12年9月开始开发到现在一年的时间，对于一个开源的控件库刚刚起步。
支持的业务比较单一，对业务场景的适应还需要大量的反馈。
Demo对于一般的开发者而言已经能够满足需求，但是介绍原理性的文档严重不足，限制了在BUI的基础上进行扩展和二次开发。
代码提供者过少，加上我们平时的业务压力，所以迭代的速度和目前文档的需求很难保障。
虽然面临这样那样的问题，但是从目前的反馈来看一切向着好的方面发展，越来越多的开发者使用BUI，我们也收到越来越多的反馈，每个月都有很大的发展，感谢大家的支持！！！
BUI的规划
BUI是一个开源项目，我们一直会开源下去，不会走商业化的道路。这是首先的保证。
针对使用者的反馈和自己参看其他UI库学习到的东西，接下来的工作：
- 完善使用和开发文档，使越来越多的开发者能参与进来。
- BUI控件库的CSS样式和控件分离，进而提供新的皮肤样式。
- BUI控件的整体性能优化，虽说目前没有得到性能方面的反馈，但这是迟早要解决的问题。
- BUI新的应用，目前仅提供了一个成熟的应用，对于各个平台上使用的具体解决方案并未提供。
