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> > >>>> > >> > >> > >
