Modular HTML5 Support

Announcements
#1

OpenFL 4.4 and Lime 3.4 have been released, introducing initial support for modular HTML5 builds.

This is a companion discussion topic for the original entry at http://www.openfl.org/blog/2016/11/01/modular-html5-support/
2 Likes
#2

Hi Joshua,

Well, I’m your huckleberry! I just came along looking for this. On wootmath.com, we’ve created a workflow where modular libraries and widgets (written in Haxe and targeting vanilla JS/CSS/HTML) are built and deployed, then we use RequireJS (AMD modules) to load reusable bits as they’re needed. It’s good for both caching and shared components.

Going forward, I’d like some more highly interactive widgets to be powered by OpenFL (while others remain simple vanilla JS widgets.)

With respect to the OpenFL modular flow:

  • Can a modular OpenFL app be not the full screen? (Maybe it “just works” to make the container canvas smaller? I haven’t tried.)
  • Does it work such that you can instantiate multiple OpenFL instances on a single page? Or is it instead more of a caching optimization?
  • Is there an example somewhere of build settings and how to build and instantiate a modular app?

Exciting stuff, thanks!

#3

Hey Jeff :slight_smile:

I’m currently able to output multiple JavaScript files from one compilation, without use of a custom JS generator. I thought that it might help make the code more resilient for the future. It works correctly if I use only one external *.js file, but when using multiple ones I ran into a bug that kept it from working in some instances:

Still, I am able to generate an external “lime.js” or “openfl.js” file, bundling as much of the Haxe standard library as I was able, plus all the code for Lime and OpenFL. For one project, it increases the file size (since there is no dead-code elimination) but for multiple OpenFL projects, this could save a lot of file size.

OpenFL is designed to work within the size of the DIV element you give it, so the CSS of that element determines the size, it happens that our default HTML template scales 100% to fill the screen, but this not required.

You should be able to use multiple embeds of OpenFL on one page, to my knowledge, though I’m not actually sure whether that conflicts with the “modular” feature.

The way to enable the feature is to add -Dmodular while building (or <haxedef name="modular" />)

#4

I tried making a modular export of the SimpleOpenGLView sample project, both debug and release.

I added the haxedef modular to the project file, but it didn’t change the build in anyway at all - am I missing something else?

the project.xml now looks like this:

<meta title="Simple OpenGLView" package="org.openfl.samples.simpleopenglview" version="1.0.0" company="OpenFL" />
<app main="Main" path="Export" file="SimpleOpenGLView" />

<source path="Source" />

<haxelib name="openfl" />

<haxedef name="modular" />

<assets path="Assets" rename="assets" />
#5

Oh, I just realized

The lime.embed function is going to get overwritten – only one will point to one loaded JS script

Is it possible to edit the JS files, so one is exposed as “lime2.embed” or something like that, and then to see if they both work on the page?

#6

How can I build a openfl/haxeflixel project as multiple javascript files?

Below command is enough to enable lime to build a project into multiple javascript files?
lime build “Project.xml” -release - final

#7

Try adding <haxelib name="modular" /> to your project, then Bundle.load in your project where you want to have a split

#8

This is not clear, is there an example we can see?

#9

I have not split projects this way myself, but my understanding is that including the modular haxelib is enough. At first, it will not split anything because there are no load calls, but if you wrap code within a load call it detects this and can split that into another file. I’m not sure fully but there’s a fair amount of documentation here: