Closure Compiler obfuscation with text! plugin for templates in 1.7 with AMD

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Closure Compiler obfuscation with text! plugin for templates in 1.7 with AMD

allnamesrtaken
Any wizard out there who knows:
1. How will does Closure Compiler obfuscation work with dojo
2. if it is possible for solutions with templated widgets using text! plugin in the AMD define statement to load the resource, to still obfuscate in 1.7?
3. does the inlining of the template's happen before the obfuscation by default when building (kind of solves 2.)?
4. Does AMD modules obfuscate well in 1.7?

In hopes of a genius!
//J
Reply | Threaded
Open this post in threaded view
|

Re: Closure Compiler obfuscation with text! plugin for templates in 1.7 with AMD

neonstalwart
to nitpick just a little, i'm not sure if you really mean optimization
rather than obfuscation.  optimizing the code will obfuscate it but i
wouldn't characterize it as obfuscation since it doesn't exactly hide
anything - it just makes it harder to read.  i'm just wanting to clarify
what your end goal is here.  for the rest of my response i've assumed
you just want obfuscation that's gained by optimization and not
obfuscation in the sense that would make your source code "top secret".

there are multiple levels of optimization available with the closure
compiler.  the simplest just shortens variable names.  there is an
advanced level that will also shorten property names and globals and
will alias references to undefined, null, true, false, etc such that
those are shortened as well.  in this advanced mode i believe there are
many configuration options available depending on how you're driving the
compiler.  the advanced optimizations are known to break a lot of code
that was not written with these optimizations in mind.  dojo's code was
not written with the closure compiler's advanced optimizations in mind.

1.
by using dojo's builder with java/rhino you are already using the
closure compiler with simple optimizations so there is no need for you
to find a genius to get this to happen - we've already found one who did
it :)  some people have also looked into how to optimize dojo's code
with the advanced optimizations but it requires changes to dojo's source
to get it to work.  (i don't have a reference for you on this, maybe
someone else can provide it).

2.
yes.  the inlined template is a string literal so its not touched by the
optimizations.

3.
dojo's build tool will inline the templates before minifying.

