So I was asked to detail the reasons why I dropped Haxe in favor of Swift
for my Quaxe project. Without disclosing precisely the words of the old friend I discussed with,
here are the questions I eventually had to ask myself as a result of his
own questions:

Does Haxe provide me, technically speaking, with everything I need to
build Quaxe?

Haxe is multi-target; is it a good or a bad thing for Quaxe?

Haxe is ten years old and mostly used for games and web sites; is it a
good or a bad thing for Quaxe?

Do I trust the Haxe Foundation to lead Haxe to its full potential?

Is the Haxe community the best fit for Quaxe?

Will people write native apps in html + CSS + Haxe if they're not
already in the Haxe community?

And then I took all the time I needed to forge answers. Here they are:

Yes, clearly. I welcomed every OS X update with some fear because it usually broke quite a bit of things on the Haxe front, but the language itself
is perfectly fine for my needs and goals.

More a bad thing than a good one. I could not care less about
Javascript, PHP or ActionScript targets. The fact that Haxe is
multi-target has side-effects on the language and its feature set and
some of these side-effects are bad for my project.

Quite a bad one actually. Almost nobody knows Haxe outside of the
gaming community even after more than ten years of existence. Most
people around me now know about it because *I* told them about it and they're
not using it. Converting desktop and mobile apps people to Haxe remains
an open question, even if Quaxe reaches 1.0 based on Haxe.

No, I don't... Sorry if it's rough and harsh but almost nothing has
changed on that front since WWX2015. Haxe is still totally
invisible and issuing a Press Release still
seems impossible, even if it's only on haxe.org.

Simn's edgy response to my talk during WWX2015 - his rather shameful «
you don't bring solutions » said with a super-aggressive tone still
badly resonates in my ears - is not the kind of behaviour I can easily
cope with. Identifying and acknowledging issues is always needed
beforehand to fix them, that's true everywhere including for Haxe. FWIW,
he's not the only HF rep who was still mentioning, I quote, "shock" and "trauma"
(yes, trauma; I had to read it multiple times to believe it...) weeks
after my WWX2015 talk. Guys, if you don't want to face painful truths,
don't let the issues grow unmonitored in the first place. Blaming the
whistle-blowers is, again, a behaviour I cannot accept.

The Haxe Foundation is still opaque and weak. It took a lot of efforts to have the 2014 financial report, and the 2015 financial report is still invisible. WWX, the one and only
gathering of the world-wide Haxe community, is still organized this year
by SilexLabs and the Haxe Foundation is not even present on the event's
logo and Nicolas Cannasse is apparently not planning to attend. The technology he created, maintained by the « Foundation » he manages, has one unique gathering event per year and he won't be there. And it's not even far away from his place. Wow, just wow.

My requests for some convergence with ECMAScript, that could open up the
market for Haxe, remained a no-go. Even a missing (and rather crucial to
me) Regexp flag was a fight I could not win.

Flash is dying, close to coma, and Haxe has to make a choice between
keeping restrictions because of Flash and moving on. I'm of course all
in favor of the latter, while the former still wins. Flash must die.

Investors have never heard of Haxe and I am unable to make them believe
even a bit in a technology that remains so invisible.

Finally, to be fully transparent about it, Nicolas Cannasse pinged me
mid-october 2015 to ask me to be the PR person for the Haxe Foundation.
I had to refuse for both legal and practical reasons: working for free
would be illegal (my company was precisely under routine IRS control at
that time) and working for a "small fee" as it was proposed would have
sucked too much time and then income from my paid consulting time;
"small fees" totally unrelated to my regular hourly rates would also
have triggered tough questions from the IRS...Secondly, I had a chat at the beginning of the year with a candidate Nicolas was interviewing for the HF CEO's
position. I'm not 100% sure but I think it's Nicolas himself who told
him to ping me, which is nice and fair if that's correct (I'm serious).
I have no idea how his interview went after our chat but the fact nothing's done yet so many months later (Nicolas announced he was looking for a CEO end of november 2015), added to the fact Nicolas seems to be much more involved in his games than in Haxe these days, is not a good signal at all. FWIW, I'm not the
only one the candidate had chats with.

Yes and no. Cool and friendly people all over the place, some real
gurus with extremely deep technical knowledge you can always annoy with
n00b questions. Some people highly sympathetic with my goals but also
some strong disagreements More importantly, it remains a rather small
community, even after ten years, and that still scares me too much.

That one took me weeks to answer... I came to Haxe with a strange
feeling of happiness, glad I found it. I was really excited about
Haxe. But the more I was coding with it, the more I was asking myself
what would be the killer argument to make people switch to Haxe for
native apps' implementation. And the more I was asking myself that
question, the more the market outside of Haxe was evolving at fast pace,
the less I could find self-assurance in my own answers... I eventually
had to face the disturbing truth: I can't answer that question and such
a doubt should be a major showstopper for a project like mine.

I have already stopped entirely using Haxe and it's gone from my work machines. I will soon unsubscribe from the Haxe ML. Some will smile and think «
good riddance », and that's fine by me; in the meantime, most issues I
highlighted a year ago - even the critical ones - still stand. I'll miss other people, friendly, geeky,
cool and having a superb expertise. But the thing I will probably regret the most is the missed opportunity and my time/energy investment. Betting on Haxe that already faced the same issues two years ago was a strategic mistake.

My disturbing conclusions:

the Haxe Foundation is totally dysfunctional and must stop leading Haxe; Nicolas Cannasse is not leading Haxe to its full potential.

the quest for a CEO seems to be anything between unsuccessful and an epic failure

the best candidate to lead Haxe is then Silex Labs

drop the Flash target entirely, it plagues the potential of the project

This was not an easy decision to make but I have now decided to stop
using Haxe for my Quaxe project. A month
ago, I was discussing Quaxe with someone who easily qualifies as one of my
mentors and, after a 45-minutes-long storm of questions, that person gave
me excellent arguments to make me switch to Apple's Swift. I am then
announcing I am working on the following Open Source components for Swift:

As of today, the DOM implementation is 75% done, the XML parser is 95%
done, the CSS parser is on its way, the build system improves every day.
None of the codes listed above will depend on external libraries if you
except some trivial usage of Foundation for NSStrings, that will
eventually go away.

Reaching 1.0 for one platform (most probably OS X) will be easier and
faster; but the side-effect is more work per platform.

first, I have greatly improved the original Haxe xml parser adding support for XML namespaces; that required modifying completely the way elements and attributes are created since the resolution of a prefix can require the attributes to be already parsed...

It should be an extension of the "local" Array class, i.e. the Haxe basic Array class. I found two ways of implementing this. The first one is achieved using an abstract class and forwarding all unknown methods to the underlying Array:

Elements is here defined as an abstract class for an Array<Element>. The @:forward() rule says all methods not defined in the abstract class are forwarded to the Array. The last line adds an array accessor to the class (only the getter, not the setter) to allow foo[index] notations.

After discussion on IRC in #haxe, there is another way, simpler, but it comes at a cost. It is possible to use a Haxe static extension:

The cool part is of course step 5. The rest is environment's setup only. Look at the source, recognize very common wxWidgets stuff there, and compare to other ways of embedding WebKit... Click on the thumbnail below to see a screenshot of the resulting OSX app.