An ECMA 2015 target sounds really good! Out of curiosity: Is dealing with circular dependencies any tricker with that target than goog.provide?
Maybe we should coordinate the work on migrating events? > On Feb 21, 2025, at 6:48 PM, Josh Tynjala <joshtynj...@bowlerhat.dev> wrote: > > 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> >>>> >> >>
