JavaScript闭包深入解析

需积分: 9 110 浏览量更新于2024-07-31 收藏 4.53MB PDF 举报

"《JavaScript闭包：权威指南》迈克尔·波林" 《JavaScript闭包：权威指南》是迈克尔·波林撰写的一本深入解析JavaScript闭包的著作，由O'Reilly Media出版。这本书针对JavaScript开发人员提供了一个详尽的闭包知识体系，帮助读者理解和掌握这个在JavaScript编程中至关重要的概念。闭包是JavaScript中的一个核心特性，它允许函数访问和操作其定义时的作用域，即使该函数在其外部作用域被调用。这一特性使得JavaScript能够实现数据隐藏、模块化、记忆化等高级编程技巧。书中详细介绍了以下知识点： 1. **闭包的基本概念**：解释了什么是闭包，以及它如何在JavaScript中工作。闭包是由函数和与其相关的引用环境组合而成的一个整体，这个引用环境包含了函数在创建时所能访问的所有变量。 2. **作用域链**：闭包与作用域链密切相关，书中详细讨论了JavaScript的作用域规则，包括全局作用域、局部作用域以及函数内部的变量查找机制。 3. **函数作为值**：在JavaScript中，函数可以被赋值给变量、作为参数传递和作为返回值，这是闭包得以实现的基础。书中会阐述如何利用这种特性来创建闭包。 4. **内存管理与垃圾回收**：闭包可能导致变量长时间保留在内存中，因此理解内存管理和垃圾回收机制对于避免内存泄漏至关重要。书中有专门的章节讲解这个问题。 5. **模块模式**：闭包是实现JavaScript模块化的一种常见方式，通过闭包可以创建私有变量和方法，同时提供公共接口。 6. **异步编程**：闭包在处理异步操作（如回调函数、Promise或async/await）时起着关键作用，因为它能保持对上下文的引用，解决回调地狱问题。 7. **性能优化**：如何有效地使用闭包，避免潜在的性能陷阱，以及如何在大型应用中管理闭包带来的内存消耗。 8. **错误处理与调试**：在涉及闭包的代码中，错误处理和调试可能会更加复杂，书中将介绍如何有效地进行这类操作。 9. **案例研究**：通过实际的代码示例和应用场景，作者展示了闭包在解决实际问题时的应用，如事件处理、定时器、缓存等功能的实现。 10. **最佳实践**：提供了一些编写高效、可维护的闭包代码的最佳实践和技巧，帮助开发者养成良好的编程习惯。这本书适合已经有一定JavaScript基础的开发者阅读，通过深入学习，读者将能够更好地理解和利用闭包这一强大的工具，提升JavaScript编程技能。

You’ll find answers to many of those specific questions throughout this book. But I

think the question that the book is most interested in (and rightly so) is about how to

make it easy to reuse code for Ajax apps. It spins off into a few other equally substantial

questions.

How do you share JavaScript code? How do you organize large amounts of common

JavaScript, often built for highly specialized tasks? How do you weigh one team’s need

for boatloads of new features and customizations against another team’s need to keep

the size of the JavaScript they’re sending to the user small?

The Closure Tools were designed to solve many of these problems. Maybe that’s un-

derstating the point. These problems are at the very core of their design. Many of the

tools were started by our friends on Gmail. Gmail began as a relatively modest Java-

Script app. Then they added more and more features, and watched it grow beyond any

hope of control or maintainability. Frederick P. Brooks, Jr., famously described large-

system programming as “a tar pit, and many great and powerful beasts have thrashed

violently in it.” In a language like JavaScript, a highly dynamic environment where

almost everything can be mutated and there’s no standard way to specify contracts

(type checking or otherwise), the tar is fast and can suck down even a small group of

developers.

The Closure Tools developers tried to bring “closure” to this mess. (I agree the pun is

terrible. It is not mine.) They followed strict idioms for namespacing code and defining

classes. They adopted ECMAScript 4’s type language for specifying contracts. The

compiler forced the developer to declare their variables, and emitted warnings for other

frowned-upon idioms. The Closure Tools, in short, tried to add some structure to the

language. Many engineering teams at Google found this structure useful, and built their

products on top of it.

A long time passed. The Closure Tools remained proprietary for years. This wasn’t

meant to be. Both the compiler and the libraries were always designed to be open source

projects. But more importantly, they were designed for building Google apps first, and

to be open source projects second. So releasing them publicly took a back seat to other

things.

Have you ever tried to publicly open up the code of a proprietary project? Several en-

gineers had tried to release Closure Compiler. They had all given up. It is surprisingly

difficult. There are two major parts. First, you have to release the code: port it to a

public build system like Apache Ant, remove all of its nonopen dependencies, and

rewrite any dependencies that you can’t remove. Second, you have to write documen-

tation: loads of documentation.

You can imagine how skeptical I was when Michael first came by my desk to talk about

making Closure Compiler an open source project. This was early 2009. By this point,

