Closure Library is in Maintenance Mode

[shicks]

Closure Library is in Maintenance Mode

[rome-user]

Hello,

Although I don't like the news, I am still happy that Closure Compiler and Closure Library has existed for so long! I have one minor question, specifically:

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.

In ClojureScript, the traditional module system of Closure is used heavily to achieve late binding, and goog.define is useful for compile-time constants like goog.DEBUG and goog.debug.LOGGING_ENABLED. I am wondering if there will be an equivalent of both of these features after the compiler drops dependency on Closure Library.

If not, what would be the "next best thing" in modern JS ecosystem to replace both of these things when using the Closure compiler?

[dpup]

I've been out of google 12 years and can't quite believe Closure still exists. Thanks to everyone who has maintained and improved it over the years. It's come a long way from the days when a static bundle was being hosted on a workstation under my desk in building 47.

[shicks]

@rome-user

In ClojureScript, the traditional module system of Closure is used heavily to achieve late binding, and goog.define is useful for compile-time constants like goog.DEBUG and goog.debug.LOGGING_ENABLED. I am wondering if there will be an equivalent of both of these features after the compiler drops dependency on Closure Library.

goog.DEBUG is defined in base.js. Some portion of base.js will be moved into the compiler in some form, to be determined over the next few months. goog.DEBUG, specifically, does not actually have any direct intersection with the compiler, so you could easily make your own version of that, possibly even named the same thing if you want backwards compatibility. LOGGING_ENABLED toggles features of the goog.log library - in the long run, you'd probably be best to find a different logging library, such as any of these browser-compatible libraries, or obviously an even larger set if you're not in the browser. Unfortunately, I'm well aware that the broader ecosystem doesn't have a concept that quite maps exactly to goog.define and works across enough optimizers that libraries would adopt it - but a small shim layer could potentially bridge the gap, whereby you make your own goog.define and your exported (top-level/static) functions are no-ops if it's not set.

If not, what would be the "next best thing" in modern JS ecosystem to replace both of these things when using the Closure compiler?

As long as you're using Closure Compiler, you can still make whatever defines you want. It's ultimately up to the library how it's going to be configured, and there's no standard (across all optimizers) way to do compile-time constants. I believe the closest thing to a standard (at least for goog.DEBUG) is the NODE_ENV environment variable. Making this work smoothly enough across enough optimizers that libraries can just depend on it existing is a dream of mine, but sadly I'm not hopeful about it ever actually happening.

[shicks]

@teppeis

How about Closure Templates?

My understanding of Closure Templates is that it's been hobbling along with minimal maintenance for a while. It's maintained independently from Closure Library, so this announcement doesn't affect it directly. Theh currently plan is that it will fold anything it needs to from Closure Library into its own project, so that it's more self-contained. That said, my personal take on it is that it's not really a thriving project anymore, and even if it's not (yet) deprecated, you're still probably better off finding a more modern alternative, such as Lit, Web Components, or one of the many [TJ]SX-based libraries/frameworks.

[shicks]

@banguit

What the alternative to goog.ui.Component to have best compatibility with Closure Compiler?

We've used Lit and Angular quite successfully with Closure Compiler. I'd assume Web Components (being a DOM standard at this point) should also work well.

[shicks]

@bcsgh

• Are there any good replacement for the typing properties of goog.dom.createDom and goog.dom.TagName?

TypeScript handles this much better with string literal overloads of the built-in document.createElement function. For createDom, we've generally found that it lives in a kind of uncanny valley of utility, so we recommend against using it - you'r generally better off either just using createElement for very simple cases, or else a more proper templating system (e.g. TSX, Web Components, Lit, Angular, etc) for the more complex cases.

• Does the compiler have documented and official support for deducing the correct Element sub types when using the top post's suggestion of "JavaScript's built-in solutions"?

Closure Compiler does not, but we're also moving away from the Closure type system in favor of TypeScript, which supports this very well (see above). As I said in the OP, the Closure ecosystem was a great solution in its early days, but we've come to realize that it's just not state of the art anymore and trying to use it is really going against the grain in the prevailing external ecosystem. As much as is feasible, we're embracing these external solutions that have now solved the problems better than we ever did.

• Does JS have a built-in solution that can be used to get compile time errors when a tag name is typo'ed?

Again, see TypeScript and TSX.

• Are there any good "fail at compile time" replacements for goog.events.EventType?

