Glad to hear. :-)
> On Dec 29, 2021, at 11:17 PM, Maria Jose Esteve <mjest...@iest.com> wrote:
>
> I love this!!! thanks Harb
>
> Hiedra
>
> -----Mensaje original-----
> De: Harbs <harbs.li...@gmail.com>
> Enviado el: miércoles, 29 de diciembre de 2021 12:11
> Para: Apache Royale Development <dev@royale.apache.org>
> Asunto: Re: Compiler options for reducing release build size of Royale
> projects (Part 2)
>
> Done:
> https://apache.github.io/royale-docs/create-an-application/optimizations/minification
>
>> On Dec 29, 2021, at 8:11 AM, Harbs <harbs.li...@gmail.com> wrote:
>>
>> I plan on writing a minification documentation page which explains all of
>> this and the take-aways from my (and Josh’s) efforts.
>>
>>> On Dec 29, 2021, at 8:09 AM, Harbs <harbs.li...@gmail.com
>>> <mailto:harbs.li...@gmail.com>> wrote:
>>>
>>> Let me qualify that.
>>>
>>> If you use "-js-dynamic-access-unknown-members=true” all untyped members
>>> are quoted.
>>>
>>> If you don’t use "-js-dynamic-access-unknown-members=true”, then the
>>> minification even without exports should work fine, but then you need
>>> to make sure you quote any Object members where the name is
>>> significant (i.e. data coming from JSON, etc.)
>>>
>>> If you need "-js-dynamic-access-unknown-members=true”, then you will get
>>> accessor mismatches unless you consistently use data types and not “Object”
>>> or “*”. Included in that is access to Array members (i.e.
>>> myArray[i].fooBaz() is a no-no because it will get quoted on output).
>>> Neither Jewel nor MX/Spark was written with that in mind. It’s fixable, but
>>> it will take time. I fixed the general framework classes, but those
>>> component sets were not within scope for me.
>>>
>>> HTH,
>>> Harbs
>>>
>>>> On Dec 29, 2021, at 8:01 AM, Yishay Weiss <yishayj...@hotmail.com
>>>> <mailto:yishayj...@hotmail.com>> wrote:
>>>>
>>>>> 1. Jewel does not look like it can be aggressively minified.
>>>>> (Spectrum can.) 2. MX/Spark does not look like it can either.
>>>>
>>>> Can you explain this?
>>>>
>>>>
>>>> From: Harbs<mailto:harbs.li...@gmail.com
>>>> <mailto:harbs.li...@gmail.com>>
>>>> Sent: Tuesday, December 28, 2021 11:36 PM
>>>> To: Apache Royale Development<mailto:dev@royale.apache.org
>>>> <mailto:dev@royale.apache.org>>
>>>> Subject: Re: Compiler options for reducing release build size of
>>>> Royale projects (Part 2)
>>>>
>>>> After 2 weeks of intense work, I got my app fully functional with the
>>>> options below.
>>>>
>>>> Here’s in short what I did:
>>>>
>>>> 1. I audited as many cases of quoted access I could in the unminified JS
>>>> code. Any place where it was accessing something on a class/instance was
>>>> because the compiler couldn’t figure out the type.
>>>> 2. I added types to all the places I could find. I basically eliminated
>>>> every use of :Object and :* that I could.
>>>> 3. I used Vectors where I could (using the
>>>> -js-vector-emulation-class=Array option) 4. I removed unknown class
>>>> accessors (no looping through classes and calling static methods) 5.
>>>> Removed all the dynamic bracket access and assignment. (no for-ins
>>>> on class instances, etc.)
>>>>
>>>> In my travels I discovered that:
>>>> 1. Jewel does not look like it can be aggressively minified.
>>>> (Spectrum can.) 2. MX/Spark does not look like it can either.
>>>> 3. I need to heavily modify my already modified version of TLF to get it
>>>> to work with minification.
>>>> 4. There was some unnecessary Reflection and Vector dependencies in
>>>> framework code which I fixed.
>>>> 5. Class names is a prime candidate for code removal, and (besides
>>>> reflection) the current roadblock with that is SimpleCSSValuesImpl which
>>>> accesses ROYALE_CLASS_INFO. If we can eliminate that, I’d save 66KB (12KB
>>>> gzipped) in my app.
>>>> 6. It’s worthwhile to use protected methods for event listener
>>>> callbacks, because the long-winded private method names end up in
>>>> the minified code. (I still need to address this.)
>>>>
>>>> End results:
>>>>
>>>> Before my effort, my app was 2,903,814 bytes and 777,071 bytes when
>>>> gzipped
>>>> Afterwards: 1,989,596 bytes and 621,851 bytes gzipped
>>>>
>>>> That’s a savings of 1MB before gzipping (about 1/3) and 155KB after
>>>> gzipping. (about 20% reduction)
>>>>
>>>> If we can get rid of the class names we can get down to: 1,923,653
>>>> bytes/610,493 bytes.
>>>>
>>>> A little over 600KB is a totally reasonable size for an application of
>>>> this size and complexity. The Flash version was MANY times that and has a
>>>> LOT less code.
>>>>
>>>> This turned into somewhat of an obsession for me, but I’m pleased
>>>> with the results. :-)
>>>>
>>>> HTH,
>>>> Harbs
>>>>> On Dec 16, 2021, at 8:54 PM, Harbs <harbs.li...@gmail.com
>>>>> <mailto:harbs.li...@gmail.com>> wrote:
>>>>>
>>>>> Well I spent more time. Besides the XML issues which are pretty much
>>>>> resolved, I ran into:
>>>>>
>>>>> 1. I have a setter in a class which was removed by the goog dead code
>>>>> removal. I worked around it by turning the setter into a method. I’ll see
>>>>> if I can come up with a minimal test case on that.
>>>>>
>>>>> 2. I have a library which has a LOT of dynamic pieces. I spent a LONG
>>>>> time trying to assign types to places where I was getting runtime errors.
>>>>> I now got to the point where there’s no more runtime errors, but it’s
>>>>> still not working and I’m pretty sure it’s because I missed some typing.
>>>>>
>>>>> Is there any way to keep public accessors on one library or specific
>>>>> classes? I’d like to compile my app with:
>>>>>
>>>>> "-js-dynamic-access-unknown-members=true",
>>>>> "-export-public-symbols=false",
>>>>> "-prevent-rename-protected-symbols=false",
>>>>> "-prevent-rename-public-symbols=false",
>>>>> "-prevent-rename-internal-symbols=false"
>>>>>
>>>>> but be able to exclude a list of classes from that.
>>>>>
>>>>>> On Dec 1, 2021, at 7:47 PM, Harbs <harbs.li...@gmail.com
>>>>>> <mailto:harbs.li...@gmail.com> <mailto:harbs.li...@gmail.com
>>>>>> <mailto:harbs.li...@gmail.com>>> wrote:
>>>>>>
>>>>>> I’m pretty sure the issue is related to events not being properly
>>>>>> handled. Although blinding might be worth looking into.
>>>>>>
>>>>>> I’ll look into it some more when I have more time.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>>> On Dec 1, 2021, at 7:14 PM, Josh Tynjala <joshtynj...@bowlerhat.dev
>>>>>>> <mailto:joshtynj...@bowlerhat.dev> <mailto:joshtynj...@bowlerhat.dev
>>>>>>> <mailto:joshtynj...@bowlerhat.dev>>> wrote:
>>>>>>>
>>>>>>>> It *almost* works. I found and fixed two cases of bracket access
>>>>>>>> which
>>>>>>> broke things. Now I’m getting no errors, but it’s still not quite
>>>>>>> working.
>>>>>>> I’m guessing it’s something simple that I need to fix.
>>>>>>>
>>>>>>> Have you tried a smaller set of prevent-rename options? That
>>>>>>> might help you narrow things down, if things start working
>>>>>>> better. I'd try allowing public variables, and maybe public
>>>>>>> accessors, to be renamed first, and see if that works. Those
>>>>>>> types of symbols are most likely to be getting accessed
>>>>>>> dynamically somehow. However, I don't really have much in the way
>>>>>>> of tips to narrow it down from there. ConstantBinding would be one
>>>>>>> thing to look out for, which I mentioned in my summary.
>>>
>>
>
