Haxe output minified / obfuscated code. Compiler responsibility?

[Séb Patu]

Hi,

what do you use for code minification, and especially obfuscation for haxe output code?

I saw Haxemin, but did not test it yet, it seems fairly efficient, but:

Don't you thinklike me that it would be great feature to have minification/obfuscation handled by compiler itself?
 doing it with the compiler instead of target tools, or even HaxeMin which is middle solution would

• give the smallest code possible
• making it more easy to maintain
• Give clean compilation errors, for example when you use non static String content in Reflec, that would break the obfuscation.
• ensure that obfuscated code is fully running, without worrying about what haxe feature we use.

It's very important feature today, for the js output in web, but also for the size of mobile apps we want to distribute.
And obfucation is a way to protect against reverse engineering.

Like compiler is the best to give auto completion informations, it will also be the best to do minification / obfuscation job.

what do you think?

[der Raab]

Thanks for bringing this up! I use this thread as opportunity to add a question: Will Haxe 3.2 have a different JavaScript output? While the current JavaScript syntax is pretty straight forward and easy to debug, it's minified versions result in still quite big files. Of course it's not that much of a problem if gzip for .js files is activated on the server side but we would like to add some optimizations later... I think one of the problems (for example) is the output of the full namespace for each static property (see enums) or the __name__ array for each class. I just wonder if this is something the Haxe Foundation is aware.

[Timothy Farrell]

While I am new to Haxe, front-end development is my forte.  IMHO, I don't think Haxe should add any sort of minification/obfuscation.

First, minification and obfuscation are very different things even if they look similar on the surface.  True obfuscation should be left as an edge-case scenario for the very few products that address it correctly.  Furthermore, I don't think the vast majority of people need obfuscation (even most closed-source apps) and so it would be a lot of development effort for something that not many people would use.

I also don't think minification should be a part of Haxe because there are tons of good tools in this space.  Maybe there are some optimizations that Haxe could build into its default JS generator but I'm not sure it's worth the effort.  I think the reason that the Haxe (I'm speculating) developers included the custom JS generator option is precisely because people want their javascript in different formats.  In another thread I posted a JSGenerator that I'm working on that outputs each class to its own file as an AMD module (https://gist.github.com/explorigin/619e4f4ec41e173b6ced).

If you have a website where JS file size matters to the point where just gzipping the output is not enough then you should be using more tools than just Haxe to optimize your website.  That being the case, you can integrate UglifyJS or Google Closure into that workflow after you compile your Haxe to JS.

Finally, I do think it would be worth it to have an option that adds notation to take advantage of the Google Closure compiler's advanced optimization features (https://developers.google.com/closure/compiler/docs/api-tutorial3) but even this could be done with a custom JS generator I think.

I think it's helpful to view Haxe-generated JS as a sort of C++ vs Assembly comparison.  Haxe output will never be as succinct as hand-coded JS.  However, even though it may look unnecessarily bulky in some instances, in reality, it's not that bad.  If you have a tight-loop that needs hyper-optimization or code that comes up bulky when you need it slim, then you should probably be hand-coding or re-evaluating the parts of the Haxe standard library that are "bloating" the output (like the serializer).  But if you consider that with Haxe, even though the code is larger, you're more likely using most of it that is coming out.  By contrast, jQuery is quite large and most people only use small portions of it.

-tim

[Séb Patu]

@der Raab:

i listened a presentation of haxe by nicolas recently, and the readable output code is one of the objectives of haxe, to make the debug easy on the target side.

so i don't think they will change the output for minification concerns.

thats one more argument to have minify / obfuscate directly handled by the compiler itself :)

you can also customise the js output yourself, with custom js generator see last paragraph of this: http://old.haxe.org/manual/macros_compiler

[Séb Patu]

@Timothy

Maybe people don't use it much, today, because theres no cross Platform easy and solid solution for haxe.

If it was there, im sure people would use it widely.

Size is important matter nowadays, not only for js and web, but also for mobile apps, when you want your app to be downloadable from a 3G connection.

"it would be a lot of development effort"

why? haxemin already do a great job with a fairly simple lib.

"because there are tons of good tools in this space"

for js target maybe, but not other targets, in mobile app space and so, not i am aware of at least. And would not it be easier to have one single solution in the compiler, instead of several Tools, one for each target, i mean thats the whole purpose of haxe, being cross Platform.

if not, why we have munit in std lib?

"use UglifyJS or Google Closure"

it is not so easy because of Reflect feature of haxe!

and the idea is to have a tool that do the job, without worrying about which feature of haxe we use. If what you do is an issue, you can compiler error and thats all.

again, thats same logic behind haxe at first. you don't want to be too much carefull about what you use in haxe, it will (it must) run perfectly on any target. performance tweeking is another question.

[Chii Chan]

not so easy because of Reflect feature of haxe!

i wonder if it's possible to compile haxe into java, then use GWT to minify the output java into js? GWT supports a limited set of reflection features that works even after being compiled into js (https://code.google.com/p/gwt-reflection/ for example)

[Juraj Kirchheim]

