Closure Library going into Maintenance Mode

[Steve Hicks]

If you prefer reading this as a GitHub issue, see #1214.

TL;DR: Closure Library will be sunset over the next 9 months. We no longer see it as meeting the needs of modern JavaScript development, and we recommend that users look for alternative solutions. Feel free to skip the introduction and go straight to the FAQ.

Dear Closure Library Users,

In the nearly 14 years since Closure Library was first made public, it's broken a lot of ground and paved the way for numerous ecosystem features that we take for granted today. At the initial release in 2009, Internet Explorer 8 was brand new, Chrome had just released version 3, the iPhone 3GS was fresh, and ECMAScript 5 was still just around the corner. Browser implementations varied widely in basic language and DOM support, with very different event models and quirks around every corner. Dependencies were generally managed manually by loading scripts in the right order.

Closure Library brought some amazing innovations to this ecosystem by providing a common library that glossed over browsers' many differences and allowed authors to focus on features and logic, rather than compatibility and quirks. It provided a full-featured debug loader, a wide swath of versatile tools, and a large gallery of prepackaged composable widgets that anybody could use to build web apps at a scale previously unimagined. And the type checker provided a level of static analysis that was previously unheard of in JavaScript.

But these same innovations that were groundbreaking at the time are now starting to feel a bit old and dated. CommonJS and ES Modules are the gold standard for dependency management; the language has evolved and added new, safer, and more ergonomic APIs for many basic features like classes or events; we now have TypeScript that provides a far more expressive type system than Closure; and groups like WICG and TAG have substantially reined in the divergences between different browsers. In short, the world has moved on and we believe it no longer needs Closure Library. These days, rather than elevating a project to modern practices, a dependency on Closure Library seems to feel more like something weighing a project down, holding it back from modern standards and greater adoption. In light of this, we've made the difficult decision that it's time to thank Closure Library and its many authors and contributors for all they've done for us over the years, and to bid it farewell.

FAQ

What is happening?

On November 1, 2023, we will transition Closure Library into maintenance mode. After this date, we will only push critical commits to the GitHub repository, respond to critical issues, and merge critical pull requests. On August 1, 2024, we plan to permanently freeze and archive the GitHub repository, after which no new commits or releases will be pushed at all.

During this time, we recommend looking for alternative solutions so that dependent projects can continue to receive critical security updates into the future.

Why are we doing this?

We no longer see Closure Library accomplishing its mission of improving the way JavaScript is written, and we honestly believe our users would be better served elsewhere.  In particular, Closure Library's monolithic approach has become an anti-pattern in today's world of package managers and bundlers.

What about Closure Compiler?

We still believe that Closure Compiler is the best advanced optimizer in terms of minified size, as long as it can assume that all input code meets its strict requirements.  While these requirements are sometimes difficult to guarantee for hand-written JavaScript, it's still very relevant as a compilation target for languages such as Java (via J2cl) or C++ (via emscripten), which can enforce the compiler's requirements more effectively.  For users hand-writing JavaScript, we see TypeScript as a better authoring language, even if Closure Compiler continues to be used for optimization.

All this said, Closure Compiler and Library have a number of intersection points where they interdepend on one another.  We are committed to retaining the core functionality in Closure Compiler, while dropping its dependency on Closure Library.  This includes Closure dependency management (goog.module, goog.require, etc), reflection (goog.reflect.object, goog.reflect.objectProperty), defines (goog.define), and a few others.

What do I need to do?

No immediate action is required.  A final version of the library will remain available for download from GitHub and NPM indefinitely (even after all updates are stopped), and  API documentation will remain available at google.github.io/closure-library/api.  There are no plans to remove any hosted versions of the library from CDNs.  You can continue to use any previously-published versions of the library with no interruption as long as it serves your purposes.  With that said, however, migrating to modern alternatives will likely be required at some point in the future to keep up with the ever-evolving web and security ecosystems.

What alternatives should I consider?

In the last decade, the NPM ecosystem has flourished.  For most use cases where JavaScript's built-in solutions are insufficient, a quick search on NPM will turn up plenty of active projects that are likely to be better integrated with modern practices and more responsive to issues.  While we can't endorse any of the non-Google libraries below, we list a few suggestions to help start a search:

• For many parts of the library (goog.array, goog.dom, goog.events, goog.json, etc), JavaScript's built-in solutions should be sufficient.

• For many special-purpose packages (math, data structures, other algorithms), a small focused library is often better than Closure's monolithic approach.

• For networking (goog.net), much of the older functionality is subsumed by fetch and the streams APIs.  WebChannel will live on in some form to support Firebase.

• For SafeHTML (goog.html), we recommend migrating to safevalues.

• For cryptography (goog.crypt), we recommend the built-in crypto.subtle API, or targetted utility libraries.

• For internationalization and localization (goog.i18n) we recommend the built-in Intl API.

• For accessibility (goog.a11y), ARIA and semantic HTML are now much more universally usable.

• For protocol buffers (goog.proto, goog.proto2), consider protobufjs or ts-proto.

• For UI components (goog.ui and other CSS/style-related packages), consider any of the modern frameworks (Angular, React, Lit, Vue, etc).

• For rich text editing (goog.editor), there are numerous modern libraries (Quill, Slate, TinyMCE, etc).

• For testing, consider any of the modern BDD frameworks (Jasmine, Chai, Mocha, Jest, etc).

=====

Thanks for your understanding,

The Closure Library Maintainers