连载:前端开发中纠结的Javascript框架(上)

如今，前端开发有着许许多多的框架和库。其中一些好用，一些却不尽人意。通常我们会习惯性运用某一概念，模块或句法。事实上，并没有什么万能工具。这篇文章是关于未来框架的发展趋势——那就是没有框架！我从以下几个方面总结了可用JavaScript框架的利弊，也大胆设想了一些完美的解决方案。

抽象意义上的危险性

我们都喜欢简单的工具。Complexity kills这条复杂的学习曲线，使得我们的工作难上加难。程序员需要时刻关注新事物，否则,他们就没有安全感。如果我们使用复杂系统工作,就会存在 “我仅仅使用它”与“我知道它的运作原理”的巨大差距。例如,下面几行代码就隐藏着一定的复杂性:

这是一个真正的框架。后台创建新页面，首页会加载出新的视图类。HTML模板是以我们新建DOM子树的可见参数为基础。现在，我们是站在开发者的角度来思考的，我们从文档中获取信息，并借助一定的模板来创建新页面，因为很抽象，我们也不清楚一些特别的细节。

今天没有框架，但有一定的抽象度。有时，为了正确使用框架，我们必须适当了解细节。抽象，从某种意义上讲，也是一个强大的工具，它具有一定的功能性，是程序员设计决策灵感的源泉。然而，因其在一定程度上会影响网络商机而没被广泛使用。

我们把上面的例子转换一下：

现在，如果你是做前端开发的，你肯定能观察出其中的端倪，原模板和后来加代码而显示出了不一样的API类，这说明我们都可以通过操控过程来做相应的改变。

Ember.js是一个伟大的框架，它给予我们灵感，仅用几行代码就能创建单页应用程序，然而，它也实现了自身的价值，同时在后台系统定义了几个类，例如:

该框架创建了三个路径，每一个都是由控制器连接的，你可能会用到这些类，也可能用不到，但它们真实存在着，该框架需要他们来启动应用程序。

我们的项目经常会用到自定义功能，但是没有一种框架是可以涵盖所有例子的。遇到问题，也没有简单的解决方案。因此，我们必须了解其运作原理，才能真正找到解决办法，但目前我们所采取的每一个措施都看起来似乎更像是在测试框架，而不是在研究它。

例如，Backbone.js就介绍了几个预定义的对象，其中也包含核心功能，但要真正实现还得靠程序员。下面就是DocumentView类扩展成backbone.view的例子，在我们使用的代码和框架的核心功能之间只有一个级别：

就我个人而言，我更喜欢使用一个没有太多抽象层次的框架-一个可提供透明度的框架。

失踪的构造函数

一些框架接受我们的类定义，但它们不产生构造函数。该框架决定何时何地创建一个实例。我们正好在knockout中看个关于框架的例子：

我们在AngularJS中定义模型并初始化，可能略有不同，例如：

我们再次定义了类，却没有运行它，只能说，我们把它当成了控制器，由框架来决定如何处理。我们会发现这有点混乱，因为我们失去了关键点——我们使用可视化应用程序流程的关键点。

DOM操作

无论我们做什么，都会用到DOM交互，怎么用很关键，因为通常情况下，页面节点每一步操作可能引发的回流或重绘，都将是一笔昂贵的投资，我们举个例子来看一下JavaScript类的使用：

这个小框架利用给定数据生成了一个无序列表。我们发送的DOM元素会收到这个列表，并调用更新函数在屏幕上显示数据。
运行后的代码，结果如下：

为了证明这个设计的缺点，我们在页面上添加一个链接，并设置一个可遥控事件侦听器，函数会再次调用更新功能，结果却显示不同。

我们输入几乎相同的数据，只改变数组的第一个元素。因为我们用的是InnerHTML，每次点击后会显示自动重绘。浏览器并不知道我们只需修改第一行，所以会重绘整个列表。我们在Opera里面运行，看看下面的GIF动画演示效果：

注意：全选并点击一次就会重绘一次，特别是我们在同一页面上使用相同技术。

