So, as the title says, when GWT compiles Java into JavaScript, is the result just minified, or is it obfuscated also?
According to the GWT FAQ the code is obfuscated, but they state that "This is partly done to protect the intellectual property of the application you develop, but also because obfuscation reduces the size of the generated JavaScript files". I'm not sure if this is true obfuscation or just variable/method renaming and stripping of whitespaces. A "true" obfuscation might actually make the code larger than the original code.
I'd also like to say that the GWT compiler minifies Js because of its optimization. It will, for example, inline method calls where possible and rename variables to shorter names.
Target is to get as small (and fast) code as possible. "Obfuscation" is just a consequence.
Related
I did find a very interesting tool for identify unused css definitions in a web project.
http://www.sitepoint.com/dustmeselectors/
Are there similar tools also for javascript projects?
P.S.
I know there is no program for deterministically finding unused code. But I am looking for a report to identify possible unused code. Then the last decision will always be your own.
Problem is there is no way to be really sure. Suppose the following:
The initial HTML site is practically empty. There is a lot of JS code though, which seems to be unused.
OnLoad, a function is called which launches an AJAX query to the server. The server returns a lot of HTML code, which is the body of the site. This body contains lots of JavaScript functions.
The initial body is replaced with the body received via AJAX. Suddenly, all code is used.
Static analysis utilities are therefore useless. I do not know whether there exists a browser extension that marks all JS usage from a running browser though.
You can try using tombstones to safely locate and remove dead code from your JavaScript.
https://blog.bugsnag.com/javascript-refactoring-with-bugsnag-and-tombstones/
In order to find the unused assets, to remove manually, you can use deadfile library:
https://m-izadmehr.github.io/deadfile/
It can simply find unused files, in any JS project.
Without any config, it supports ES6, JSX, and Vue files:
The one that comes to mind most quickly is Javascript LINT (http://www.javascriptlint.com/) and JSLint (http://www.jslint.com/).
Beware though: the latter hurts your feelings.
Yes, I know that less was in first place written for node.js.
But I really want to use it without adding node.js to my server, or learning how it works.
Is there some implementations of less written in other languages? Or maybe something similar to less?
You could take a look at SCSS. The compilation of files into CSS is done by a Ruby script which is very easy to get set up (even on Windows), and the syntax and feature list is almost identical. I'd even say that the documentation of SCSS is better than LESS.
That said, I have managed to get LESS compilation running locally by running the file in a Javascript engine (in my case, Komodo Edit's macro system is powered by Javascript, but it could work with Rhino or V8). You do have to modify the source a little, to simulate the window object. I got a lot of help by looking at the code of the Less Engine project, which basically allows Less to be executed within a JVM.
There is a Windows LESS compiler for .NET and a standalone version of it as well. I find this latter considerably better (i.e. fewer bugs) than less.js, although both are pretty odd in the way they handle comments: less.js doesn't understand two comments in a row, and lessc.exe doesn't understand comments inside selectors. I really don't see the point of compiling the .less file at the client once per page download per client when you could have done it once for the universe at build time.
There is also a Python implementation of SCSS: http://packages.python.org/scss/. It works quite well and includes a watch folder function.
There is very nice PHP class: http://leafo.net/lessphp/
I'm starting to learn JavaScript for my first language and I am kind of starting to get the hang of it.
But I'm beginning to check out source codes of .js files in websites and I see a lot of people put the the entire script in just one line which. For one, this is hard for me to understand from a learning point, but my main question is: is there a benefit for doing this, rather than coding it in more of a block style?
The developers of the code won't be writing it like that themselves, they'll be using a normal style. Because JavaScript isn't compiled, developers often run it through a tool called a minifier instead:
Minification in computer programming languages and especially JavaScript, is the process of removing all unnecessary characters from source code, without changing its functionality. [...] Minified source code is especially useful for interpreted languages deployed and transmitted on the Internet (such as JavaScript), because it reduces the amount of data that needs to be transferred.
Minified code is harder to understand; this is often seen as a feature because it makes it harder for other people to copy your code and use it themselves. Some minification tools, such as Google's Closure Compiler, also optimize the code, improving performance and removing redundant code.
You should develop using normal indented code and, if you want, run it through a minifier when publishing it on your web server.
benefit for doing this rather
It makes the script smaller, so it downloads faster.
than coding it in more of a block style
The scripts will be coded in block style. They are just minified as part of the publishing process.
For file size. The easiest way to reduce the number of bytes downloaded to a user's browser is to remove all unnecessary whitespace (including newlines) from every JavaScript and CSS file. Depending on the number of lines, that could save several kilobytes.
You're probably looking a scripts that have been "minified", that is, all of the unnecessary line breaks and white space, etc. have been removed. The advantage of this is that the script has a smaller memory footprint and uses less bandwidth when it's transmitted over the wire.
Each character == a unit of digital information (bits, bytes, etc...)
Less Bits and Bytes === faster loading times.
It's called minifying. It's not written like that originally.
Wikipedia:
Minified source code is especially useful for interpreted languages
deployed and transmitted on the Internet (such as JavaScript), because
it reduces the amount of data that needs to be transferred. Minified
source code may also be used as a kind of obfuscation.
Source
Minification, removing unnecessary white spaces and characters to reduce the size.
You'll find the script has been put in one line when it is 'minified'. This means that unnecessary white space and all comments have been removed.
A Script file is minified to reduce the size of the JavaScript file in order to optimise it for download from the server to the client browser.
All the minified script will have been developed as a block of code as you describe, and then passed through a 'minifier' like JSMin
There is a further stage referred to a zipping, which is to give all variables and function the smallest possible names ('a', 'b', etc).
In addition, both these stages are useful as a crude obfuscator
You will find that this is more a deployment step than a discreet developement one. The original version of the script will (or at least should) be retained by the owner.
They don't code in one single line, once the code is ready, they remove spaces and comments so the code is not too heavy and will load quickly
For a project I'm tangentially working on, I need a way to compile JavaScript into some intermediate language or bytecode so that I can single-step through it. I know that many of the JavaScript engines in modern browsers do something like this, but they don't make the resulting bytecode accessible. Is there a good off-the-shelf tool for this sort of JavaScript compilation?
Not exactly sure of your needs, however maybe Rhino could work for you.
The JavaScript compiler translates
JavaScript source into Java class
files. The resulting Java class files
can then be loaded and executed at
another time, providing a convenient
method for transfering JavaScript, and
for avoiding translation cost.
More about the compile function is located here.
Do you have a step in your deployment process that minifies JS? Do you have any sort of preprocessor for your JavaScript that allows you to leave in comments and console.logs and then have them automatically stripped out? Is your JavaScript machine generated by GWT or Script#? Do you use ANT or another tool to automate deployment?
I see a lot of JavaScript that looks like it comes right out of the editor, complete with lots of white space and comments. How much of that is due to not caring about the state of the deployed code, and how much is due to the spirit of the open web?
I usually check it out with JSLint to make sure it is bug-free, then pack it/encode it with YUI compressor.
My steps include:
I write Javascript using TextMate with the Javascript Tools bundle installed. This JSLint's my files on every save and notifies me when errors occur.
I use Sprockets to automatically concatenate my various Javascript files.
I run the resulting concatenation through jsmin to generate a minified version.
I end up with a concatenated lib.js file and a minified lib.min.js file. One I use for development, one for production. TextMate commands help automate it all.
I'm still looking for a good solution to actually (unit) test my scripts.
Check out YUI Compressor its a console app that you can use to minify (strip out comments, whitespace etc..) and also obfuscate your javascript files.
JSMin it from Douglas Crockford. We've got it hooked up as a macro in Studio as well as a post build item for some of our larger projects
FWIW, here's an interesting mini-benchmark on various ways you can minimize your Javascript source:
http://www.ericmmartin.com/comparison-of-javascript-compression-methods/
In short:
gzip compression in HTTP protocol really makes a difference (although you need to pay a CPU cost at the server side)
minification (removal of whitespace/comments, change of variable names etc.) also helps, and if you want best result, use it together with gzip compression
js-based decompressors are most likely useless - while you might get smaller size, the CPU overhead on the client is significant.
For one of our products, we concatenate all Javascript files together (most files are used on most pages, so this makes sense for us) and use Javascript::Minifier. This has given us a pretty nice speed boost.
A lot of it is probably due to not caring about people that might be viewing your pages on slower machines with slower connections and assuming that everyone has a 50Mbps line and three Gigs of RAM.
We are minifying our (hand-written + plugins, jQuery, etc.) JS as a part of the build process in .NET environment. No preprocessor, this is something we should definitely be doing once time permits.
P.S. By the way, we're not using console.log, as this will break IE. Instead we have a simple wrapper function, something like:
function log(stuff) {
if (window.console && window.console.log) {
console.log(stuff);
}
};
I have a PHP script that does it on the server side and keeps a cache of whatever it pulls from the source folder(s).
One word- packer
Light a candle, whisper a prayer against IE6 errors, and click "go". Does that count? :)
I don't minify my own javascript code since text tends to gzip/compress well.
I would minify a very large (say > 100 kb) javascript library (but then again I probably would not want to be using such a large library (or just ship what i use)).
I tend to believe that a lot of the javascript-minification is (in reality) done to achieve some sort of (futile) obfuscation of javascript code instead of the proclaimed end-user performance gain.
There's also a .NET port of YUI Compressor which allows you to:-
intergrate the minification/file combining into Visual Studio post-build events
intergrate into a TFS Build (including CI)
if you wish to just use the dll's in your own code (eg. on the fly minification).
I thought I would share my approach to js deployments. Have a look at this blog post:
http://www.picnet.com.au/blogs/Guido/post/2009/12/10/Javascript-runtime-compilation-using-AspNet-and-Googles-Closure-Compiler.aspx
This also includes code to compile (using google's closure compiler) at runtime (when needed).
Thanks Guido