Hello
I’m building with Haxe + OpenFL/Lime using:
haxelib run lime build html5 -Dno-deprecation-warnings -Dwebgl -Dsource-map-content -release
The entire OpenFL framework gets bundled with my app code, making the release file huge. I know there’s an openFL NPM library, but I’m not sure how to use it to avoid this duplication.
Thanks in advance.
Many parts of OpenFL depend on other parts of OpenFL, even if you aren’t necessarily using those other parts all of the time. The Flash API wasn’t really designed to be modular (and the whole point of OpenFL is to provide an implementation of the Flash API, so this isn’t something we can change). There might be some re-architecting we could do internally to help ensure that certain classes are excluded when they aren’t used (or even provide defines to exclude things manually). However, I suspect that a big part of OpenFL will always be included with your app due to the nature of the Flash API.
One place where you can possibly exclude parts of OpenFL in your app today is by avoiding using the assets system. The Assets class, in particular, pulls in a lot of dependencies for the various types of different assets. If you avoid using any <assets/> tags in your project.xml, and you load your assets manually with URLLoader or Loader, that can save a bit on file size. Not a ton, but when every little bit counts, it’s better than nothing.
That being said, you can probably get a bigger drop in file size by using -final, which I’ll go into in the next section…
Using -final instead of -release can make a huge difference for html5 builds in particular. It enables -dce full, which analyzes which classes/properties/methods you use at compile-time and removes the ones that are unused. However, when you use this feature, you may need to change some of your code to avoid using reflection, or use it selectively for things that you know will be strongly referenced elsewhere (or things that are using @:keep). In my own projects, using -final makes a pretty dramatic difference in file size, actually.
Often a source of reflection is programmatic animation. Personally, I made sure that Feathers UI works with -dce full mainly by switching from Actuate.tween() to Actuate.update(). Instead of passing in an object with the target properties like {x: 100, alpha: 0} or whatever, you pass in a function to Actuate.update() that strongly references the properties that are being animated.
Actuate.update((x:Float, alpha:Float) -> {
// strong references to x and alpha below so that dce doesn't remove them:
target.x = x;
target.alpha = alpha;
}, duration, [target.x, target.alpha], [100.0, 0.0], true);
Finally, one thing to also keep in mind is that most web servers use gzip compression. The number of bytes actually passed over the network will often be much smaller than the size of the .js file on your file system.
The OpenFL npm library definitely includes all of OpenFL, so I’m not sure that switching to it would help you much, unless you are talking about sharing a single OpenFL .js URL among multiple OpenFL apps on the same domain (for security purposes, web browsers will redownload and duplicate in their cache the same .js file referenced by multiple domains).
There are samples that show you how to configure OpenFL npm with TypeScript, JavaScript (ES5 and ES6), AS3 (Royale), and Haxe. I don’t think a lot of people are using the OpenFL npm library, so it may not be as stable as sticking with pure Haxe.
Yes, I found my code “suffers” a lot when using -final or -release, so I have to avoid them. The closure compiler, however, does the job for me using the default settings.
Hello @joshtynjala , I really appreciate your details answer, its only one openFL app, within the domain, I was thinking to use the OpenFL npm library as most of the times openFL version is not changed when deploying new release or fixes for my app, that way I keep openFL code completely cached, while I deploy my updated app changes only.
(post deleted by author)