掌握Google Closure库：交互应用开发权威指南

需积分: 9 116 浏览量更新于2024-07-27 收藏 6.27MB PDF 举报

《闭包权威指南》是一本由Michael Bolin撰写的专业书籍，专注于JavaScript库Closure的深入理解和开发技术。这本书是Google在开发诸如Gmail和电子地图这类交互式应用时所依赖的核心工具之一，它解释了如何有效地利用Closure，一种强大的JavaScript特性，来提升代码的组织性、性能和模块化。 Closure，简单来说，是一种函数和其相关的引用环境的组合，这种环境包含了在函数定义时所有可用的变量和函数。它允许开发者创建私有变量，封装和重用代码，以及创建可维护和高效的工作模块。在JavaScript这样的动态类型语言中，Closure特别有用，因为它可以解决作用域问题，避免全局变量污染，并实现代码的模块化，这对于大型复杂项目管理至关重要。书中详细探讨了以下关键知识点： 1. **基本概念**：介绍Closure的基本原理，包括函数作为一等公民（first-class functions）、函数声明提升（hoisting）以及闭包的创建方式。 2. **作用域和内存管理**：阐述闭包如何保持对外部变量的持久引用，以及这种引用如何影响内存管理，特别是在异步编程中的延迟执行。 3. **模块和命名空间**：教授如何使用Closure创建独立的模块，以及如何通过命名空间组织代码，避免名称冲突。 4. **高级技巧**：涵盖闭包在事件处理、工厂模式、缓存策略等方面的应用，以及如何使用闭包优化性能和提高代码复用性。 5. **实战案例**：书中包含实际项目中的示例，展示如何在Gmail或电子地图这类大型应用中使用Closure设计和开发功能模块。 6. **最佳实践和注意事项**：提供编写高效、易于维护的闭包代码的实用建议，以及避免常见陷阱的方法。 7. **最新版本更新**：作为2010年首次出版的作品，它可能还包括了当时最新的Closure API和开发趋势，同时也关注了JavaScript语言的变迁对闭包的影响。《闭包权威指南》对于任何想要提升JavaScript编程技能，特别是对大型、交互式Web应用开发感兴趣的开发者来说，是一本不可或缺的参考书籍。无论是初学者还是经验丰富的开发者，都能从中获得宝贵的知识和实践经验。通过阅读和实践书中的内容，读者将能更好地掌握如何利用Closure进行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页未读，继续阅读

andyshar

粉丝: 65
资源: 3

掌握Google Closure库：交互应用开发权威指南

闭包权威指南] Closure：The Definitive Guide Michael Bolin

javascript权威指南_高清版pdf_1

闭包权威指南：JavaScript编程关键概念

闭包权威指南：JavaScript中的核心技术

JavaScript闭包详解：权威指南

闭包权威解析：掌握JavaScript的核心概念

javaScript权威指南

javascript权威指南

JavaScript权威指南

JavaScrip权威指南

最新资源