“publicly releasing Closure Compiler” was the sort of daunting chore that you’ve pro-

crastinated forever and a half. We’d work on it for a month, realize that we seemed no

xiv | Foreword

Preface

JavaScript borrows many great ideas from other programming languages, but its most

unique, and perhaps most powerful, feature is that any code written in JavaScript can

run as-is in any modern web browser. This is a big deal, and it is unlikely to change

anytime soon.

As web browsers improve and become available on more devices, more applications

are being ported from desktop applications to web applications. With the introduction

of HTML5, many of these applications will be able to work offline for the first time. In

order to create a superior user experience, much of the logic that was previously done

on the server will also have to be available on the client. Developers who have written

their server logic in Java, Python, or Ruby will have to figure out how to port that server

logic to JavaScript. Tools like Google Web Toolkit, which translate Java to JavaScript

can help with this, though such tools are often clumsy because the idioms from one

programming language do not always translate smoothly into that of another. How-

ever, if your server code is written in JavaScript, this is not an issue.

I believe that the use of server-side JavaScript (SSJS) is just beginning. Previously, most

implementations of JavaScript were too slow to be considered a viable option for server

code. Fortunately, the recent competition among browser vendors to have the fastest

JavaScript engine makes that difference far less significant (http://shootout.alioth.debian

.org).

Because of the emerging support for offline web applications, it is compelling to write

both the client and the server in the same programming language to avoid the perils

associated with maintaining parallel implementations of the same logic. Because it is

extremely unlikely that all of the major browser vendors will adopt widespread support

for a new programming language, that will continue to force the client side of a web

application to be written in JavaScript, which in turn will pressure developers to write

their servers in JavaScript as well. This means that the size of the average JavaScript

codebase is likely to increase dramatically in the coming years, so JavaScript developers

will need better tools in order to manage this increased complexity. I see Closure as the

solution to this problem.

xvii

Closure is a set of tools for building rich web applications with JavaScript, and brings

with it a new approach to writing JavaScript and maintaining large JavaScript applica-

tions. Each tool in the suite is designed to be used independently (so jQuery developers

can make use of the Closure Compiler and Closure Templates, even if they are not

interested in the Closure Library), but they are most effective when used together.

Many JavaScript toolkits today focus on DOM utilities and UI widgets. Such function-

ality is incredibly useful when building the interface for a web application, but the

emergence of SSJS will require an equivalent effort in building server-side JavaScript

libraries. There, the focus is likely to be on data structures and efficient memory usage,

both of which are already woven into the Closure framework.

I believe that Closure will play an important part in making web applications faster and

more reliable. As an active user of the Web, I have a vested interest in making sure this

happens. That’s why I had to write this book. Rather than document every API in

Closure, I have tried to provide detailed explanations for the most commonly used

APIs, particularly those that are unique to the Closure approach.

Indeed, learning Closure will change the way you develop JavaScript applications.

My Experiences with Closure

When I worked at Google from 2005 to 2009, I used Closure to help build Google

Calendar and Google Tasks. When the initial work on Calendar was done in 2005, only

the Compiler was available, and it was (and is) known internally as the JavaScript

Compiler. At the time, there were a number of common JavaScript utilities that teams

would copy from one another. This led to many forked versions, so improvements to

one copy did not propagate to the others.

Meanwhile, the JavaScript codebase for Gmail had grown so large and complex that

developers complained that it was too hard for them to add new features. This triggered

a rewrite of the Gmail client, which precipitated the development of the two other major

tools in the Closure suite: the Library and Templates. The Library was simply named

“Closure,” as it was a play on the programming construct used so frequently in Java-

Script, as well as the idea that it would bring “closure” to the nightmare that was

JavaScript development at Google.

Like many other JavaScript toolkits, the goal of Closure was to provide a comprehensive

cross-browser library. Instead of adopting an existing solution, such as Dojo, Google

decided to roll its own. By having complete control of its library, it could ensure that

the API would be stable and that the code would work with its (then) secret weapon:

the Closure Compiler. This made it possible to buck the trend established by libraries

like Prototype that encouraged the use of absurdly short function names. In Closure,

nondescript function names such as $ were eschewed in favor of more descriptive ones

because the Compiler would be responsible for replacing longer names with shorter

ones.

xviii | Preface

剩余592页未读，继续阅读

derektu123

粉丝: 0
资源: 2

JavaScript闭包深入解析

Google Javascript Closure Compiler

Closures:这个存储库包含 JavaScript Closure 演示

Javascript闭包（Closure）详解

JavaScript闭包(closure).pdf

学习Javascript闭包（Closure）知识

broccoli-closure-compiler:使用Closure编译器缩小JavaScript

javascript闭包(Closure)用法实例简析

JavaScript知识点总结(十六)之Javascript闭包（Closure）代码详解

javascript中闭包(Closure)详解

JavaScript 闭包深入理解(closure)

最新资源