NodeJS target, compiler params and examples needed.

[Saumya Ray]

I was trying to understand how JS target works. All I know is, HAXE compiles to one single JS file

Now trying to get to NodeJS target, i was expecting that each .hx file will be compiled to respective NodeJS modules. But Could not find any reference documents or command line params for that.

Is it that for NodeJS also I have to compile all the .hx files into one .js file or there is something I am missing here.

thanks

[Andreas Söderlund]

You're right, Haxe will compile to a single JS file so you don't have to care about requiring modules. But if you really want separate JS files you need to compile them separately with multiple hxml files or using --next (useful hxml reference here).

If you're interested in a larger Node.js example for Haxe, I've just created https://github.com/ciscoheat/meadowlark which will follow a tutorial from a Node.js book, but using Haxe as language and Haxe libraries instead of Node packages when possible.

/Andreas

[Saumya Ray]

Thanks Andreas.

Will update you as I do a little experiment on it.

However, is it necessary to have a "main" function in each .hx file to compile to individual .js file ?

When I tried to compile to JS for each file, it throws error saying "main" is not defined. What am i missing here.

[Cambiata]

@Andreas:
Cool! Compiles and runs just fine.
I like the "native Haxe" approach.

@Saumya:

It is possible to compile without a static main method.
Let's say that you have a package ("example") with classes/modules that you want to include ("example.Example.hx", "example.Utils" etc.)
You can then compile using the following command:
> haxe -js bin/test.js -cp src --macro "include('example')"
This will produce a .js file including all classes in the "example" package.
However, I don't know if it's possible to restrict the compilation to just one single class/module inside a package.
(--macro "include('example.Example')" doesn't seem to work.)

Jonas

[Andy Li]

On Fri, Jan 9, 2015 at 1:19 PM, Cambiata <jona...@gmail.com> wrote:

However, I don't know if it's possible to restrict the compilation to just one single class/module inside a package.
(--macro "include('example.Example')" doesn't seem to work.)

This will work:

haxe -js bin/test.js -cp src example.Example

That is, no "-main" in the compiler argument, just give it the class.

Cheers,

Andy

 

[Marcelo de Moraes Serpa]

Andreas,

That’s pretty cool! Thanks for taking the time to upload this. The js-kit lib is pretty cool!

Opening a parenthesis here, how has been your experience working with Haxe and compiling for js/node? Did you feel Haxe adds friction or helps / boost your productivity? What are the main advantages your found that keep you using Haxe instead of vanilla Javascript or maybe Coffeescript?

I’m currently mainly using Coffeescript for js, and it does fix most of js nuisances and there’s very little (if any) friction since the code maps almost 1:1 to js. I’m looking forward to using Haxe too, and I’ve tested it but what is currently worrying me is the amount of externs it requires. Yes, it *can* turn out to be an advantage (such as the auto importing feature from js-kit), but keeping multiple externs up to date + the amount of forks and similar libs attempting to solve the same problem are what worry me, but I still believe that once I get the hang of it, Haxe for js will be a bliss. 

Cheers,

— Marcelo

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

[Saumya Ray]

Thanks Andy and Jonas.

Will give it a try.

[Andreas Söderlund]

Hey Marcelo, glad you like it. :) I think node development with Haxe is great. It's a bit of a slow start, but when you get up to speed and mentally disconnect from being in node/javascript it's really nice. Hopefully the meadowlark project can help people get started a bit quicker as well.

The advantages I see is the "power of Haxe" of course, but also that I can use what's not available in many other languages: DCI, Contracts and convenient BDD. I love Coffeescript too, so if Haxe would have short lambdas I wouldn't look back to it as frequently...!

Maintaining externs is a little bit of work, but after a while it's quite automatic as well (and you sure get to know the library you're using). Since the project is based on a book I'm updating the externs as I progress through it, following the structure of js-kit. Some improvements in creating externs would be nice, like a compact API description standard, or a wiki-style git repo where anyone can contribute their externs. You're allowed to dream, right? :) Of course, the last resort is to use Dynamic.

So give it a try, as soon as you're up to speed it's a pleasure!

/Andreas

[clemos]

Hi,

I'm the maintainer of haxe-js-kit.

I'd gladly accept more externs through a PR, especially since you seem to follow the library standard.

For the record, I'm not too much in favor of a too "open" way of contributing externs.

I think it's very important to carefully review and test each of them.

Also, the npm repo is a mess, and I believe it's important to select which libs are worth integrating.

