Uglifying js code would prevent any meaningful reports from reaching us in the error reporting system since all function and variable names are useless and all the scripts are inlined. I am suggesting that we refrain from uglifing js code in production. Since bandwidth is now sufficiently large to handle pretty js code in production. It would give us access to a wealth of info to help us diagnose and reproduce error reports that may not be feasible with ugly js scripts.
what do you think?
On 06/16/2013 08:45 PM, Mohamed Ashraf wrote:
Uglifying js code would prevent any meaningful reports from reaching us in the error reporting system since all function and variable names are useless and all the scripts are inlined. I am suggesting that we refrain from uglifing js code in production. Since bandwidth is now sufficiently large to handle pretty js code in production. It would give us access to a wealth of info to help us diagnose and reproduce error reports that may not be feasible with ugly js scripts.
what do you think?
This could work. My suggestion would be to ship both minified and uncompressed versions of the scripts. And serving different version based on whether the error reporting is turned on or not.
Bye, Rouslan
Hi
Dne Sun, 16 Jun 2013 21:45:14 +0200 Mohamed Ashraf mohamed.ashraf.213@gmail.com napsal(a):
Uglifying js code would prevent any meaningful reports from reaching us in the error reporting system since all function and variable names are useless and all the scripts are inlined. I am suggesting that we refrain from uglifing js code in production. Since bandwidth is now sufficiently large to handle pretty js code in production. It would give us access to a wealth of info to help us diagnose and reproduce error reports that may not be feasible with ugly js scripts.
Indeed it's hard for error reports, but the size reduction is quite significant - one the main page we load 1.25 MiB of js, after minification it's only 630 kiB. And not everybody has fast bandwidth now...
On Tue, Jun 18, 2013 at 9:53 AM, Michal Čihař michal@cihar.com wrote:
Hi
Dne Sun, 16 Jun 2013 21:45:14 +0200 Mohamed Ashraf mohamed.ashraf.213@gmail.com napsal(a):
Uglifying js code would prevent any meaningful reports from reaching us in the error reporting system since all function and variable names are useless and all the scripts are inlined. I am suggesting that we refrain from uglifing js code in production. Since bandwidth is now sufficiently large to handle pretty js code in production. It would give us access to a wealth of info to help us diagnose and reproduce error reports that may not be feasible with ugly js scripts.
Indeed it's hard for error reports, but the size reduction is quite significant - one the main page we load 1.25 MiB of js, after minification it's only 630 kiB. And not everybody has fast bandwidth now...
A web server that is configured to support gzip would help alot more than minification anyway and provides a much smaller size whether the files are minified or not. Most web servers and web browsers already support gzip compression so it is not a problem. also the javascript files are already aggressively cached so it is not a big problem.
considering that with minified files you would get zero to no information on the source of a javascript error. I think it is a small price to pay for error reports; otherwise most error reports would be "ReferenceError: a is not defined in line 7" where line 7 is the entire jquery source minified. Having understandable error reports is worth paying a few extra KB. notice that not all scripts are fetched at once every page load thus it is at most a few KBs more per request is not much
I think this is the best course of action for proceeding with the collection of error reports since we are giving deployers the option of turning this feature off altogether and provide minified files to their users if it really came to that.
-- Michal Čihař | http://cihar.com | http://blog.cihar.com
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Hi
Dne Tue, 18 Jun 2013 12:01:22 +0200 Mohamed Ashraf mohamed.ashraf.213@gmail.com napsal(a):
A web server that is configured to support gzip would help alot more than minification anyway and provides a much smaller size whether the files are minified or not. Most web servers and web browsers already support gzip compression so it is not a problem. also the javascript files are already aggressively cached so it is not a big problem.
Indeed gzip can save transfer size, minified code has also benefits for parsing and execution time due to shorter identifiers. Or at least Google claims so:
https://developers.google.com/speed/docs/best-practices/payload#MinifyJS
considering that with minified files you would get zero to no information on the source of a javascript error. I think it is a small price to pay for error reports; otherwise most error reports would be "ReferenceError: a is not defined in line 7" where line 7 is the entire jquery source minified. Having understandable error reports is worth paying a few extra KB. notice that not all scripts are fetched at once every page load thus it is at most a few KBs more per request is not much
I think this is the best course of action for proceeding with the collection of error reports since we are giving deployers the option of turning this feature off altogether and provide minified files to their users if it really came to that.
That's option as well, though it increases size of our package...
On Tue, Jun 18, 2013 at 3:44 PM, Michal Čihař michal@cihar.com wrote:
Hi
Dne Tue, 18 Jun 2013 12:01:22 +0200 Mohamed Ashraf mohamed.ashraf.213@gmail.com napsal(a):
A web server that is configured to support gzip would help alot more than minification anyway and provides a much smaller size whether the files are minified or not. Most web servers and web browsers already support gzip compression so it is not a problem. also the javascript files are already aggressively cached so it is not a big problem.
Indeed gzip can save transfer size, minified code has also benefits for parsing and execution time due to shorter identifiers. Or at least Google claims so:
https://developers.google.com/speed/docs/best-practices/payload#MinifyJS
I just did a small test to see how much does minifying and/or gzipping affects file size. I chose to use the list of scripts requested in the main page as a reference for a large number of scripts downloaded at the same time to maximize the differences. original js 1.4M minified js 629K gzipped original 331K gzipped minified 181K
when using gzip the difference of 150K is negligible since this is only downloaded once in every session and every other request only gets one or two extra js files since your ajax script takes care of that caching. an extra 150K for the first page download is not too much to ask since it is more than likely to be cached by the browser itself. for normal page accesses only one or two extra scripts are requested. here is the same breakdown for a single js file. I chose server_database.js arbitrarily original js 4.3K minified js 1.8K gzipped original 1.4K gzipped minified 811B
the difference between the gzipped original and minified is just 600B. that is not much.
considering that with minified files you would get zero to no information on the source of a javascript error. I think it is a small price to pay for error reports; otherwise most error reports would be "ReferenceError: a is not defined in line 7" where line 7 is the entire jquery source minified. Having understandable error reports is worth paying a few extra KB. notice that not all scripts are fetched at once every page load thus it is at most a few KBs more per request is not much
I think this is the best course of action for proceeding with the collection of error reports since we are giving deployers the option of turning this feature off altogether and provide minified files to their users if it really came to that.
That's option as well, though it increases size of our package...
since the package is gzipped it is not that big of an increase also the package is usually just a one time download so a small increase in size is not muxh
-- Michal Čihař | http://cihar.com | http://blog.cihar.com
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
2013/6/19 Mohamed Ashraf mohamed.ashraf.213@gmail.com:
On Tue, Jun 18, 2013 at 3:44 PM, Michal Čihař michal@cihar.com wrote:
Hi
Dne Tue, 18 Jun 2013 12:01:22 +0200 Mohamed Ashraf mohamed.ashraf.213@gmail.com napsal(a):
A web server that is configured to support gzip would help alot more than minification anyway and provides a much smaller size whether the files are minified or not. Most web servers and web browsers already support gzip compression so it is not a problem. also the javascript files are already aggressively cached so it is not a big problem.
Indeed gzip can save transfer size, minified code has also benefits for parsing and execution time due to shorter identifiers. Or at least Google claims so:
https://developers.google.com/speed/docs/best-practices/payload#MinifyJS
I just did a small test to see how much does minifying and/or gzipping affects file size. I chose to use the list of scripts requested in the main page as a reference for a large number of scripts downloaded at the same time to maximize the differences. original js 1.4M minified js 629K gzipped original 331K gzipped minified 181K
when using gzip the difference of 150K is negligible since this is only downloaded once in every session and every other request only gets one or two extra js files since your ajax script takes care of that caching. an extra 150K for the first page download is not too much to ask since it is more than likely to be cached by the browser itself. for normal page accesses only one or two extra scripts are requested. here is the same breakdown for a single js file. I chose server_database.js arbitrarily original js 4.3K minified js 1.8K gzipped original 1.4K gzipped minified 811B
the difference between the gzipped original and minified is just 600B. that is not much.
This seems reasonable to me.
I'd suggest to drop the js minification to being able to get a stack trace for the error reporting. Thanks for investigating, Mohamed.
considering that with minified files you would get zero to no information on the source of a javascript error. I think it is a small price to pay for error reports; otherwise most error reports would be "ReferenceError: a is not defined in line 7" where line 7 is the entire jquery source minified. Having understandable error reports is worth paying a few extra KB. notice that not all scripts are fetched at once every page load thus it is at most a few KBs more per request is not much
I think this is the best course of action for proceeding with the collection of error reports since we are giving deployers the option of turning this feature off altogether and provide minified files to their users if it really came to that.
That's option as well, though it increases size of our package...
since the package is gzipped it is not that big of an increase also the package is usually just a one time download so a small increase in size is not muxh
-- Michal Čihař | http://cihar.com | http://blog.cihar.com
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
-- Kind regards,
Dieter Adriaenssens
On 06/19/2013 08:49 AM, Dieter Adriaenssens wrote:
2013/6/19 Mohamed Ashraf mohamed.ashraf.213@gmail.com:
On Tue, Jun 18, 2013 at 3:44 PM, Michal Čihař michal@cihar.com wrote:
Hi
Dne Tue, 18 Jun 2013 12:01:22 +0200 Mohamed Ashraf mohamed.ashraf.213@gmail.com napsal(a):
A web server that is configured to support gzip would help alot more than minification anyway and provides a much smaller size whether the files are minified or not. Most web servers and web browsers already support gzip compression so it is not a problem. also the javascript files are already aggressively cached so it is not a big problem.
Indeed gzip can save transfer size, minified code has also benefits for parsing and execution time due to shorter identifiers. Or at least Google claims so:
https://developers.google.com/speed/docs/best-practices/payload#MinifyJS
I just did a small test to see how much does minifying and/or gzipping affects file size. I chose to use the list of scripts requested in the main page as a reference for a large number of scripts downloaded at the same time to maximize the differences. original js 1.4M minified js 629K gzipped original 331K gzipped minified 181K
when using gzip the difference of 150K is negligible since this is only downloaded once in every session and every other request only gets one or two extra js files since your ajax script takes care of that caching. an extra 150K for the first page download is not too much to ask since it is more than likely to be cached by the browser itself. for normal page accesses only one or two extra scripts are requested. here is the same breakdown for a single js file. I chose server_database.js arbitrarily original js 4.3K minified js 1.8K gzipped original 1.4K gzipped minified 811B
the difference between the gzipped original and minified is just 600B. that is not much.
This seems reasonable to me.
I'd suggest to drop the js minification to being able to get a stack trace for the error reporting. Thanks for investigating, Mohamed.
Thought I'd mention that third party libraries (jquery, jquery plugins, etc) can stay minified IMO. All we really care to debug is our code. Besides, the public API of any external library will remain unmangled.
considering that with minified files you would get zero to no information on the source of a javascript error. I think it is a small price to pay for error reports; otherwise most error reports would be "ReferenceError: a is not defined in line 7" where line 7 is the entire jquery source minified. Having understandable error reports is worth paying a few extra KB. notice that not all scripts are fetched at once every page load thus it is at most a few KBs more per request is not much
I think this is the best course of action for proceeding with the collection of error reports since we are giving deployers the option of turning this feature off altogether and provide minified files to their users if it really came to that.
That's option as well, though it increases size of our package...
since the package is gzipped it is not that big of an increase also the package is usually just a one time download so a small increase in size is not muxh
2013/6/19 Rouslan Placella rouslan@placella.com:
On 06/19/2013 08:49 AM, Dieter Adriaenssens wrote:
2013/6/19 Mohamed Ashraf mohamed.ashraf.213@gmail.com:
On Tue, Jun 18, 2013 at 3:44 PM, Michal Čihař michal@cihar.com wrote:
Hi
Dne Tue, 18 Jun 2013 12:01:22 +0200 Mohamed Ashraf mohamed.ashraf.213@gmail.com napsal(a):
A web server that is configured to support gzip would help alot more than minification anyway and provides a much smaller size whether the files are minified or not. Most web servers and web browsers already support gzip compression so it is not a problem. also the javascript files are already aggressively cached so it is not a big problem.
Indeed gzip can save transfer size, minified code has also benefits for parsing and execution time due to shorter identifiers. Or at least Google claims so:
https://developers.google.com/speed/docs/best-practices/payload#MinifyJS
I just did a small test to see how much does minifying and/or gzipping affects file size. I chose to use the list of scripts requested in the main page as a reference for a large number of scripts downloaded at the same time to maximize the differences. original js 1.4M minified js 629K gzipped original 331K gzipped minified 181K
when using gzip the difference of 150K is negligible since this is only downloaded once in every session and every other request only gets one or two extra js files since your ajax script takes care of that caching. an extra 150K for the first page download is not too much to ask since it is more than likely to be cached by the browser itself. for normal page accesses only one or two extra scripts are requested. here is the same breakdown for a single js file. I chose server_database.js arbitrarily original js 4.3K minified js 1.8K gzipped original 1.4K gzipped minified 811B
the difference between the gzipped original and minified is just 600B. that is not much.
This seems reasonable to me.
I'd suggest to drop the js minification to being able to get a stack trace for the error reporting. Thanks for investigating, Mohamed.
Thought I'd mention that third party libraries (jquery, jquery plugins, etc) can stay minified IMO. All we really care to debug is our code. Besides, the public API of any external library will remain unmangled.
I agree, it doesn't make sense to show a stack trace of where it goes wrong in those libraries. If there would be a bug there it can be found by a developer who investigates an error report.
Mohamed, can you take a look at the release script and modify it so that our JS files are no longer minified?
-- Kind regards,
Dieter Adriaenssens
Hi
Dne Thu, 20 Jun 2013 11:01:30 +0200 Dieter Adriaenssens dieter.adriaenssens@gmail.com napsal(a):
2013/6/19 Rouslan Placella rouslan@placella.com:
Thought I'd mention that third party libraries (jquery, jquery plugins, etc) can stay minified IMO. All we really care to debug is our code. Besides, the public API of any external library will remain unmangled.
I agree, it doesn't make sense to show a stack trace of where it goes wrong in those libraries. If there would be a bug there it can be found by a developer who investigates an error report.
Mohamed, can you take a look at the release script and modify it so that our JS files are no longer minified?
Maybe we can simply include minified jQuery and jQuery-UI in git and do no minification on release time? These are anyway the big libraries and we don't want to touch their code anyway...
2013/6/20 Michal Čihař michal@cihar.com:
Hi
Dne Thu, 20 Jun 2013 11:01:30 +0200 Dieter Adriaenssens dieter.adriaenssens@gmail.com napsal(a):
2013/6/19 Rouslan Placella rouslan@placella.com:
Thought I'd mention that third party libraries (jquery, jquery plugins, etc) can stay minified IMO. All we really care to debug is our code. Besides, the public API of any external library will remain unmangled.
I agree, it doesn't make sense to show a stack trace of where it goes wrong in those libraries. If there would be a bug there it can be found by a developer who investigates an error report.
Mohamed, can you take a look at the release script and modify it so that our JS files are no longer minified?
Maybe we can simply include minified jQuery and jQuery-UI in git and do no minification on release time? These are anyway the big libraries and we don't want to touch their code anyway...
Good idea!
-- Kind regards,
Dieter Adriaenssens
On Thu, Jun 20, 2013 at 11:32 AM, Dieter Adriaenssens dieter.adriaenssens@gmail.com wrote:
2013/6/20 Michal Čihař michal@cihar.com:
Hi
Dne Thu, 20 Jun 2013 11:01:30 +0200 Dieter Adriaenssens dieter.adriaenssens@gmail.com napsal(a):
2013/6/19 Rouslan Placella rouslan@placella.com:
Thought I'd mention that third party libraries (jquery, jquery plugins, etc) can stay minified IMO. All we really care to debug is our code. Besides, the public API of any external library will remain unmangled.
I agree, it doesn't make sense to show a stack trace of where it goes wrong in those libraries. If there would be a bug there it can be found by a developer who investigates an error report.
Mohamed, can you take a look at the release script and modify it so that our JS files are no longer minified?
The script that compresses files keeps originals in a sources directory. The release script deletes this folder. I will just remove the line that deletes this folder. I will then change the get_script.php file to get the js files from the sources directory if it exists and the error reporting setting is active. otherwise it will load the minified version.
Maybe we can simply include minified jQuery and jQuery-UI in git and do no minification on release time? These are anyway the big libraries and we don't want to touch their code anyway...
Good idea!
-- Kind regards,
Dieter Adriaenssens
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Hi
Dne Thu, 20 Jun 2013 11:32:02 +0200 Dieter Adriaenssens dieter.adriaenssens@gmail.com napsal(a):
2013/6/20 Michal Čihař michal@cihar.com:
Hi
Dne Thu, 20 Jun 2013 11:01:30 +0200 Dieter Adriaenssens dieter.adriaenssens@gmail.com napsal(a):
2013/6/19 Rouslan Placella rouslan@placella.com:
Thought I'd mention that third party libraries (jquery, jquery plugins, etc) can stay minified IMO. All we really care to debug is our code. Besides, the public API of any external library will remain unmangled.
I agree, it doesn't make sense to show a stack trace of where it goes wrong in those libraries. If there would be a bug there it can be found by a developer who investigates an error report.
Mohamed, can you take a look at the release script and modify it so that our JS files are no longer minified?
Maybe we can simply include minified jQuery and jQuery-UI in git and do no minification on release time? These are anyway the big libraries and we don't want to touch their code anyway...
Good idea!
Done in master and also removed the release time compression in master.
-
Dieter Adriaenssens -
Michal Čihař -
Mohamed Ashraf -
Rouslan Placella