On Wed, Feb 18, 2015 at 2:56 PM, der Raab <goo...@derraab.com> wrote:

Thanks for bringing this up! I use this thread as opportunity to add a question: Will Haxe 3.2 have a different JavaScript output? While the current JavaScript syntax is pretty straight forward and easy to debug, it's minified versions result in still quite big files. Of course it's not that much of a problem if gzip for .js files is activated on the server side but we would like to add some optimizations later... I think one of the problems (for example) is the output of the full namespace for each static property (see enums) or the __name__ array for each class.

There is -D js_flatten which then works pretty well with closure in simple mode. Also, the Haxe output is generally closure compatible, which really is more useful than attempting to duplicate Google's efforts.

Also, the Haxe output is generally smaller if you do not use reflection. The additional payload (like __name__) is included for just that purpose.

Best,

Juraj

[der Raab]

So if I never use the Reflect-API this won't be created at all?

[der Raab]

And does avoiding strict casting also reduce the output?

[Nathan Hüsken]

I have a follow up question to that: If one of the libraries is using
the reflect API, it gets pulled in and increases the output size, right?
Can one somehow detect if one if the libraries is doing that and which?

[Séb Patu]

@back2dos good to know about -D js_flatten

but it does not resolve issue with Reflect for Google closure right?

and i don't think a haxe minifier / obfuscator would mean duplicate Google closure efforts, because we still can have a second pass for js target with it.

Am i the only one thinking that it would also be usefull for any other target of haxe, like for mobile apps? (or tv!)

[Juraj Kirchheim]

On Fri, Feb 20, 2015 at 5:06 PM, Séb Patu <seb...@gmail.com> wrote:

@back2dos good to know about -D js_flatten

but it does not resolve issue with Reflect for Google closure right?

Macros solve the issue of having to use reflection in the first place. I appreciate the fact that to most people they just look like dark magic, but ultimately, meta-programming in a statically typed language is simply better to do at compile time than runtime for a great many reasons. Not having to rely on reflection is just a nice bonus.

 

and i don't think a haxe minifier / obfuscator would mean duplicate Google closure efforts, because we still can have a second pass for js target with it.

You say "because" but I fail to see how one statement follows from the other. Google closure does a very good job at what you seem to be after. It optimizes JavaScript code so much that it becomes unintelligible, which then meets both your goals. How would trying to achieve these goals in the compiler do anything different?

Am i the only one thinking that it would also be usefull for any other target of haxe, like for mobile apps? (or tv!)

You probably are not the only one, but I don't think you will find enthusiasm for obfuscation in this community to be rather sparse - particularly in the compiler team. So instead you should look for obfuscation tools that you can integrate further down the toolchain, as most of the target ecosystems have this kind of tooling already.

Best,

Juraj

[Joshua Granick]

I'd be happy to see code minifying (further than Closure "simple" mode) and obfuscation supported as part of the Lime tools, if it were stable to do so. I do agree that if this were included in the compile process, it could be more reliable, but I think that the focus of the core team is probably higher level than this -- if it can emit good reliable code, then obfuscating/minifying works alright as a second step which can be optionally enabled/disabled, plus, the core library is not released that often, so if there are minor issues, outside of Haxe would enable it to be improved more quickly.

Like Juraj said, using macros to replace dynamic access is a compelling point on solidifying code so it minifies well. I need to apply this to Actuate, and check out any other cases for dynamic access in common workflows

[Philippe Elsass]

Would generating Google Closure annotations be the solution?

Provided you can make your code compatible with full dce, Closure advanced optimisation will practically obfuscate your code.

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

[David Elahee]

For the record mt, do use its own obfuscation tools for yeaaaaars now, sidelong haxe, so there is no fundamental problem here or hostility to obfuscation.

The haxe team can help you if you need to make things compatible with your obfuscation flow but won t mix compiler and obfuscation out of the box for now Those are two different problems,so we leave the obfuscation problems up to users.

If you need help with the compiler because it actually prevent an obfuscation technology to be implemented, please file an issue :)

[white...@gmail.com]

Hi,

Regarding Reflect you could take a look at : 

http://yal.cc/introducing-haxmin/ and https://github.com/yellowafterlife/haxmin

 

 

Here is an obfuscation flow that could work:

merge and mangle js files with uglifyjs then use HaxMin. Obviously you'll have to update the whitelist HaxMin uses but that should not be a problem.

 

 

Current tests have shown promising results so far with merging big js libs (jquery, pixijs) with my haxe generated js file and then using HaxMin.

I need to research a little further though but it could give you ideas

 

IMHO I don't think obfuscation should be a compiler feature.

++

 

 

François Nicaise
http://www.linkedin.com/in/fnicaise
www.francoisnicaise.fr

Freelance Game Developer / Designer 
Business Relations @ FrenchCows
Gaming & Business @ Bordeaux Games

"David Elahee" <david....@gmail.com> wrote:

--

[whitetigle]

Sorry guys for the duplicate, I should have re-read the thread from the beggining :)

-- 
--
François Nicaise
https://www.linkedin.com/in/fnicaise