Replacing an OpenFL Backend

When I was designing OpenFL, one of the goals was to build an architecture that would allow for easy development on one of the backends. Currently, we have two backends: “openfl-native” and “openfl-html5″

If you install OpenFL, you will probably notice that these are completely different Haxe libraries. This makes it possible to make changes to the native backend without rebuilding command-line tools, or to make HTML5 improvements without rebuilding native binaries.

The README for each project on GitHub includes instructions for using a development version. For example, to use a development version of openfl-html5:

git clone https://github.com/openfl/openfl-html5
haxelib dev openfl-html5 openfl-html5

This can also let you replace a backend entirely.

One of the things about HTML5 particularly is that a “one size fits all” approach may not be ideal. One person to the next, or one project to the next, may require different features and emphasize competing priorities.

For sake of argument, I created a simple example of an alternative backend for HTML5. This backend uses DIV elements for Sprites, when requested, the Graphics object is a canvas element, and the stage clipping is a simple “overflow: hidden”

git clone https://github.com/jgranick/openfl-simple-html5
haxelib dev openfl-html5 openfl-simple-html5

Here is an example of a project that works with the backend:

Some features might never work with this kind of backend (for example, bitmapData.draw may not work for DIV elements) but this may be a good match, for, say, web application development.

There is still a lot of room left to innovate. Let’s play!

  • Jeremy Sachs

    Yes, let’s!

    Are there plans for a listing of publicly available OpenFL backend options?

  • http://www.joshuagranick.com Joshua Granick

    What are you looking for?

    Currently, each backend is following a loose interface, where (technically) properties, methods and classes do not need to be implemented, but as you support the same API, it obviously makes it work seamlessly cross-platform. As a result, if you create a backend where you are using only a limited subset of the full API, you should be able to still have compatibility with the fuller backends that have complete support.

  • Jeremy Sachs

    I guess the haxelib listing provides enough visibility for most OpenFL backends that someone might want to share with other people.

  • Danny Marcowitz

    As someone who’s constantly moving from NME/OpenFL development to Haxe with CreateJS externs, I would be psyched to have CreateJS as a backend for OpenFL, and I think it’s current API is pretty damn close to flash.