The compiler is theoretically designed to allow for different Emitters and
Publishers that can output different JS to support other module and
minification systems. Volunteers are welcome to work on those.
However, the Strands and Beads idea is not about minification for Google
Closure or WebPack at all. Royale (and Flex) are designed for "Really Really
Big" applications where the source code is not compiled all at once. It might
be broken into what Flex and Royale still call Modules, or in some cases,
SubApplications. In these cases, it is should not be a requirement to be able
to statically know what APIs in one compilation will be used by another
compilation. Some of these compilations will be done by different teams, or
written once and never compiled again (think of a government's form filling
app). That's why in Royale today, we automatically export all public APIs to
prevent them from being removed as dead-code by the Google Closure minifier.
We just don't know if that API is going to be used by a Module later.
Royale and Flex also allow syntax that prevents (or at least complicates)
static analysis and dead code removal. You can write code that does:
Var obj:*;
Obj["w" + "idth"] = 0;
That's a contrived example, but I've seen more practical ones that would take
longer to describe.
So, Strands and Beads are intended to implement PAYG to allow the developer to:
1) get better granularity over what APIs are in the final output
2) reduce choices in the IDE code assist
3) re-use as much code as possible to optimize download size and runtime
performance.
HTH,
-Alex
On 10/8/19, 8:45 AM, "Josh Tynjala" <joshtynj...@bowlerhat.dev> wrote:
It is worth mentioning that Royale uses Google's Closure compiler when
creating release builds. Closure compiler does very advanced JavaScript
code analysis that eliminates unused code from the final output, so it has
a very similar effect to tree shaking.
The ability to integrate into a webpack build pipeline would be really
nice, though, since webpack is such a popular tool in the JS ecosystem.
--
Josh Tynjala
Bowler Hat LLC
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Cc7d79fa2927d4e731b8b08d74c068e25%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637061463354123380&sdata=IuAQOyehYEVTvGQqyWN2Q0rexmkFjlER5e08%2BI0k0us%3D&reserved=0>
On Tue, Oct 8, 2019 at 1:00 AM Chris Velevitch <chris.velevi...@gmail.com>
wrote:
> If the whole point of PAYG is to eliminate unused code from being
> included in the final app distribution, then I'd like to suggest that
> we take advantage of the tools the JavaScript ecosystem already has
> for eliminating unused code.
>
> I think we should take a look at Webpack [1] and create a compilation
> pipeline that feeds into Webpack to create the final compacted
> distributable app.
>
>
>
> [1]
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwebpack.js.org%2Fguides%2Ftree-shaking%2F&data=02%7C01%7Caharui%40adobe.com%7Cc7d79fa2927d4e731b8b08d74c068e25%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637061463354123380&sdata=4BJ5JjTodiGxukbMgSO%2FAhhapC0q5FqONCaCe3KQcks%3D&reserved=0
>