Best,

Clément

[Andreas Söderlund]

Den fredag 9 januari 2015 kl. 19:49:00 UTC+7 skrev clemos:

Hi,

I'm the maintainer of haxe-js-kit.

I'd gladly accept more externs through a PR, especially since you seem to follow the library standard.

Hi, great job with the library! It really helped me get started quickly. As soon as I'm finished with the book I'll make a PR with the externs I got.

 

For the record, I'm not too much in favor of a too "open" way of contributing externs.

I think it's very important to carefully review and test each of them.

Also, the npm repo is a mess, and I believe it's important to select which libs are worth integrating.

Of course, it would be great if someone had the time to do that, and would decide with precision what is useful and not. But I don't think that's the case, the node world is too big. A combination would be nice, with for example voting and relatively easy improvement of what's submitted. Then add some taxonomy and the ability to make and share bundles for web/game/app/any development. And the same could be done with haxelib. (Another dream)

/Andreas

[Saumya Ray]

Thanks Andy.

This thing works from commandline not hxml file

haxe -js com/app/MyClass.js -cp src com.app.MyClass

That's without a "-main".

Now, the next question is about generating a AMD JS module. Is it possible to produce that ?

cheers

[Marcelo de Moraes Serpa]

>A combination would be nice, with for example voting and relatively easy improvement of what's submitted

Didn’t we have a site dedicated to haxe and node? Hexenode I guess?

Currently it’s hard to start with Haxe and nodejs mainly because of a lack of good bootstrap guides. There are many similar (and outdated) libs. Convention is good to create traction. I think node-kit should be the de-facto lib for node and Haxe.

I also remember the HaxeFoundation was sponsoring a specific nodejs lib that would eventually get into the std lib, which one was that? Perhaps you should join efforts?

— Marcelo

[clemos]

Hi,

On Fri, Jan 9, 2015 at 8:17 PM, Marcelo de Moraes Serpa <fullofc...@gmail.com> wrote:

>A combination would be nice, with for example voting and relatively easy improvement of what's submitted

Didn’t we have a site dedicated to haxe and node? Hexenode I guess?

There used to be haxejs.org and haxenode.org

But it seems they're dead now :

https://github.com/theRemix/haXenode.org

https://twitter.com/haxejs

 

Currently it’s hard to start with Haxe and nodejs mainly because of a lack of good bootstrap guides. There are many similar (and outdated) libs. Convention is good to create traction. I think node-kit should be the de-facto lib for node and Haxe.

I agree convention is very important, 

especially since it's what plain JS lacks most.

I also agree that getting started with Haxe + node.js can be difficult.

Just getting Haxe to work is still pretty hard for newbies (and even sometimes for relative veterans such as me...),

then you have to find some externs to begin with (as you said, there are several similar / outdated / half broken libs out there...).

Finally, when you're ready to go with Haxe+Node.js, 

you have yet to figure out which NPM lib(s) to work with (exact same issue than with externs, but at a _massive_ scale ;))

I'm trying to simplify this process by at least providing a set of tools with which you can very quickly make something work, 

and with which you can produce a variety of stuff 

(from web apps with express+mongodb / socket.io, to atom-shell desktop apps)

I made most of my professional work with this set of tools last year.

 

I also remember the HaxeFoundation was sponsoring a specific nodejs lib that would eventually get into the std lib, which one was that? Perhaps you should join efforts?

The Haxe foundation promoted one of the several collection of nodejs externs to an officially supported project

https://github.com/HaxeFoundation/hxnodejs

(was https://github.com/haxorplatform/nodehx)

As soon as it's officially released, I'll remove the core node.js externs from haxe-js-kit 

and the project will focus on maintaining externs for major npm libs (express, mongoose, etc), 

improving the various other features (dependency tracking / package.json generation, macro-powered mongoose modeling, ...)

and eventually add more (hopefully ease JS client/server "interoperability", integrate better with NPM for building / testing, ...) :) 

Thanks again for your support :D

Best,

Clément

[Andreas Mokros]

Hi.

On Fri, 9 Jan 2015 10:51:09 -0800 (PST)
Saumya Ray <2saum...@gmail.com> wrote:
> This thing works from commandline not hxml file
> haxe -js com/app/MyClass.js -cp src com.app.MyClass

hxml should work just as well:

-js com/app/MyClass.js
-cp src
com.app.MyClass

no?