如果我们能创建<li>nodes，只更新内容，那就更好了。这样，我们就不用重绘整张列表，只修改部分就可以，首先我们要设置元素：

像这样，我们无需再引入主元素，只需创建一个新的<ul>元素并添加。改善性能的逻辑是更新方法的主体：

第一个循环语句会通过传入的数据在必要时创建 <li>元素，在行中创建标签，如果某个索引存在节点，框架就会适时更新文本目录属性，要是旧的数组元素比当前元素少，就在最后循环处移除节点。

这里是结果：

结果显示：浏览器重绘部分改变。

好消息是，从框架反应的效果显示操作DOM的方法是正确的。浏览器也更加智能化，会运用技巧来减少重绘。它也有很强的记忆性，能够时刻检测所选框架提供的信息。

我希望在不久的将来，框架能够自动化处理，我们不用再为这种问题烦恼。

DOM事件处理

基于JS的应用程序通过DOM事件经常与用户进行沟通，页面元素输出信息，然后经过代码处理。这儿有个例子，当用户与页面交互，backbone.js代码会相应执行一个动作：

这儿应该有一个跟菜单显示卡相匹配的元素，否则用户一旦点击，我们就必须切换菜单。这种设计的问题是将JS放在了一个特定的DOM条目里。如果我们修改HTML，想把菜单变为主菜单”，那我们也必须同时修改JS部分。控制器应该是独立的，我们可以把它们从DOM中分离出来。

通过定义函数，我们将任务委托给JS类。如果这些任务在DOM事件中处理，然后在HTML中构建也可以。

我们来看看AngularJS如何处理事件：

go是一个在控制器中注册的函数。按照这种方法，我们不必考虑DOM选择器。我们来看HTML节点的应用行为，这是一个功能强大的方法，我们可以直接跳过与DOM的无聊互动。

总的来说，我是希望能在HTML里看到这种逻辑。但有趣的是，我们花了很长时间让开发者把内容（HTML）和动效（JavaScript）分开，教他们要避免内联样式和脚本。然而，现在我看到这样做实际上也可以节省我们很多时间，组件也变得灵活。当然，我不希望看到这样的代码：

相反，我们应该讨论控制元素行为的描述性属性。例如:

它不像HTML当中的JS编码，更喜欢设置结构。

依赖管理

管理依赖关系是我们开发过程中的一项重要工作。我们通常依赖于外部功能、模块或库。事实上，我们一直都存在依赖性。我们不会把每件事都总结成一个方法。我们将应用程序任务分解为功能，并写下它们。理想情况下，我们把这些逻辑方法整理成模块在以后工作细节上备用。

RequireJS是解决依赖关系的流行工具之一，在接受所需模块的闭包中包装你的代码：

在上面的例子中，我们的函数需要两个模块—— Ajax和路由器。用神奇的方法读取传递的数组，并用适当的参数调用我们的函数，回调函数的定义代码是这样的：

注意，存在另一个依赖关系—jQuery。同样重要的是，我们必须返回我们模块的公共接口API。否则，我们模块的代码会无法访问所定义的功能。

AngularJS通过给我们提供一种叫factory的东西走的更远，我们记录下相关性，他们就能在控制器里神奇地运行，例如:

一般而言，这种方法简化了我们的工作。我们不需要使用像命令这样的功能来获取依赖性，我们要做的就是在参数列表中键入正确的字样。

把这两种方法的依赖性用到工作里，一定要具体样式的编码。未来，我希望能看到可消除这种约束的框架。如果我们能够在变量定义中应用元数据，那将是非常优雅的。语言特性现在还不提供这样的能力，如果下面例子成为可能就好了：

将依赖性和变量定义放在一起，如有必要就直接套用。例如，requirejs和AngularJS属同一功能层次。在特定情况下，你只能使用一个组件，但初始化界面和套用这两种方法随时都可以用。当然，也必须有一个特定的地方来定义这种依赖关系。

今天就先写到这里，明天继续。

智能社撰稿，转载请注明来源！！