I'm currently working to implement a new Royale target that outputs ECMAScript 2015 standard modules instead of goog.provide modules. I got a pure AS3 project working well with native imports, but once I start trying to use anything involving EventDispatcher, the GCL dependencies become a hurdle. It looks like I either still need to continue to call goog.require() for those classes specifically (but I'm actually hoping to get rid of the base.js loader from GCL for this target), or I need to generate <script> tags in the HTML for the GCL classes that are referenced.
-- Josh Tynjala Bowler Hat LLC <https://bowlerhat.dev> On Fri, Feb 21, 2025 at 12:02 AM Harbs <harbs.li...@gmail.com> wrote: > One of the things I’ve wanted to tackle for a long time is getting rid of > the dependency on goog events. > > There’s really no technical reason why we still need it. Most of the > advantage of the goog event library is with handling really old browsers > which there’s no reason to support anymore. > > Harbs > > > On Feb 21, 2025, at 7:03 AM, Greg Dove <greg.d...@gmail.com> wrote: > > > > 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> > >> > >
