Thanks Josh, that's all helpful to know. iirc I think we are also currently blocked from updating our closure compiler version because of some local subclasses or overrides where the base classes or implementation was changed inside in a more recent GCC version, but it's been some time since I tried to look into that, so I might be wrong.
In terms of events, I'd be happy to look at that in several months time if we can wait, I will likely not find time before that. Lots of things changed in js since the start, and it seems that if we really wanted to we could support weak event listeners now, for example. more modern outputs from our compiler are another future option, which might make debugging in the js version of the code much easier. -Greg On Fri, Feb 21, 2025 at 12:20 PM Josh Tynjala <joshtynj...@bowlerhat.dev> wrote: > Hi team, > > Today, I noticed that the GitHub repo for Google's Closure Library is now > archived/read-only, and the README contains the following message. > > Closure Library has been archived. We no longer see it as meeting the needs > > of modern JavaScript development, and we recommend that users look for > > alternative solutions. > > > > Please see https://github.com/google/closure-library/issues/1214 for > more > > details. > > > This applies to Closure Library only. We also use the related Closure > Compiler in Royale. Google addresses Closure Compiler specifically in the > issue mentioned above: > > 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. > > > So even if we decide to eventually drop Closure Library, we can continue to > use Closure Compiler to create optimized release builds. > > It also appears that we can continue to use the goog.provide/goog.require > module system with Closure Compiler. The parts of Closure Library that > include the module system appear to have been migrated (or are in the > process of being migrated) to Closure Compiler here: > > https://github.com/google/closure-compiler/tree/master/lib > > In the royale-asjs codebase, you can search for "import goog." to discover > which other parts of Closure Library that we currently use in Royale. > Ideally, that usage should probably start trending downward. > > We use the goog.html package for HTML sanitation. I see that Google > specifically recommends the following library as a replacement: > > https://github.com/google/safevalues > > Our biggest use is probably of the goog.events package. I think that we can > reduce some of it relatively easily (like the goog.events.EventType > constants). Calls to goog.events.listen() may be easy to replace too. > > However, the trickiest part is our EventDispatcher class that extends > goog.events.EventTarget. Extending goog.events.EventTarget instead of > writing a custom implementation was probably mostly for convenience. If we > want to replace it with our own custom implementation, we'll definitely > want a good set of automated tests to ensure no regressions. Starling > Framework, an AS3 library with its own EventDispatcher implementation, has > a good set of tests that we might consider adopting, if we choose to > migrate away from goog.events.EventTarget. > > Anyway, I just wanted to spread awareness of the state of Closure Library, > since we currently depend on it. It was officially deprecated in November > 2023, and archived and made read-only in August 2024. > > -- > Josh Tynjala > Bowler Hat LLC <https://bowlerhat.dev> >