> Now, the next question is about generating a AMD JS module. Is it
> possible to produce that ?

This has been asked several times. It doesn't make much sense in Haxe.
You'll end up getting duplicate (haxe-specific) code in your classes
and including/excluding classes by macro. Maybe producing some compiled
haxe-std-js classes and externs would help. But the default
haxe-js way is still compiling to one js-file (optimized with dce and
all).

--
Mockey

[Andreas Mokros]

Hi.

On Fri, 9 Jan 2015 13:17:44 -0600

Marcelo de Moraes Serpa <fullofc...@gmail.com> wrote:

> I think node-kit should be the de-facto lib for node and Haxe.

Not sure. Some things are not quite right there (IMO). I remember I
had to fix some classes when I tried it to get it compile correctly.
Maybe it was because of a newer node/express version, don't remember
exactly. I didn't make any pull requests, though, because I switched to
hxnodejs then (see below).

On Fri, 9 Jan 2015 13:48:56 +0100
clemos <cl3...@gmail.com> wrote:
> Also, the npm repo is a mess, and I believe it's important to select
> which libs are worth integrating.

Very true. Also some stuff is sadly outdated already (both from a node
and a haxe perspective).

On Fri, 9 Jan 2015 13:17:44 -0600

Marcelo de Moraes Serpa <fullofc...@gmail.com> wrote:

> I also remember the HaxeFoundation was sponsoring a specific nodejs
> lib that would eventually get into the std lib, which one was that?

https://github.com/HaxeFoundation/hxnodejs

Great work and already very usable (IMO). The problem is that creating
(and especially maintaining) externs of that quality is quite a lot of
work. I started out with some current express externs in that style. But
node module-APIs are also a moving target of course. Especially express
has changed quite a lot in 4.x as I have learned (no Connect
dependency, all middleware separate, which needs separate externs,
etc.).

--
Mockey

[Andreas Mokros]

Hi Clemos.

On Fri, 9 Jan 2015 21:23:32 +0100
clemos <cl3...@gmail.com> wrote:
> I'm trying to simplify this process by at least providing a set of
> tools with which you can very quickly make something work,
> and with which you can produce a variety of stuff
> (from web apps with express+mongodb / socket.io, to atom-shell
> desktop apps) I made most of my professional work with this set of
> tools last year.

js-kit is a great effort for sure. Sorry if I sounded so negative about
js-kit in my previous post but it was my first node.js project last year
and some things just didn't work for me then. So hopefully you won't
get me wrong.

I'll try to find my modifications from back then and send you some
pull-requests at least if they are still relevant.

--
Mockey

[Saumya Ray]

yeah! That did work from hxml.

-js com/app/MyClass.js 
-cp src 
com.app.MyClass 

I was passing them in one line before like

-js com/app/MyClass.js  -cp src com.app.MyClass 

Thanks a lot.

[clemos]

On Fri, Jan 9, 2015 at 9:48 PM, Andreas Mokros <m...@medienpensionat.com> wrote:

Hi Clemos.

On Fri, 9 Jan 2015 21:23:32 +0100
clemos <cl3...@gmail.com> wrote:
> I'm trying to simplify this process by at least providing a set of
> tools with which you can very quickly make something work,
> and with which you can produce a variety of stuff
> (from web apps with express+mongodb / socket.io, to atom-shell
> desktop apps) I made most of my professional work with this set of
> tools last year.

js-kit is a great effort for sure. Sorry if I sounded so negative about
js-kit in my previous post but it was my first node.js project last year
and some things just didn't work for me then. So hopefully you won't
get me wrong.

No problem :)

I actually don't use the "core" node.js api a lot in my projects, 

it's definitely not the most complete and well tested part of the project,

so I'm quite happy to let this part to others ;)

As for the rest, there are still a lot of things I'd like to improve,

express is one of them (the type signatures are pretty difficult to adapt),

socket.io, also (which I'm rewriting based on 1.0)

 

I'll try to find my modifications from back then and send you some
pull-requests at least if they are still relevant.

Would be great :)

Best,

Clément

 

--
Mockey

[Andreas Mokros]

Hi.

On Fri, 9 Jan 2015 22:32:38 +0100
clemos <cl3...@gmail.com> wrote:
> express is one of them (the type signatures are pretty difficult to
> adapt),

I'll put my express attempts on github soon.

> socket.io, also (which I'm rewriting based on 1.0)

Yes, API-changes as well there...

--
Mockey