JS界面框架的思考——控件逻辑结构与DOM的控制
纯JS实现的Web界面框架，被认为是一种基于组件的管理方式，可以认为是在浏览器上近似实现桌面应用GUI的方式。Web组件的封装与桌面控件的实现不同，JS框架需要通过封装来做的，就是管理与其逻辑结构相关联的DOM元素；而这两者在思想上却具有相似的地方（这是一定的，因为本质上这是一种主动的模仿）。
因此有以下几个问题需要关心：
- 封装必然导致的问题就是灵活性受限，提供的API不可能是完备的。用户如果跨越框架直接操纵DOM，将是非常不可靠的，框架的更新或者仅仅简单的界面风格切换，都可能导致用户的越级操作失效。因此，接口提供用户需要的尽可能多的功能，是非常必要的。
- 对于控件的操作，应该总是从逻辑对象入手，由框架操作DOM对象，就像Windows编程时程序员会得到控件句柄，而控件句柄永远是指向了该控件的逻辑结构所在的空间，而不是二维层缓冲区。因此，一个逻辑控件的构造与析构，与实际控件是否在缓冲区或被释放，是没有直接的联系的（对JS来说，就是与DOM对象的存在与否没有关系）。
- 理论上良好的实现是需要时才产生DOM，而不是在构造时就产生DOM，尽管由于浏览器的优化行为，构造一个不用显示的DOM，计算开销是比较小的，然而还是由于浏览器的优化行为（空间换时间），DOM往往必须占据不少内存空间，远大于控件逻辑对象。实际上程序员是比较习惯手动控制DOM的创建和移除，因此许多框架中程序员都需要明确向框架发出构造DOM的指示，这就要求程序员对与何时构造DOM有一个基本的考虑。
- 意图不明确的封装是糟糕的。如果在控件的逻辑结构上需要再进行一次封装，那么最好有明确的理由和完整的架构考虑，就像在Windows的C库上封装的MFC，甚至虚拟机。当然，使用MFC的程序员，往往不再同时直接接触Windows API，因为那样是被视为混乱的程序结构。然而在架构不明确的框架中，使用不同层次的框架往往是难免的，这样将同样产生不可靠的操作。另外，除了造成内聚性差以外，层次不明确导致开发人员也无法知道，使用哪一层的操作才是最优的，往往可能导致不同的实现，代码可读性也变差。
- 框架要提供必要的文档，帮助开发人员了解，对逻辑控件的操作，会如何影响用户交互。
- 不能够直接操纵逻辑对象的数据成员，因为直接操作数据成员一般都是不好的行为，而应该总是使用方法来进行调用，尽管JS语法上并没有可见性修饰符，但是从封装性的角度而言是不希望用户这样操作的。因此，对于可以修改的数据成员，总是应该提供修改/获取它们的值的方法。
