What should be done / avoided to compile Haxe to JS as slim as possible?

[Pierre Chamberlain]

Hey Haxers!

I'm relatively new to using Haxe to compile JS code, but would love using it on a daily basis for strict-typing JS (over using say... TypeScript!).

The one thing that makes me a bit hesitant to use Haxe though is not knowing which built-in classes / features will cause it to compile a bunch of preparation code.

I've tried a simple example by compiling a class using an instance of List<String> (and invoked an add() / remove()), and another test without the List.

Haxe does seem to do a wonderful job only including the necessary methods / properties mentioned in the Haxe project classes. But seeing that it generates a List function/prototype object (which I completely understand, it's not an Array persé, it's more of a linked-list), I can see how this could grow larger if I made use of other built-in features, maybe like Generics.

So is there any guidelines you can recommend for reusing JS built-in classes as much as possible, to keep the generated code slim?

(ex: Using Arrays over Lists, I guess that would be one?)

Also, while I'm on the JS topic - is it possible to change how Haxe compiles custom classes? Either with a compiler flag, or would I need to roll my own exporting-script or something of the sort?

(see snapshot of a Google Dev article)

[Dan Korostelev]

We could probably make the JS generator move constants initialization into prototype, but I doubt it will get us any real profit, so I'd not spend time on it unless you have some benchmarks that show significant improvement.

Your List example shows how DCE (dead code elimination) works - it removes any unused methods/types from the generated code. By default it only runs for std lib classes, but you can pass "-dce full" to make it work on your code as well.

As for the "slim code" - i think really the only thing you want to avoid is using reflection - not only it adds a bunch of RTTI stuff into generated code, but also is a bad way to code in haxe in general. Other things that haxe generates are actually good and I don't see any reason to avoid them. 

Trying to make Haxe-generated code look like JS most likely means you have to code in haxe as you would code in plain JS, without using its features (e.g. enums or pattern matching) which disregard the very reason to use haxe instead of JS in the first place.

понедельник, 20 октября 2014 г., 18:18:10 UTC+4 пользователь Pierre Chamberlain написал:

[Pierre Chamberlain]

Alright thanks. It does seem to be pretty lightweight in general. I'll keep in mind though to only use reflection if I absolutely need it - thanks! :)

-Pierre

[Cristian Baluta]

I created this lib to minify and scramble the files http://lib.haxe.org/legacy/p/jsscramble

And there's this one as well http://lib.haxe.org/legacy/p/jsmin

Didn't tested any with haxe3 though

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

--

Băluță Cristian
http://ralcr.com
http://imagin.ro

[Philippe Elsass]

Firstly you should probably use Array<T>, which gets translated into a regular Array,  instead of List ;)

The class initialisation recommendation is good but not something that can be changed easily. Also that's arguably a micro-optimisation.

You shouldn't worry too much about the size of the generated code: including all Haxe special features won't represent much in regard to the final project. I think it's worth it and everything gets gzipped in the end by the server.

The most you can save (up to 5% of the output size) will be by not using any Reflexion of any sort. I'm not sure if that includes enums.