简介

模板引擎，其实就是一个根据模板和数据输出结果的一个工具。

我们要开发一个将模板文件转换成我们实际要使用的内容的工具，这个工具就是模板引擎。我们把模板文件里的内容当成字符串传入到模板引擎中，然后模板引擎根据一定语法对该字符串进行解析处理，然后返回一个函数，之后我们在执行函数时把数据传输进去，即可拿到根据模板和数据得到的新字符串。最后我们想怎么处理该字符串就看需求了，如果用于前端模板生成的话，则可以用 dom 的 innerHTML 这个属性来追加内容。

目前前端的模板引擎多得数不胜数，语法特性也花样百出，用行内的话来说，我们要实现的是一种基于字符串的模板引擎。

想做一个好用的在线编辑器，不管是地图编辑器、PPT 创作平台还是通过拖拽快速创建活动页面的编辑器等等，必然要给用户提供各种快捷的操作方法。如非常常用的复制粘贴功能。

举个例子，在 iPresst 创作平台，我们的作品在好几页都要用到同一张图片，总不能每次都点击上传一次图片吧？右键复制粘贴或者直接按快捷键无疑是最符合用户预期的操作方式，然而我们编辑器用到的元素一般比较特别，而且我们复制粘贴的时候经常要做一些特殊处理，此时我们就需要覆盖浏览器给我们提供的复制粘贴功能了。

原文地址：http://www.toptal.com/nodejs/top-10-common-nodejs-developer-mistakes

原文作者：MAHMUD RIDWAN

转载此译文请注明原文及译文出处，如译文有翻译不当之处还请各位看官指出。

自 Node.js 面世以来，它获得了大量的赞美和批判。这种争论会一直持续，短时间内都不会结束。而在这些争论中，我们常常会忽略掉所有语言和平台都是基于一些核心问题来批判的，就是我们怎么去使用这些平台。无论使用 Node.js 编写可靠的代码有多难，而编写高并发代码又是多么的简单，这个平台终究是有那么一段时间了，而且被用来创建了大量的健壮而又复杂的 web 服务。这些 web 服务不仅拥有良好的扩展性，而且通过在互联网上持续的时间证明了它们的健壮性。

然而就像其它平台一样，Node.js 很容易令开发者犯错。这些错误有些会降低程序性能，有些则会导致 Node.js 不可用。在本文中，我们会看到 Node.js 新手常犯的十种错误，以及如何去避免它们。

这主题主要是早期对 web audio api 的一些尝试，这里整理一下以便以后翻阅，如有错误，诚请指正。

在真正进入 Web Audio API 开发之前，需要先弄清两个概念：音频上下文（AudioContext）、音频节点（AudioNode）;

Web Audio API 是一套以音频上下文（AudioContext）为基础的接口系统；基本上每一次的开发都需要第一个用到，

看下 W3C 对 AudioContext 的描述：

This interface represents a set of AudioNode objects and their connections. It allows for arbitrary routing of signals to the AudioDestinationNode (what the user ultimately hears). Nodes are created from the context and are then connected together. In most use cases, only a single AudioContext is used per document.

大意是一个 AudioContext 代表一系列音频节点以及节点之间的连接方式，它允许一个或以上的音频信号在经过任意的连接之后最终连接在音频播放设备节点上；节点都是可以通过音频上下文对象然后连接到了一起；通常一个文档中只需要一个一个音频上下文对象即可。

这主题主要是早期对 web audio api 的一些尝试，这里整理一下以便以后翻阅，如有错误，诚请指正。

在这之前，先回顾一下那些年我们一起走过的 web audio：

<bgsound>

在我印象当中，bgsound 是个很古老的东西，接触互联网之后，那时兴起的个人 blog 都有一个增加小组件或者背景音乐的功能，就是允许你贴入一段代码来实现，那是我最早接触 bgsound 的时候；当然那时也只是会 ctrl+c/v ~~

网上翻来些资料，大概是这样的：

早在 1996 年，IE3.0 定义了<bgsound> 的标签，这应该 web 最早的一个能播放音频的标签；但它却从未成为标准，由始至终只有 IE 支持该标签；提供的功能比较有限，简单的后台自动播放，支持.wav|.mid|.ua 格式音频；

前些时候有使用过 AngularJS 一些时间，最大的感受就是 Angular 完全颠覆了我们开发 Web 应用的方式，自己被其许多耳目一新的设计思想所折服。

首先想说的就是依赖注入（DI），这也意味着，你在使用某一个模块时，不需要去手动 require() 一下，你需要的模块会自己注入到的函数所在的作用域中，如：

上面的代码中，直接使用了 $http 的 post() 方法。那么问题来了：为什么可以这样？我们知道 JS 函数在调用时，其形参如果没有赋值就会是 undefined。能直接使用 $http 的 post() 方法，就说明 $http 是有对应的实参与之对应的。这是怎么发生的呢？下面，就让我们一起来揭开其中的秘密。

一： 如何在 JS 中实现 DI

在这之前，我们先回顾一下 toString 方法。在 JS 中，除了 null 和 undefined，其它所有的一切值都是有 toString() 方法的。函数也不例外，而且函数的 toString() 方法，是可以拿到函数定义的全部代码，甚至是注释。有了这一前提，我们可以实现一个获取函数形参的方法。

上周 Oscar 赴新加坡南洋理工大学（Nanyang Technological University, Singapore）参加 Mozilla 主办的 HTML5 集训及研讨会。活动主要是针对希望了解 HTML5 技术的在校学生，分享 HTML5 的当前状况、主要技术点以及一些实际应用，以帮助他们了解 HTML5 的强大能力和快速入门。

原文：http://coding.smashingmagazine.com/2012/11/05/writing-fast-memory-efficient-javascript/

作者：Addy Osmani

译者按：本人第一次翻译外文，言语难免有些晦涩，但尽量表达了作者的原意，未经过多的润色，欢迎批评指正。另本文篇幅较长、信息量大，可能难以消化，欢迎留言探讨细节问题。本文主要关注 V8 的性能优化，部分内容并不适用于所有 JS 引擎。最后，转载请注明出处: )

 什么是函数节流？

介绍前，先说下背景。在前端开发中，有时会为页面绑定 resize 事件，或者为一个页面元素绑定拖拽事件（其核心就是绑定 mousemove），这种事件有一个特点，就是用户不必特地捣乱，他在一个正常的操作中，都有可能在一个短的时间内触发非常多次事件绑定程序。而大家知道，DOM 操作时很消耗性能的，这个时候，如果你为这些事件绑定一些操作 DOM 节点的操作的话，那就会引发大量的计算，在用户看来，页面可能就一时间没有响应，这个页面一下子变卡了变慢了。甚至在 IE 下，如果你绑定的 resize 事件进行较多 DOM 操作，其高频率可能直接就使得浏览器崩溃。

使用事件代理

有时候我们会感觉到页面反应迟钝，这是因为 DOM 树元素中附加了过多的事件句柄并且些事件句病被频繁地触发。这就是为什么说使用事件代理是一种好方法了。如果你在一个 div 中有 10 个按钮，你只需要在 div 上附加一次事件句柄就可以了，而不用去为每一个按钮增加一个句柄。事件冒泡时你可以捕捉到事件并判断出是哪个事件发出的。