JavaScript 核心

202014年05月

此文译自 Dmitry A. Soshnikov 的 JavaScript. The core..

本文是详解 ECMA-262-3 系列的概述和总结。每个部分都包含对应章节的连接，所以你可以阅读它们以获得更深入的了解。

目标阅读者：有经验的程序员，专业人士。

我们从对象的概念开始，这是 ECMAScript 的根本。

面向切面编程（AOP）简介

082014年05月

原文连接：Intro to Aspect Oriented Programming

本文简单地介绍了 AOP 的原理，以及 AOP 与其他方式的异同，并没有涉及太多的复杂逻辑，另外推荐下面两篇文章，这些文章中都间接或直接提及了 AOP：

面向切面编程（AOP）是一种非侵入式扩充对象、方法和函数行为的技术。通过 AOP 可以从“外部”去增加一些行为，进而合并既有行为或修改既有行为。

虽然有很多技术可以用来增加和合并行为，例如继承、组合、委托，然而，在很多情况下，AOP 被证明是更灵活和更少侵入的方式，非常值得将其纳入我们的工具箱中。

前端跨域通信解决方案

222014年04月

此类文章在社区中一抓一大把，但为什么还要来翻译这篇文章呢？最主要的原因是本章的配图太好了，一看就懂，扯远了。。

原文：Improve cross-domain communication with client-side solutions

介绍

越来越多的网站需要相互协作。例如，一个在线房屋租赁网站需要谷歌地图的支持，以显示某个出租屋的位置。为了满足这种需求，出现了各种各样的聚合应用（mashup）。聚合应用是一种将来自不同供应商的数据或组件整合在一起，使其更有价值或更加可定制化的 Web 应用。聚合应用或协作能力，被认为是 Web 2.0 的一个重要组成部分

但是，要将异步 AJAX 和聚合应用结合在一起并不是那么容易，由于浏览器的安全限制，页面上不同组件之间的通信也难以做到。传统的解决方案是，在服务器上设置一个代理，但这种方式的伸缩性不大。在本文中，你可以了解到一些客户端的跨域通信和数据传输的解决方案。

安全限制

同源策略（SOP）将阻止从一个源加载的脚本去操作另一个源的数据或方法，同源要求脚本的域名、协议和端口都相同，你可能会误解同源策略，它不仅仅意味着站点 A 不允许从站点 B 获取信息，你需要知道在同源策略下能做什么和不能做什么。

同源策略的限制

例如，A 源中的页面可以：

从 B 源获取脚本、样式和图片文件
使用 iframe/frame 嵌入指向 B 源的页面
通过 HTML 元素（如 iframe 或 img）的 src 属性，向 B 源发送信息

A 源中的页面不能：

向 B 源发送 AJAX 请求
读取或操作通过 iframe/frame 嵌入的 B 源页面的内容

为什么会这样？主要是为了保护用户的重要信息。假设，一个用户正在访问某个网站，他不希望提交到该网站的任何信息被泄露给其他网站。这种限制限制了网站之间的合作，但可以保护用户免受潜在的恶意攻击。

接下来的章节将讨论跨域通信和数据传输的客户端解决方案。每一种解决方案都有优缺点，应用场景在很大程度上影响你的选择。

大型 JavaScript 架构中的设计模式

212014年04月

我们今天要讨论的主题是，大型 JavaScript 应用中一些有效的设计模式。本文基于我最近发布在 LondonJS 上同名演讲，灵感则来自于 Nicholas Zakas 之前的研究成果。

我是谁以及我为什么要撰写这个主题？

我目前是 AOL 的一名 JavaScript 和 UI 开发人员，负责规划和编写下一代面向用户的应用的前端架构。这些应用不仅复杂，而且需要一种可扩展和高复用的架构，我的职责之一就是确保这类应用中的设计模式尽可能是可持续的。

尽管在这个领域有许多比我知识渊博的专家，我也认为自己是设计模式的狂热者。先前，我基于 Creative Commons 许可写了《Essential JavaScript Design Patterns》一书，现在我正在为此书撰写更详尽的后续版本。

140 个字的全文概述

如果你时间不够，下面是本文的概述，只有一条 tweet 的长度。

应用解耦。架构/模块，外观模式和中介模式。模块发布消息，中介管理发布/订阅，外观处理安全问题。

什么是“大型” JavaScript 应用

正式开始之前，我们先尝试为“大型” JavaScript 应用下个定义。我发现，即便是在这个领域有多年开发经验的开发者，对于这个问题他们的答案都可能很主观。

作为实验，我询问了一些中级开发者，让他们试着作一个非正式的定义。一个开发者认为是代码超过 100,000 行的 JavaScript 应用，而另一个则认为是源代码超过 1M 的 JavaScript 应用。他们的答案很大胆，但都准确，因为代码量的大小不总是和应用的复杂度相关，100,000 行代码也可能是相当琐碎的代码。

虽然我的定义并不一定是普遍观点，但我认为这更接近大型 JavaScript 应用的本质：

在我看来，大型 JavaScript 应用是那种非琐碎，并且需要大量开发人员努力维护的应用，在浏览器端有繁重的数据操作和显示处理。

也许，该定义的最后一句话才是最重要的。

HTTP cookies 详解

212014年04月

HTTP cookies，通常称之为“cookie”，已经存在很长时间了，但是仍然没有被充分理解。首要问题是存在许多误解，认为 cookie 是后门程序或病毒，却忽视了其工作原理。第二个问题是，对于 cookie 的操作缺少统一的接口。尽管存在这些问题，cookie 仍旧在 Web 开发中扮演者重要的角色，以至于如果没有出现相应的代替品就消失的话，我们许多喜欢的 Web 应用将变的不可用。

早期的 Web 应用面临的最大问题之一就是如何维持状态。简言之，服务器无法知道两个请求是否来自于同一个浏览器。当时，最简单的办法就是在请求的页面中插入一个 token，然后在下次请求时将这个 token 返回至服务器。这需要在页面的 form 表单中插入一个包含 token 的隐藏域，或者将 token 放在 URL 的 query 字符串中来传递。这两种方法都需要手动操作，而且极易出错。

当时网景通讯的一名员工 Lou Montulli，在 1994 年将 “magic cookies” 的概念应用到 Web 通讯中。他试图解决 Web 的第一个购物车应用，现在购物车成了购物网站的支柱。他的原始说明文档提供了 cookie 工作原理的基本信息，该文档后来被作为规范纳入到 RFC 2109（大多数浏览器的实现参考文档）中，最终被纳入到 RFC 2965 中。Montulli 也被授予 cookie 的美国专利。网景浏览器在它的第一个版本中就开始支持 cookie，现在所有 Web 浏览器都支持 cookie。