A few times in the past I considered using OpenFL for interactive applications which would run in the web browser, and final file size was an issue. One time I ended up using Haxe+SVG+GSAP instead because I wanted a leaner download.
This leads me to my question: would it make sense to create an OpenFL tool similar to what other libraries do (e.g. GSAP) where you can pick the exact features you intend to use, then it generates CDN links for you? (for cached libraries and distributed delivery)
I suppose you’d need to put something into the compiler so that your custom code was separate from the other generated classes. Maybe you’ve already done something like that for OpenFL 7?
There is a feature called -Dmodular in Lime/OpenFL for HTML5, that generates distinct “haxe.js”, “lime.js” or “openfl.js” files, separating it from your code. However, this code is generated dynamically, based upon the contents of your specific libraries (and the defines you use) so it is not suitable for a global standard CDN, as your “openfl.js” may be different than mine.
This is changed in our NPM releases, which include a standard “openfl.min.js” which is standard based upon that release version, it is also possible to import distinct OpenFL modules (though I think we could do more to make sure that modules rely on each other as little as possible). Currently, the gzipped version of our “everything” JS file is 230 KB, is this too large?
I have plans to put our “openfl.min.js” on a CDN with each release
EDIT: I have submitted a pull for CDNJS, and just realized JSDelivr works automatically
I was wondering if we could split out different parts of the API and CDN those as well. The haxe/gsap/svg thing I did weighs in at 87.4 KB and it has some nice animation and interactivity. Back in the day we used to use Flash to add a bit of pizazz to a site. OpenFL has all the same features that Flash had, but because we are now downloading all the functionality that used to be part of the plugin, it’s less an option as a Flash replacement in the browser, at least for the basic stuff.
Good question. Following the GSAP model I suppose we could offer 1 or 2 base packages, then determine add-ons which would provide a nice group of desired functions.
Just off the top of my head, with ideal file size for discussion:
OpenFL-Light (~60KB):
Most display/loader classes but no JPEG/PNG encoding, tiles, or shaders
basic geom classes
full Assets utils
OpenFL-Standard (~100KB):
all display classes, Assets
all 3D classes, filters, geom
Separate plugins for:
media package (sound/video)
net package classes: basic (URLLoader, URLRequest) and advanced (Socket, SharedObject, NetStream, etc.)
printing package
sensors package
text package
ui package, basic (Mouse/Keyboard) and advanced (GameInput, Multitouch, etc.)
other openfl libraries such as Actuate
Appropriate errors and events would have to be bundled in the packages.
I’d love to hear other folks’ opinions on this.
Thanks, I appreciate the feedback. I think we can continue to look at 1.) how we make OpenFL modular (but may have to ask some questions, of how we (in a CommonJS way) would allow separation of openfl.display.Stage from openfl.display.Stage3D, for example.
We might also be able to 2.) try and isolate the weight/cost of different features, and see if any of them stand out as items that cost more than they should. We do have a lot of features in OpenFL, and there is the cost of the Lime layer, but I think we could continue to improve in this area.
OpenFL 9 is not currently compatible with NPM, but the biggest change is the addition of the Timeline class and the removal of the SWF tools. We will need to figure out the SWF-based workflow for NPM users before we can bring both releases up to the same version again.
