OpenFL is mature for HTML5 project. I’ve made few projects this year. However there are few bugs in textfields (especially in IE11) but it exists few workarounds. I personally use this PR to have better textfields.
So what’s your experience about it exactly? What’s your problem? Can we help?
@loudo, thank you for taking your time to participate and for your willing to help.
It’s something really impressive in openfl community: people are always willing to help.
Regarding the HTML5, it were many problems I faced. From no sound playing to game not loading at all in HTML5.
What bothered me more is that the projects worked fine on Flash, Android and Windows.
Many problems were solved (in one way or the other) but for me it’s clear HTML5 is far behind the other targets.
It’s very annoying to expend time trying to fix problems when all you want is the game running as in other platforms.
In the end, I preferred to use another framework to develop for HTML.
But I still have high expectations that HTML5 target will be in a point that I’ll be able to select this platform and be sure it will work flawless (as it happens with Flash).
That’s why I wrote this post. I’d like to hear @singmajesty about the plans for HTML5.
And I have to say: If it depended on me, Flash wouldn’t die the way it’s dying. It’s unfair it be killed because Mozilla, Google and other vendors want to force user adoption of HTML5. It should be an option of developers and users to use or not Flash.
In (legacy) versions of OpenFL, we had different backend code for HTML5 or for native platforms. It was common to see discrepancies between the two, bugs in one and not the other, or just different behavior.
Current releases of OpenFL are not only 100% Haxe code, we use the same OpenGL renderer code on all GL (WebGL, OpenGL desktop, GLES mobile) platforms. The only real distinction in the OpenFL layer is whether we use Cairo or canvas for a software render (but both are very very similar) or if you use the special -Ddom mode for HTML5, which is not commonly used.
In older releases, it was not surprising when Mac and Linux builds both worked, because they were so similar. Nowadays, I feel this way across desktop and HTML5 especially, for a majority of features. You can check the source code (if you like), we don’t have a special Android or desktop code path in OpenFL.
In the Lime layer, there is platform code in order to unify the platforms, but this is easy to diagnose (and generally to fix) if anything is not correct. At that level, we create a window, send events for input or window events, or have a few APIs (such as AudioSource) which wrap features such as network and sound.
The only real difference between HTML5 and native targets (at the moment) is that we cannot do multiple threads (which we simulate by running synchronously, then using the same API to callback)
Although this is a bit older, here is a good example of OpenFL HTML5: