To menu | To search

Quaxe reborn #2

, 17:58

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:

  1. Does Haxe provide me, technically speaking, with everything I need to build Quaxe?
  2. Haxe is multi-target; is it a good or a bad thing for Quaxe?
  3. Haxe is ten years old and mostly used for games and web sites; is it a good or a bad thing for Quaxe?
  4. Do I trust the Haxe Foundation to lead Haxe to its full potential?
  5. Is the Haxe community the best fit for Quaxe?
  6. 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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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
  • converge with a well-chosen subset of ECMAScript

Bye Haxe, I hardly knew ye.

Quaxe reborn

, 13:42

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:

  1. a DOM implementation
  2. a XML parser
  3. a HTML DOM implementation
  4. a html parser
  5. a CSS Object Model implementation with my "better" CSS Values OM
  6. a CSS parser based on my JSCSSP parser
  7. a CSS engine
  8. a component model better tailored to Swift than Web Components (that I find ugly anyway)
  9. a framework turning html + CSS + Swift into native apps for OS X, iOS, Gtk+3 and I really hope the Swift port for Windows will appear sooner than later :-) No knowledge of XCode needed. No browser engine inside. Lightweight. Fast. Dynamic. Extensible.

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.

Wish me luck, it's a lot of code/work.

E-Toiles d'Or 2015

, 09:43

I am glad to report that Quaxe won a « E-Toiles d'Or 2015 » award in the Startup category yesterday in Paris :-)

Second Quaxe screenshot

, 14:15

Things are getting better and I now have menus working fine...

Quaxe screenshot with OSX menus

20141114 Progress

, 11:02

  • querySelector() now fully implemented, based on Selectors Level 3 and some bits of Level 4 like case insensitivity matching in attribute selectors
  • fixed a bug in NodeIterators
  • Element.getElementsBy*() methods now implemented

XML Namespaces

, 19:00

I have added a lot of things to my DOM4 implementation:

  • 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...
  • then I added a xml serializer with pretty printing
  • I also added a content sink that will be useful to embedders.
  • I also revamped the associated test that is much cleaner and more readable now I have extracted the mini-serializer

Implementing DOM4 Elements class in Haxe

, 09:29

The Elements class from DOM4 is defined as follows:

class Elements extends Array {
  Element? query(DOMString relativeSelectors);
  Elements queryAll(DOMString relativeSelectors);

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:

abstract Elements(Array<Element>) {

  public inline function new() {
    this = [];

  public function query(relativeSelectors: DOMString): Element
  { ... }

  public function queryAll(relativeSelectors: DOMString): Elements
  { ... }

  @:arrayAccess public inline function __get(key:UInt) return this[key];

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:

class Elements {
  static public function query(t: Array<Element>,relativeSelectors: DOMString): Element
  { ... }
  static public function queryAll(t: Array<Element>,relativeSelectors: DOMString): Elements
  { ... }

and use it through a

using path.to.Elements;

but then you can't use var foo:Elements = [];, you have to write var foo:Array<Element> = [];
. I am then keeping the solution of the abstract class, that fits better.


, 10:01

I have started implementing DOM4 for my project. The work-in-progress can be monitored on github.

Standalone app embedding IE in minutes

, 17:28

I have successfully adapted my build of waxe to support Windows and have included prebuilt binaries of waxe. So here are the steps for windows (no need to build waxe any more):

  1. install Haxe: download it from here
  2. install nme and hxcpp: in a terminal, type
    • haxelib install hxcpp
    • haxelib install nme
  3. install my own build of waxe; in a terminal type
    • cd <a_safe_place>
    • git clone https://github.com/therealglazou/waxe
    • cd waxe
    • git checkout WebView
    • haxelib dev waxe <a_safe_place>/waxe
  4. build my example (and don't forget to look at the trivial source):
    • cd <a_safe_place>/waxe/samples/04-Simple
    • haxelib run nme test Simple.nmml windows

To build on OS X, just follow the steps above and change the "windows" keyword on the last line to "mac".

Recently added

, 12:57

  • waxe-works
    • waxe-works was not building src/osx/webview_webkit.mm on OS X...
  • waxe
    • add support for wxApp::s_macAboutMenuItemId (OS X)
    • add support for wxApp::s_macPreferencesMenuItemId (OS X)
    • add support for wxApp::s_macExitMenuItemId (OS X)
    • add skeleton for WebView wrapper for wxWebView
    • WebView.loadURL() and sample code
    • WebView.isBusy()
    • WebView.isEditable()
    • WebView.print()
    • WebView.reload()
    • WebView.setEditable()
    • MiniFrame wrapper for wxMiniFrame
    • WebView.runScript()
  • my additions to waxe now work well with windows and linux too

WebKit embedded in a standalone OS X app you could write in ten minutes

, 11:00

  1. install Haxe: download it from here
  2. install nme and hxcpp: in a terminal, type
    • haxelib install hxcpp
    • haxelib install nme
  3. install my own build of waxe-works (that's only needed to build my own fork of waxe, the haxe lib for wxWidgets); in a terminal type:
    • cd <a_safe_place>
    • git clone https://github.com/therealglazou/waxe-works.git
    • cd waxe-works
    • git checkout addWebViewWebKit
    • cd build
    • neko build.n
    • haxelib dev waxe-works <a_safe_place>/waxe-works
  4. install my own build of waxe; in a terminal type
    • cd <a_safe_place>
    • git clone https://github.com/therealglazou/waxe
    • cd waxe
    • git checkout WebView
    • cd project
    • neko build.n ndll-mac-m32
    • haxelib dev waxe <a_safe_place>/waxe
    • haxelib remove waxe-works
  5. build my example (and don't forget to look at the trivial source):
    • cd <a_safe_place>/waxe/samples/04-Simple
    • haxelib run nme test Simple.nmml mac

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.

Screenshot of demo

New blog

, 09:49

I have decided to start a new blog to host my Haxe/Waxe/Quaxe ramblings. This is http://quaxe.org.