Good to know that Starling has that code. It sounds like a good direction.
> On Feb 21, 2025, at 10:01 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>
>>>
>
