Haxe (From: Java > Scala -> new thread: GUI for D)

[Nick Sabalausky]

"Adam Ruppe" <destructionator at gmail.com> wrote in message 
news:jbj23n$p68$1 at digitalmars.com...
> Nick Sabalausky Wrote:
>> The only problem now is that that would rule out the possibility of
>> sharing code between both server and client - Which is *NOT* something I 
>> want to give up...
>
> What kind of code is it?

Flash. A demo of it is here: www.attentionworkout.com  (Pardon the 
voiceovers, that's a requirement that's outside of my control.)

Basically, there's a series of "activities" that are (by necessity) Flash 
SWFs (but written in Haxe). These activities collect as much performance 
information as possible (including various timings, and in the case of the 
Radio, a log with enough info to "play back" the performance and 
re-interpret it however desired.) The whole thing was designed to be used in 
clinical trials on the elderly (which it's currently going through), so data 
collection/analysis, correctness/reliability, and compatibility were 
important concerns. (And naturally, flashiness and polish were lower 
priorities, which is why it...umm...doesn't exactly compete with PopCap in 
those regards.)

For the most part, the shared PHP-server/Flash-client code is things like:

- Data structures for all the results data.

- Various utility functions (Such as a lerp function. And a string->int 
function that actually works consistently on server/client and doesn't have 
the other weirdness of Haxe's built-in string->int. And other such util 
funcs that's aren't in Haxe's std lib).

- Identifiers for and URL-building for various URLs involved in the program. 
Even the flash apps need to refer to specific URLs now and then.

- Much of the code in the custom error-notification system (which 
automatically logs and emails us about things like unhandled exceptions in 
both the server and client-side code). This includes the Exception classes. 
The client version will notify the server instead of recording to 
log/DB/email directly, but other than that it's mostly the same code on both 
sides.

- The code which takes a log of exactly what happened (and when) during the 
Radio activity, and gives it an accuracy ranking between 0% - 100%. This, of 
course, needs to be consistent in both PHP and Flash. We could just simply 
record the 0% - 100% result the flash app shows to the user, but then we'd 
lose the ability to re-analyze the old performace data if we decide we want 
to change the algorithm (well, we *could*, but we'd be forced to do it in 
flash).

Basically the shared code, aside from reducing duplication (which has 
well-known problems), helps to keep simple things simple, helps with 
consistentcy, and helps us keep our options open (hell, at some point I 
could probably even make it work on an iOS browser without rewriting all the 
client code).

> The main reason for the javascript
> api thing in my web.d is to help minimize the pain of duplication,
> by keeping it all on the server, but still having easy client side
> interface.
>
> Then basically your js is just event glue to various server side
> functions.
>
>
> Of course, it keeps the JS down to size... but doesn't actually let you
> run code on the client written in D.

Yea, actually, I don't use Haxe for JS at all. Like you, I prefer keep my JS 
usage minimal and hand-tuned, and don't want to pull in a ton of JS libs 
just to do simple DHTML tricks. (Of course, once JS/HTML5 advance to a point 
where they can be used as an alternative to Flash, then I'd be more likely 
to use Haxe->JS for those purposes.)