NodeJS as "official" Haxe target?

[Cambiata]

Hi guys!

The NodeJS logo is used at the haxe.org front page, but there is no "official" Haxe-branded externs/lib for it - only the thirdparty libs by Dion, Clemos, Eduardo and others.
With the spread and momentum that NodeJS has, shouldn't there be

• official Haxe externs for NodeJS
• official sys.* iplementation built on those externs

?

What do you say?

Jonas

[Dan Korostelev]

I believe there's even an issue about that. We implemented an "official" way to automatically "require" extern classes in 3.2 with @:jsRequire. I think that can be used as a base for some kind of official nodejs externs. And of course we'd want to use haxe typing facilities to the maximum (for example use @:enum abstracts for EventEmitter event names).

среда, 6 августа 2014 г., 18:19:57 UTC+4 пользователь Cambiata написал:

[Cambiata]

Good news!
Looking forward to it!

J

[Sam MacPherson]

Agreed on this. FYI There is already a discussion for this on the Haxe repo: https://github.com/HaxeFoundation/haxe/issues/2784

I can see one of the big issues being the asynchronous nature of NodeJS. Most (all?) Haxe server targets are synchronous so it may be hard to adapt the sys.* package.

[Juraj Kirchheim]

@Dan: I think it'd be great do have some -D headless or -D nobrowser
or -D nodom or -D nohtml or whatever to get rid off the js.html.* and
js.Browser stuff. Also js.Lib.alert should ideally go into
js.Browser.alert for a cleaner dissection, but that's probably not
worth breaking code.

Best,
Juraj

> --
> To post to this group haxe...@googlegroups.com
> http://groups.google.com/group/haxelang?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Haxe" group.
> For more options, visit https://groups.google.com/d/optout.

[Nicolas Cannasse]

Le 06/08/2014 20:49, Juraj Kirchheim a écrit :
> @Dan: I think it'd be great do have some -D headless or -D nobrowser
> or -D nodom or -D nohtml or whatever to get rid off the js.html.* and
> js.Browser stuff. Also js.Lib.alert should ideally go into
> js.Browser.alert for a cleaner dissection, but that's probably not
> worth breaking code.

Apart from alert() - which could be implemented in some other way in
Node anyway - there's already such a clear separation with js.Browser
and js.html package. We might only want to actualy forbid using these
when compiling for node.

Best,
Nicolas

[Simon Krajewski]

The way our package_rules works currently doesn't really allow dealing
with non-toplevel packages if I'm reading it correctly. We would have to
hack that in some way.

Note that `@:require` is more powerful now, so something like
`@:require(!nodom)` would work on js.Browser.

Simon

[clemos]

I've found it useful to be able to access html definitions from node.js for packages like JSDOM, actually...

https://github.com/clemos/haxe-js-kit/blob/master/js/npm/Jsdom.hx

As for alert, I agree, here's the issue if you want to +1 ;) :

https://github.com/HaxeFoundation/haxe/issues/2793

Best,

Clément

[Juraj Kirchheim]

On Thu, Aug 7, 2014 at 9:51 AM, Nicolas Cannasse <ncan...@gmail.com> wrote:

> Le 06/08/2014 20:49, Juraj Kirchheim a écrit :
>
>> @Dan: I think it'd be great do have some -D headless or -D nobrowser
>> or -D nodom or -D nohtml or whatever to get rid off the js.html.* and
>> js.Browser stuff. Also js.Lib.alert should ideally go into
>> js.Browser.alert for a cleaner dissection, but that's probably not
>> worth breaking code.
>
>
> Apart from alert() - which could be implemented in some other way in Node
> anyway

I'm really not sure about that. An alert is a *blocking* GUI
interaction. Some output to the console just won't cut it, if you ask
me.

> - there's already such a clear separation with js.Browser and js.html
> package.

In general, yes. There is this one mishap however. I think it should
just be `@:deprecated @:require(!nodom)` and then we put the actual
implementation into js.Browser and we don't need to break anything.

> We might only want to actualy forbid using these when compiling for
> node.

My point exactly. To be more precise, we should simply make forbidding
these straight forward. You don't want to automatically forbid them
when compiling for node, because then you can't use node-webkit ;)

Best,
Juraj