Ah, got it, Josh, sorry I missed the detail earlier. I'm keen to be involved when time permits (not soon I'm afraid) to make sure we get 'current' if we can.
I haven't kept up on openfl, but it sounds like what you did there with WeakRef for event listeners was the same thing I had in mind. I will have to take another look at haxe etc, I used to be active in that community a long (long!) time ago. -Greg On Tue, Feb 25, 2025 at 5:40 AM Josh Tynjala <joshtynj...@bowlerhat.dev> wrote: > I should be clear that I'm specifically trying to use the module system > that was introduced in ES2015 as an alternative to our current use of goog > module. Nothing else introduced in ES2015 is currently on my radar. If > there are other features introduced in ES2015 (or later) standards that > would improve our generated JS, we should definitely talk about those. > However, I consider that a separate task from the one that I'm working on > right now. > > -- > Josh Tynjala > Bowler Hat LLC <https://bowlerhat.dev> > > > On Sat, Feb 22, 2025 at 12:22 PM Greg Dove <greg.d...@gmail.com> wrote: > > > Nice, Josh. Did you also consider making the leap to es2022 ? > > Whatever concerns people have about browser support levels may not be > > irrelevant, not just because they may not be in - for example - another 2 > > years or so, but because I believe GCC supports transpiling es2022 down > to > > es2015 or es6 for the minified release build, in any case. And debugging > in > > debug builds (and possibly native reflection etc) with es2022 output > would > > be easier with things like private class members etc. > > > > > > On Sun, Feb 23, 2025 at 7:45 AM Harbs <harbs.li...@gmail.com> wrote: > > > > > 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> > > > >>>> > > > >> > > > >> > > > > > > > > >
