Minification process on JavaScript as per definition basically just removes blank spaces , comments . Building on this , why in Nodejs is language specification pertaining to whether code is written in ECMA5 or ECMA6 necessary ? Why not just run the minifier and minify the code by removing blank spaces and comments. Why do I need to bother whether my code is written ECMA5 OR 6 ?
Thanks in advance.
Minification process on JavaScript as per definition basically just removes blank spaces, comments.
I have no idea whose "definition" you are quoting. Minification is much, much more than squeezing out white space. Minifiers parse the entire source in order to do advanced minification. Obviously, to do that, they have to know the syntax they are parsing. If they don't know ES6 syntax, they cannot parse ES6 input. To minify ES6, you'll have to choose a minifier that supports ES6.
Related
I'm just wondering is there a difference in performance using removing spaces before and after equal signs. Like this two code snippets.
first
int i = 0;
second
int i=0;
I'm using the first one, but my friend who is learning html/javascript told me that my coding is inefficient. Is it true in html/javascript? And is it a huge bump in the performance? Will it also be same in c++/c# and other programming languages? And about the indent, he said 3 spaces is better that tab. But I already used to code like this. So I just want to know if he is correct.
Your friend is a bit misguided.
The extra spaces in the code will make a small difference in the size of the JS file which could make a small difference in the download speed, though I'd be surprised if it was noticeable or meaningful.
The extra spaces are unlikely to make a meaningful difference in the time to parse the file.
Once the file is parsed, the extra spaces will not make any difference in execution speed since they are not part of the parsed code.
If you really want to optimize download or parse speed, the way to do that is to write your code in the most readable fashion possible for best maintainability and then use a minimizer for the deployed code and this is a standard practice by many web sites. This will give you the best of both worlds - maintainable, readable code and minimum deployed size.
A minimizer will remove all unnecessary spacing, shorten the names of variables, remove comments, collapse lines, etc... all designed to make the deployed code as small as possible without changing the run-time meaning of the code at all.
C++ is a compiled language. As such, only the compiler that the developer uses sees any extra spaces (same with comments). Those spaces are gone once the code has been compiled into native code which is what the end-user gets and runs. So, issues about spaces between elements in a line are simply not applicable at all for C++.
Javascript is an interpreted language. That means the source code is downloaded to the browser and the browser then parses the code at runtime into some opcode form that the interpreter can run. The spaces in Javascript will be part of the downloaded code (if you don't use a minimizer to remove them), but once the code is parsed, those extra spaces are not part of the run-time performance of the code. Thus, the spaces could have a small influence on the download time and perhaps an even smaller influence on the parse time (though I'm guessing unlikely to be measurable or meaningful). As I said above, the way to optimize this for Javascript is to use spaces to enhance readability in the source code and then run a minimizer over the code to generate a deployed version of the code to minimize the deployed size of the file. This preserves maximum readability and minimizes download size.
There is little (javascript) to no (c#, c++, Java) difference in performance. In the compiled languages in particular, the source code compiles to the exact same machine code.
Using spaces instead of tabs can be a good idea, but not because of performance. Rather, if you aren't careful, use of tabs can result in "tab rot", where there are tabs in some places and spaces in others, and the indentation of the source code depends on your tab settings, making it hard to read.
I came to know that "obscure" the code - make it less readable, but will still execute.
It replaces symbol names with non-meaningful one
Replaces numeric constants with expressions
Replaces characters in strings with their hex escapes
So If we Obfuscate the Code , then if something goes wrong in production & how we can fix it ?
If we want to do modification how we can go around with it?
You fix the problem in the original code and then run it through the obfuscater again.
You do not debug with obfuscated code. You should turn off the obfuscation on development environments, since it is only needed for production.
Quentin has it right: don't throw away the original source, and then you can debug the problem there. (Likewise for "modifications" to the code).
A bit trickier is, how do you diagnose the problem, when it occurs while running the obfuscated version? I don't know how others do this. However, our tools provide an invertible mapping from the original source to the obfuscated version as an additional output from the obfuscation process. When a problem is found in the running code, if the obfuscated identifiers "nearby" the problem (e.g., in the offending statement/function/... or in a crash call backtrace) can be captured, the inverse map can be used to produce corresponding unobfuscated identifiers, which can then be used to locate the offending construct in the original source code.
While I of course agree with the above posters, they're kind of negating the question, not answering it.
Anyway, if you use Chrome, you can open the dev tools ( Right click anywhere>inspect element> sources tab). Find the obfuscated code on the file explorer on the left, then click the two curly braces on the bottom.
Once you do that, the variable names are still obfuscated, but at least it's formatted properly. This is extremely useful for when you're worried that the minification process itself is breaking something.
As many of us know, IE7 is not quite friendly with JavaScript code containing trailing commas, which can be a large problem for projects using modern JS framerworks and containing a lot of JS code.
In a pretty good article on the subject, the author mentions:
On the tools front, my preference for combating these devils is the Eclipse JavaScript Development Tools. The JavaScript source editor in JSDT flags trailing commas as errors: http://www.enterprisedojo.com/wp-content/uploads/2010/12/jsdtRules.png
However, using Eclipse Indigo with WTP/JSDT, I'm not seeing trailing commas as errors, and I can't find a proper setting to fix this.
How do I setup Eclipse to flag trailing commas in JavaScript as errors?
It looks like the fix for another bug involving erroneous syntax errors on the comma operator also removed the syntax error on trailing commas in initializers. That's technically correct; the standard says they're allowed and IE7 is just nonconformant. There's a feature request open asking that they be reinstated.
Slightly off topic, but you should also look into using JSLint to check the syntax of the JavaScript code. It will warn you about the trailing comma, but also about many other potential problems. There is a good plugin for Eclipse, http://marketplace.eclipse.org/content/phonegap-android-jslintjshint. The instructions for setting it up: http://www.mobiledevelopersolutions.com/home/announce-1/mds12released-nowwithjslintjshint
Make sure you're in the correct perspective (ie JavaScript as opposed to Java).
Also, I found in Helios that if I added a JS file to the project by right-clicking and adding a new 'File' (which I would then name with a .js extension) didn't make the UI pick up that it should be treated as a JS file--no syntax highlighting, checking, etc. If I added it specifically using the new JavaScript file option, it worked fine.
Context
I read a JavaScript code example written by Google. It used:
Single lowercase letters for naming variables
Single uppercase letters for naming functions
So the code was illegible.
Questions
Why this naming?
What tools are using to do this?
Often when large Javascript libraries are put into production the code is "minimized" in order to...
Decrease the download size
Make it more difficult to reverse engineer the code
I think the primary motivator is #1 however.
This process generally involves things like removing comments and whitespace and changing variable references to single characters.
For instance, take a look at JSMin.
Fewer letters means fewer bytes means faster downloads, which is Google's (stated) primary concern.
They probably use Closure Compiler but YUI Compressor is still popular.
That's JavaScript Obfuscation!
Some people do this to obfuscate, but many do it to minify because the fewer characters means that it is a smaller file to transmit.
You can use minification/compression tools and google even has one that is open source:
http://code.google.com/closure/compiler/
It serves two main purposes
reduced bandwidth, since Google serves so many pages
obfuscation
http://blogoscoped.com/archive/2008-02-08-n74.html
I'm trying to retrofit/fix lots of legacy web code and unfortunately most of it is poorly formatted JavaScript. I'm looking for a batch/scriptable utility that can fix JavaScript that is missing simicolons at the end of executable statements.
I've tried the beautify-cl.js script with Rhino but that does not does not add semicolons. In addition, I have tried JSTidy thinking I could modify it to be scriptable, but it strips all comments. Considering we have something like 2000-3000 files, any solution has to be scriptable.
The following topics were referenced, however none of the solutions were sufficient for various reasons:
Javascript Beautifier - Doesn't handle semicolon
Best source code formatter for Javascript? - Not scriptable
Any ideas/solutions? Thanks in advance.
I've found a winning combination in js-beautify and Google's Closure Linter:
# legacy.js is your poorly formatted JavaScript file, and will be modified in-place
js-beautify -s 2 -n -b end-expand -x -r legacy.js && fixjsstyle legacy.js
Explanation of js-beautify options:
-s 2: indent with two spaces
-n: ensure newline at end of file
-b end-expand: puts { braces at the end of the line, but always gives } braces their own line.
-x: unescape \xNN-escaped characters in strings
-r: make changes in-place
fixjsstyle, which is installed with the Closure Linter suite, makes changes in-place by default.
This pipeline retains comments (!), indents everything (mostly) how I like, adds semicolons where appropriate, and even changes double quotes to single quotes where feasible. Both commands can be given a list of files (e.g., **/*.js), instead of just one.
To install the required packages on Mac OS X:
npm install -g js-beautify
brew install closure-linter
Obviously you'll need to do this if you want to minify the files on deployment. Missing semicolons are probably the #1 reason JS files don't minify properly, so I understand your motivation.
Write a little Python (or whatever) script to run the file through jslint, then use the output from jslint to see which lines need semicolons, then spin through the js source and add them.
I think you can be fairly fearless here, because JavaScript implicitly adds the semicolons anyway.
Update: This set of tools may be what you are looking for. The "format" tab offers missing semicolon insertion.
If you use JavaScript Utlity V2 at http://jsutility.pjoneil.net and use the formatting function, it will automatically replace missing semicolons.
In addition, if you use the compaction function, it will also replace missing semicolons so that the compaction will not cause any errors.
You shouldn't be worried about doing a mass update on a lot of legacy code for the sole purpose of inserting semi colons. That's a classic case of "doing it wrong".
How would you test the results?
How would you ensure no "functionality" (as a side effect of a bug caused by a semi colon being missing) isn't lost?
What do you think adding semi colons to all these files will get you? Beside larger files (I'm not knocking the use of semicolons) and massive amounts of untested code changes?
As gumbo said, use jslint. I would use it on the files as you edit them in your day to day work. As you edit these files, presumably you will be testing changes to the file at that time. That would be the most ideal time to go crazy with semi colon insertion.
Also, if you're concerned about keeping 2000-3000 legacy javascript files alive and supported, you've got far bigger problems than semi colons
If http://jsutility.pjoneil.net is throwing too much errors (and be unable to format it), you may try to compress it with: http://refresh-sf.com/yui/ (which will add missing semicolons) and then go back to pjoneil.net formatter to obtain the pretty code with semicolons.
If you are using Visual Studio Code then Prettier Formatter is the way to go:
https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode
You simply install it and then on the keyboard shortcut to Format Document, the js file is reformatted but also any missing semicolons are automatically filled.
Enjoy!