4.
i'm not sure what you mean by "obfuscate well".  we have a build tool
that works - it optimizes your code (or its a bug if it doesn't).  there
are things that you can do to help decrease the size of your optimized
code but some of these work against the optimization that can be
provided by gzip since gzip works well with strings that are repeated.  
...and if you're not gzipping your code you're missing one of the
biggest optimizations you can do.

hope that answers your questions.

ben...

On 7/11/2011 6:39 AM, allnamesrtaken wrote:

> Any wizard out there who knows:
> 1. How will does Closure Compiler obfuscation work with dojo
> 2. if it is possible for solutions with templated widgets using text! plugin
> in the AMD define statement to load the resource, to still obfuscate in 1.7?
> 3. does the inlining of the template's happen before the obfuscation by
> default when building (kind of solves 2.)?
> 4. Does AMD modules obfuscate well in 1.7?
>
> In hopes of a genius!
> //J
>
> --
> View this message in context: http://dojo-toolkit.33424.n3.nabble.com/Closure-Compiler-obfuscation-with-text-plugin-for-templates-in-1-7-with-AMD-tp3158785p3158785.html
> Sent from the Dojo Toolkit mailing list archive at Nabble.com.
> ________________________________________________________
> Dojotoolkit: http://dojotoolkit.org
> Reference Guide: http://dojotoolkit.org/reference-guide
> API Documentation: http://dojotoolkit.org/api
> Tutorials: http://dojotoolkit.org/documentation
>
> [hidden email]
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
________________________________________________________
Dojotoolkit: http://dojotoolkit.org
Reference Guide: http://dojotoolkit.org/reference-guide
API Documentation: http://dojotoolkit.org/api
Tutorials: http://dojotoolkit.org/documentation

[hidden email]
http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
Reply | Threaded
Open this post in threaded view
|

Re: Closure Compiler obfuscation with text! plugin for templates in 1.7 with AMD

allnamesrtaken
Thx Ben I owe you a beer,

To answer you first question. Yes I meant minification but including property and variable replacement, so that would be Advanced mode of CC. And I am both after the minification for natural reasons but also the "obfuscation" effect you get by shortening variable names, properies and even private functions (if thats possible to declare? is it?)

But since I dojo is open I am clearly not after obfuscating the dojo libraries, only private libraries. Maybe there is a better tool that could be used to pre process the  libraries you want to make less readable and then just run a simple mode CC or shrinksafe on the whole project?
Or maybe the 1.7 builder (bdBuild) can be configured in such way and then have 2 builds after each other, one for dereadability and one for building?

If I read you right here, I don't get CC automatically if running the build script through node? Well I can configure that then.

Generally though I am not getting the 1.7.0b1 build to build so to say. It fails like I explained in my earlier post, but I guess I will have to either debug the builder or wait for a less beta release. Have you managed to build in 1.7 using node?

Lastly, Do you know of any plans for propery binding to markup in markup? (more like MVVM or like we can do now in the templates using ${foo.bar} but with automatic update as the property change. It would make the separation a bit nicer.

Thanks again ben, and as I said I owe you a beer (or other beverage of choice) :)

//J
Reply | Threaded
Open this post in threaded view
|

Re: Closure Compiler obfuscation with text! plugin for templates in 1.7 with AMD

neonstalwart
dojo comes close to providing some of the pieces needed for reactive
templating (ie declarative binding in markup) but the complete solution
doesn't exist.  you can use attributeMap (or its 1.7 equivalent) to map
properties of widgets to properties of particular nodes in your template
but this is not a full solution for reactive templating.  there is also
dojox/dtl which provides a more expressive syntax for generating
templates but this does not automatically react to changes in the
underlying data.  you can do this at a very coarse level by listening
for changes to the underlying data and re-rendering the template when
there is a change.  unfortunately, continuing support for dtl is sparse
so you may find it hard to get bugs fixed.  with dojo 1.7 there will be
dojox/mvc (see
http://archive.dojotoolkit.org/nightly/dojotoolkit/dojox/mvc/tests/mvc_index.html)
and this provides a way to bind form inputs (child widgets) to a model
and has some support for repeating parts of a template but doesn't
provide enough to make a whole template reactive.

i know there is some work being done on a project to provide reactive
templating for dijit and i've heard there are plans to open source that
code but i don't know the current status of that project.  i've been
monitoring the progress of https://github.com/SteveSanderson/knockout 
and https://github.com/wycats/handlebars.js and think that some
combination of those 2 with dijit's widgets would be very interesting.  
afaik, handlebars was developed specifically for sproutcore 2 and
they've managed to do something to provide bindings and templating
(http://guides.sproutcore20.com/using_handlebars.html#setting-up-bindings)
in their views.  if dojox/dtl progressed with better support for
bindings it could be very similar except with django's syntax rather
than mustache.  this whole topic is something that's on my radar, be
sure to let me know if you find a good solution.

as for the build, i've managed to get some code to build with 1.7 and
node but that was probably even before the first beta release.  of
course i wouldn't expect things are any worse now but i'm waiting for
docs before i spend any more time trying the build with existing code.  
this is mostly because i'd like to find out what new features are
available and assess whether i might like to use some of those features.

so far, i'm very impressed with the speed of the build... build times
seemed to have improved in rhino and are blazing fast running on node.  
iirc, i have a build that previously took ~12+ minutes and now takes
less than 2 minutes with node.  i seem to remember that it was about
10-12x faster comparing node to the old build and i think it was about
6x faster when comparing rhino to the old build.  of course ymmv and
that was a couple of months ago so my memory may also be distorting
those figures.

ben...

On 7/11/2011 12:20 PM, allnamesrtaken wrote:

> Thx Ben I owe you a beer,
>
> To answer you first question. Yes I meant minification but including
> property and variable replacement, so that would be Advanced mode of CC. And
> I am both after the minification for natural reasons but also the
> "obfuscation" effect you get by shortening variable names, properies and
> even private functions (if thats possible to declare? is it?)
>
> But since I dojo is open I am clearly not after obfuscating the dojo
> libraries, only private libraries. Maybe there is a better tool that could
> be used to pre process the  libraries you want to make less readable and
> then just run a simple mode CC or shrinksafe on the whole project?
> Or maybe the 1.7 builder (bdBuild) can be configured in such way and then
> have 2 builds after each other, one for dereadability and one for building?
>
> If I read you right here, I don't get CC automatically if running the build
> script through node? Well I can configure that then.
>
> Generally though I am not getting the 1.7.0b1 build to build so to say. It
> fails like I explained in my earlier post, but I guess I will have to either
> debug the builder or wait for a less beta release. Have you managed to build
> in 1.7 using node?
>
> Lastly, Do you know of any plans for propery binding to markup in markup?
> (more like MVVM or like we can do now in the templates using ${foo.bar} but
> with automatic update as the property change. It would make the separation a
> bit nicer.
>
> Thanks again ben, and as I said I owe you a beer (or other beverage of
> choice) :)
>
> //J
>
> --
> View this message in context: http://dojo-toolkit.33424.n3.nabble.com/Closure-Compiler-obfuscation-with-text-plugin-for-templates-in-1-7-with-AMD-tp3158785p3159665.html
> Sent from the Dojo Toolkit mailing list archive at Nabble.com.
> ________________________________________________________
> Dojotoolkit: http://dojotoolkit.org
> Reference Guide: http://dojotoolkit.org/reference-guide
> API Documentation: http://dojotoolkit.org/api
> Tutorials: http://dojotoolkit.org/documentation
>
> [hidden email]
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
________________________________________________________
Dojotoolkit: http://dojotoolkit.org
Reference Guide: http://dojotoolkit.org/reference-guide
API Documentation: http://dojotoolkit.org/api
Tutorials: http://dojotoolkit.org/documentation

[hidden email]
http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
Reply | Threaded
Open this post in threaded view
|

Re: Closure Compiler obfuscation with text! plugin for templates in 1.7 with AMD

allnamesrtaken
I will sure let you know if I find something on the declarative binding horizon. I was myself thinking of a compile hack, just parse the template files for some syntax within the declerative use of properties ei. ${foo.bar$lookhere} and then in in the script remove the $lookhere and  add some boilerplate js code to the object (_setXXXAttr: ...).

Sure it wouldnt really do it all but atleast my code would be cleaner and then as I compile it, it gets connected. Maybe its more work than its worth though.

Anyhow Ill yell if I find something.
//J