COMMUNITY

Flash/Air targets deprecated?

haxe-swf
haxe-as3

(Seb) #1

Today I saw that Simon is back in action, which I am very happy about!

However I found it quite surprising, that he apparently closed all Flash related Github issues with the argument “Moving towards Haxe 4, we will no longer look into fixing old Flash/SWF issues.”.

I cannot remember seeing any official statements or announcements by the HaxeFoundation to retire the Flash target, so I am really puzzled that such a fundamental decision bubbles up through comments in closed Github issues. While my last post Where is Haxe heading? received quite some attention in the community, apparently little to nothing has really changed since then regarding official communication by HF. The Haxe roadmap https://haxe.org/community/roadmap.html is still completely out of date. We are still left wondering what happend/is happening to the CS/Java targets for which development seems to be completely stalled.

ATM I find it a bummer that we are about to loose first class support of the Flash target because FlashDevelop+FlashDebugger is/was for me the easiest way to get realtime debbuging working without much hassle. I also believe Haxe+Air is still a thing, or not?


(Simon Krajewski) #2

Ok, here’s the announcement:

Moving towards Haxe 4, we will no longer look into fixing old Flash/SWF issues. We are still going to keep the generator up to date with all new Haxe features, but we don’t have the resources to work on flash-specific bugs. Pull requests to fix them are still going to be reviewed and possibly accepted.

You left out the important details and made it sound like we were giving up the Flash target altogether. I honestly have no idea how you would arrive at that conclusion after reading this message.


(Seb) #3

Even your full message indicates that HF is only supporting the Flash target by “possibly” accepting external PRs but no HF resources are spend anymore on implementing new Haxe features or fixing outstanding issues. That fact should be officially communicated!


(Simon Krajewski) #4

I specifically mention that we’ll keep it up to date with new Haxe features.


(Seb) #5

Ok, so you are actually saying “We continue adding new features for Flash but won’t fix any bugs.” But also adding new features will eventually result in new bugs. This seems to be ill-conceived.

From my view HF should be consequent, either retire the target with proper official announcement and an adequate advance or keep the target fully maintained.


(Simon Krajewski) #6

We won’t retire it, but we also don’t have the resources to keep it fully maintained (in the sense that we can’t look into some of the 5-10 year old bugs). I don’t really understand what you want from us here.


(Valentin Lemière) #7

We’re not saying those issue will never be fixed, just not with the quite small development team we have right now, maybe if we had more developers we might.


(Seb) #8

What I wanted was that HF rethinks there decision or at least in the future improve the way of communication. If HF is short on resources than just be consequent and drop the Flash target completely in Haxe 4, cleanup the code base and focus the energy on other targets (esp. the once that currently need some love) instead of supporting Flash half-heartedly by using up the limited man power to implement new languge features for Flash but leaving the Haxe users on their own when facing bugs in the Haxe compiler which are impossible to fix by non-OCaml developers.


(Ben Morris) #9

There are a lot of calls for HF to improve communication…did you know they recently hired a new Director of Marketing? I’m sure that’s on his todo list :slight_smile:

I disagree with you: “spend resources to maintain” or “drop completely” is a false dichotomy. I think the middle ground of preserving support and considering PRs is preferable to either.


(Phil Chertok) #10

@seb and @bendmorris - Indeed improving communication is at the top of my todo list.

Certainly this news (and other news) could be and will be handled better in the future. I’m still trying to familiarize myself with the community and the most pressing issues. You’ll be hearing a lot more from me in the coming weeks as I start my duties wholeheartedly.

My session at Haxe Summit will touch on communication along with other outreach plans in order to improve engagement with the community.

Yes it’s true that the foundation has limited resources, but when it comes to speaking with our most valuable members, there should not be a limitation going forward.


(Nanjizal) #11

@seb was there a specific bug that he closed that was causing you a specific problem?

Generally I have found that flash target was always very stable and that these edge cases are pretty rare and quite unusual, just given the limited user base it’s hard for them to be priority. The same was said of PHP until a developer stepped forward to update Haxe to PHP7.

It would be foolish to drop the flash target given it works so well, in my opinion the cases closed are normally fairly obscure and not common problems.

Given Adobe’s reluctance to put flash as a priority it’s understandable that Haxe is not putting much effort into the target really you should ask Adobe to sponsor support into the occasional obscure features and prove that it’s serious about AIR going forward, but reality is that it’s not :(. It has killed flash more than apple in it’s neglect and lack of promotion of the platform, I suspect that products like photoshop, illustrator mean that it will support AIR long enough to keep it’s corporate clients happy but has no real interested in AIR? The cost for Adobe to sponsor Haxe in relation to flash would be very little in relation to their budgets and would be huge positive PR and reassurance for AIR as a product so you should probably raise it with them, it is to be honest a minimum they could do to give AIR users any reassurance. They don’t really close bugs they just neglect them?

I think that if you have a bug with haxe flash target that is a real show stopper to your projects you should probably bring it up, but if its something you can work round… and slowly look at solutions that are not flash based then that is likely sensible longer term.