I thought pictures would speak louder than words here.
Check out my haXe code. Look familiar? It should if you use Robotlegs to make your code all pretty.

Now get a gander at mah DOM:

Yeah, my HTML is a little outdated, that’s why “HTML5″ is in quote marks above. But there’s nothing to stop you from using whatever newfangled tags you like. Declarative views FTW!
And lastly, what the generated JS looks like in Chrome Developer Tools:

The generated JS is not all as perfectly readable as the above, but it’s quite good enough. Peep the breakpoint you can set to debug your code.
OK, now I know you wanna check out the demo: 101 Icebreakers
I know, it’s corny and cheesy but hey it’s hard to come up with ideas for a weekend project
You might have to hit “GET RANDOM ICEBREAKER” a few times before getting another one as there are only 3 in each icebreaker type dataset.
View the source here: At Github (Apology: Wrote and learned this all in a weekend so don’t expect all RL best practices to be followed or for the code to look that great. It’s just a demo meant to show the capabilities here)
PROS
Wow, too many to count really. A few to highlight: I am able to write clientside JS code and not have it be a nightmare. I can confidently write my code using RL’s clean architecture and know that it will work as designed. And, best yet, I can use any JS library out there, provided an extern has been written for it. jQuery comes with haXe JS, and there are externs already written for ExtJS, even node. I can use as much or as little JS as I want. There’s some really exciting stuff out there and I’m drooling, for example, at the thought of an Angular extern bringing in databinding capabilities (not sure if its possible) Really, it’s fun peoples.
CONS
Currently with cube automatic creation of mediators is not supported. So in addition to your mapping code, you have to do this for example:
agent.mediatorMap.createMediator( menuView );
whenever you create a view. This can be tricky as you will need a reference to “agent” in order to do this.
“Declarative Views”, as I call them above, is a bit misleading. At least the way I chose to take care of views for this example, it’s more like when you create Symbols in the flash IDE and write classes to control their behavior- inside the class, you have to tell it what DOM elements belong to it and what to use. There’s no protection here — you could access a div that doesn’t belong to the View you are writing — so you do have to be your own nanny a bit.
I preferred to write the views the way I did, inside the HTML, because I can clearly see what I’m creating; it feels like MXML to me. You could instead, as in the Cube Demo above, create your views directly from within view classes in haXe JS.
But I can definitely envision writing some sort of wrapper that cycles through your HTML and creates classes based on the elements it finds inside… perhaps it would be too slow… but someone will just have to write it and see!
main.js is pretty large. 215KB… though I haven’t run it through a minifier or even googled anything about how to make it smaller.
This isn’t really a con, but just as in writing real JS, use the jQuery library provided for you in haXe, otherwise you will be asking for a world of IE pain.
CONCLUSION
OK, I haven’t felt this excited in a while. I don’t claim to be an expert on language or compiler design, framework implementations, browser quirks, etc etc but I really can’t see a reason why I would NOT write my client-side code this way now and in the future. If you can, let me know in the comments… Otherwise, haXe JS – it’s you and me baby.
Lastly, this was a really rushed piece. I have a lot of work to do for my day job right now but was too excited not to get this out there. If you find any inconsistencies or inaccuracies don’t hesitate to smack me upside the head in the comments and I’ll update this post tout de suite.
—————————————-
Alright here’s the dilly, for those who want to try it out:
I used Flash Develop as my haXe IDE, it’s definitely the best way to go. Really worth booting up Virtualbox or Parallels for those of you with Macs.
I got great code-completion. You can jump to declaration (place your cursor and press F4) and there are a lot of other awesome shortcuts FD has that I don’t know about. But basically, haXe has static typing so your IDE experience is pretty close to perfect. The only thing is AFAIK no one has built refactoring support for FD yet.
You will need to install haXe and install xirsys_cube to get the demo source to build. After haXe is installed, you just go:
haxelib install xirsys_cube
from a command prompt.
There may be other libraries you need to install and I’ve forgotten, if so haXe will prompt you when you try to run the code.
After you get the example project into FD, right-click on src/build.hxml and select Execute. This will build your main.js file, which is in bin/ . That’s where index.html is also in, so you can view your work.
I used Cube, one of two Robotlegs ports that exist for haXe. Here is the demo that I used to get me going. The other port is RobotHaXe, but Cube had better examples for my use case so I went with that.