I believe TypeScript's standard declarations (lib.dom.d.ts, etc) declare a mapping from event name to expected event type, which should provide some safety there. If not, you could easily define your own TS enum, or there's likely an off-the-shelf library on NPM that provides one (or if not, you could contribute it for a much broader reach than anything you'd get with Closure, since TS just has a massively larger user base).

Just in general; it would be nice to have a wiki or set of .md doc people can send PRs to with a mapping from existing libs to "things people have experience replacing them with". The further projects like this can stay away from the perception of doing a "we got board and lost interest, you're all on your own, not sorry, (╯°□°)╯︵ ┻━┻" the more likely people are to be willing to adopt other projects published by Google.

This is a great idea, but I'm not sure having it in this repo is the right place, since it's due to be archived later this year, at which point it would become read-only. GitHub is a pretty democratic place, so if anybody feels strongly about it, you're more than welcome to make such a repository and link it here for the benefit of future readers.

---

Finally, we are still here, and we check this issue roughly weekly. I can't say much about Google's internals, but as much as possible, in areas like this where the Google-built solution has fallen behind the industry standards, we're trying to migrate to better external solutions, though this is sometimes very challenging. For external users in a similar boat, we feel your pain (first hand) and you can keep using Closure Library (in its current state) as long as you need to, but we simply can't in good conscience recommend anyone adopt it today given the many better alternatives.

[shicks]

@lemito

Sorry, but since the closure library goes into maintenance mode and then archiving, how would a j2cl that transpiles java code into js code work? It also uses the closure library

Yes, j2cl depends on both Closure Compiler and Closure Library. We are committed to ensuring it continues to work. The library functionality that j2cl relies on will be folded into either the compiler or into j2cl's repository, depending on what makes the most sense. We'll be figuring out the details in the next few months.

[shicks]

This is not the only Google project using the Closure Library, there is also j2cl - they do their fork to keep the project running. So I think they will just develop their version or maintain it internally and only put out versions that affect application security

Thanks for bringing this up. To be clear, the Closure Library owners are working with these products to ensure that they remain intact. In cases where the internal remnants of Closure Library are still in use by these other projects, those projects are in the process of either migrating to more modern alternatives, or else adopting the shared code, in which latter case they'll release it (and any relevant security updates) per their own release schedules. Once the Closure Library repository is frozen/archived, it will no longer receive any updates (including security updates).

[lemito]

Hello. Is the project closed inside Google as well?

I have a strong suspicion that internally (most) stuff was transitioned before the announcement. At least as of a few years ago, Google had a habit of deprecation of old stuff before the new stuff is ready, but would keep it working as long as necessary. The odds that no must-fix bugs would be found in the time since the last update is slim to none if it was still being used.

To be honest, it's still not very clear what the fate of this library is.
My guess is that Google for Gmail, GSearch, etc. will continue with a separate, internal branch of the closure library or will seamlessly transition to their other solutions - angular 17/lit-html/server rendering via java closure-templates.
No comments from the developers yet and probably won't be, although it would be interesting to see the "inner kitchen" of modern Google, not through the research work of Larry Page and Sergey Brin.
Of course, this is most likely due to the policy of non-disclosure and confidentiality of information, but, again, there is a blog google search, but there rather exhibit DOODLES and information about the work of AI on the search, but not the principle of work at least the frontend of the search engine

[seyoung-song-walmart-com]

@sampajano Opened a discussion. grpc/grpc-web#1415. Using Bazel is necessary because all codes are maintained in a Bazel based monorepo. Here is example link. https://github.com/stackb/rules_proto/blob/master/example/routeguide/closure/client.js.

[teppeis]

How about Closure Templates?

[banguit]

What the alternative to goog.ui.Component to have best compatibility with Closure Compiler?

[bcsgh]

• Are there any good replacement for the typing properties of goog.dom.createDom and goog.dom.TagName?
• Does the compiler have documented and official support for deducing the correct Element sub types when using the top post's suggestion of "JavaScript's built-in solutions"?
• Does JS have a built-in solution that can be used to get compile time errors when a tag name is typo'ed?
• Are there any good "fail at compile time" replacements for goog.events.EventType?

---

Just in general; it would be nice to have a wiki or set of .md doc people can send PRs to with a mapping from existing libs to "things people have experience replacing them with". The further projects like this can stay away from the perception of doing a "we got board and lost interest, you're all on your own, not sorry, (╯°□°)╯︵ ┻━┻" the more likely people are to be willing to adopt other projects published by Google.

[lemito]

Hello. Is the project closed inside Google as well? So search engine, Workspace(including gmail) and other products using Closure Library will move to other technologies?

[bcsgh]

Hello. Is the project closed inside Google as well?

I have a strong suspicion that internally (most) stuff was transitioned before the announcement. At least as of a few years ago, Google had a habit of deprecation of old stuff before the new stuff is ready, but would keep it working as long as necessary. The odds that no must-fix bugs would be found in the time since the last update is slim to none if it was still being used.

[lemito]

Finally, we are still here, and we check this issue roughly weekly. I can't say much about Google's internals, but as much as possible, in areas like this where the Google-built solution has fallen behind the industry standards, we're trying to migrate to better external solutions, though this is sometimes very challenging. For external users in a similar boat, we feel your pain (first hand) and you can keep using Closure Library (in its current state) as long as you need to, but we simply can't in good conscience recommend anyone adopt it today given the many better alternatives.

Sorry, but since the closure library goes into maintenance mode and then archiving, how would a j2cl that transpiles java code into js code work? It also uses the closure library

[seyoung-song-walmart-com]

What is the best alternative for implementing grpc web client using Bazel? The closure example code looked like the most clean one that I could find in Google search.

[sampajano]

@seyoung-song-walmart-com Hi! Do you mind start a discussion on the question you have instead? Could you also provide pointers to the "closure example code" you referred to so we can better understand your question? Thanks! Typically, npm would be the recommended way to use grpc-web (instead of Bazel).

[lemito]

@sampajano Opened a discussion. grpc/grpc-web#1415. Using Bazel is necessary because all codes are maintained in a Bazel based monorepo. Here is example link. https://github.com/stackb/rules_proto/blob/master/example/routeguide/closure/client.js.

This is not the only Google project using the Closure Library, there is also j2cl - they do their fork to keep the project running.
So I think they will just develop their version or maintain it internally and only put out versions that affect application security