Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #26222 > unrolled thread

JavaScript Packers, Compression & Decompression

Back to article view | Back to comp.lang.javascript

Contents

  JavaScript Packers, Compression & Decompression Chris White <0ntariokingston@gmail.com> - 2014-11-27 03:34 -0800
    Re: JavaScript Packers, Compression & Decompression "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-27 13:46 +0100
    Re: JavaScript Packers, Compression & Decompression Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-27 15:26 +0100
    Re: JavaScript Packers, Compression & Decompression Chris White <0ntariokingston@gmail.com> - 2014-11-28 06:16 -0800
    Re: JavaScript Packers, Compression & Decompression Chris White <0ntariokingston@gmail.com> - 2014-11-28 06:17 -0800
    Re: JavaScript Packers, Compression & Decompression Chris White <0ntariokingston@gmail.com> - 2014-11-28 06:27 -0800
      Re: JavaScript Packers, Compression & Decompression "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-28 15:43 +0100
      Re: JavaScript Packers, Compression & Decompression Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-28 16:16 +0100
        Re: JavaScript Packers, Compression & Decompression Chris White <0ntariokingston@gmail.com> - 2014-11-28 07:21 -0800
          Re: JavaScript Packers, Compression & Decompression Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-28 17:04 +0100
            Re: JavaScript Packers, Compression & Decompression "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-28 18:26 +0100
    Re: JavaScript Packers, Compression & Decompression Chris White <0ntariokingston@gmail.com> - 2014-11-28 08:20 -0800
      Re: JavaScript Packers, Compression & Decompression Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-28 17:57 +0100
        Re: JavaScript Packers, Compression & Decompression Chris White <0ntariokingston@gmail.com> - 2014-11-28 10:10 -0800
      Re: JavaScript Packers, Compression & Decompression danca <cyberdanny@tiscalinet.it> - 2014-11-28 22:31 +0100
        Re: JavaScript Packers, Compression & Decompression Chris White <0ntariokingston@gmail.com> - 2014-11-28 15:01 -0800
        Re: JavaScript Packers, Compression & Decompression Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-29 14:48 +0100
          Re: JavaScript Packers, Compression & Decompression Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-29 15:05 +0100
            [OT] Re: JavaScript Packers, Compression & Decompression danca <cyberdanny@tiscalinet.it> - 2014-12-01 18:44 +0100
    Re: JavaScript Packers, Compression & Decompression Denis McMahon <denismfmcmahon@gmail.com> - 2014-11-29 06:46 +0000
    Re: JavaScript Packers, Compression & Decompression Chris White <0ntariokingston@gmail.com> - 2014-11-30 18:41 -0800
      Re: JavaScript Packers, Compression & Decompression "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-11-30 20:38 -0800
      Re: JavaScript Packers, Compression & Decompression Denis McMahon <denismfmcmahon@gmail.com> - 2014-12-01 16:28 +0000
    Re: JavaScript Packers, Compression & Decompression Chris White <0ntariokingston@gmail.com> - 2014-11-30 18:41 -0800
    Re: JavaScript Packers, Compression & Decompression Chris White <0ntariokingston@gmail.com> - 2014-12-15 15:54 -0800

Page 2 of 2 — ← Prev page 1 [2]

#26260

It is too bad that JavaScript cannot provide the most popular compression formats so I can embed compressed data like a dataURi and extract it without me having to provide software.

Would be nice say if I could zip as easy as they allow inflating (Base64).

[toc] | [prev] | [next] | [standalone]

#26262

On Sunday, November 30, 2014 8:41:09 PM UTC-6, Chris White wrote:
> It is too bad that JavaScript cannot provide the most popular compression formats so I can embed compressed data like a dataURi and extract it without me having to provide software.
> 
> Would be nice say if I could zip as easy as they allow inflating (Base64).

Did you look at any of the work that has been done on this yet? For example:

<http://www.2ality.com/2010/12/crazy-javascript-hack-unzipping-file.html>

Of course much has changed in browser functionality since 2010...

[toc] | [prev] | [next] | [standalone]

#26266

On Sun, 30 Nov 2014 18:41:04 -0800, Chris White wrote:

> It is too bad that JavaScript cannot provide the most popular
> compression formats so I can embed compressed data like a dataURi and
> extract it without me having to provide software.

Why? What is the benefit to just compressing a url over the benefit of 
compressing the whole text content of the html file / js file / css file 
etc. And if you're compressing the whole file, it's dumb to use a script 
engine to decompress when the browser already has the capability.

I still don't understand what your real life use case for this feature is.

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#26261

On Thursday, November 27, 2014 6:34:10 AM UTC-5, Chris White wrote:
> www.ScriptCompress.com is trying to provide compression to JavaScript because not all servers have compression. It is not only responsibility of the web server to compress, think about it. Why not client side compression so I can send form data back to server compressed (just one of thousands of examples)?
> 
> If you pack a JavaScript, it may not compress as well with Gzip, here we need an alternative like bzip. Get with the program JavaScript!
> 
> *Why does JavaScript not support decompression of top formats?* It is time to make a proper language that has all good compression formats built in (lpaq, lzma, lz77, bzip, Gzip, zip, rar, lha, etc, etc, etc). It is standard need on a computer, and the internet is run by computers, so only seems logical.
> 
> Developers need to be able to find a match for their needs. One compression may work well on say text, but another works better on binary data (like run length encoding algorithm I came up works well on a bunch of zeros and ones, but on a javascript it inflated many times over). I have found mixing a few together in certain combinations results in more savings than any used alone.
> 
> Can't tell me it's not possible, file type svgz can open natively on most browsers and it is just a svg that is gzipped! Why not htmlz, jpgz, cssz, etc? Here is sample of HTML hacked to SVGZ: http://imgh.us/1MB-HTML5-Holy-Bible.svgz (this was a huge task making the Bible this small, takes a bit to extract and load because I had to combine so many techniques to compensate for bloating of Base64), it's the World's smallest fully complete HTML5 Bible that was originally 4.5MB but now 1MB (if browsers supported compression I could have skipped base64 and got down to 900KB plus less time decoding base64 about 2 times). I had to pack it to JavaScript (scriptcompress.com makes self extracting search/replace compressed script mixed with bzip), compress bzip, encode Base64, minify, convert to SVG foreignObject tag (inject to iframe) and final stage was gzip I left raw compressed data.
> 
> *Why doesn't JavaScript have built in decompression for all the top formats?* 
> 
> Compression is not just responsibility of the server side hosting. I myself use many paid services or free services that do not compress. Why can't I use compressed files on them? Because web browsers won't do their part! Look at all the trouble I have to go through to host a gzipped webpage on a server without compression: first I use HTML packer on scriptcompress.com to make it complete javascript, now I bzip with tools on same site, then convert to SVG image and then gzip it  https://plus.google.com/108316513308693963076/posts/SrLwZahWgyE - GRRRRRR!
> 
> I should be able to say have an HTML page zipped up. So we have index.html that is now index.html.zip. The browser should now see they expect a name of index and extension html, so browser would know that to unzip what internal function it needs, then extract the page then view it. SO SIMPLE!
> 
> index.html.gz = gzipped index.htm
> index.html.bz =bzip
> logo.png.gz = an image gzipped
> 
> The browser would first extract all related files in same recursive directories, then your pages can now call say logo.png instead og logo.png.gz. By first extracting everything, you could now call other files that were packed in say index.html.gz (maybe you added css or js files for instance), basically the name is just a place for the extractor to start when executing something
> 
> If browser told to open index.html.gz it would extract with gzip and run index.html so if you had css and js files to go with the page without a URL linking to external resources, you would either have to embed code with base64 and dataURLs or just simply include the files inside index.html.gz without any (file renaming)
> 
> The browser should check again for compressed files incase some compressed files were compressed before compression.
> 
> Search engines (like Google) are going to have to start decompressing files to get meta data. All my attempts of self extracting web pages fail because people complain that all stuff is now hidden from search engines! Would be nice if a JavaScript contained eval a search engine would actually run it to get data as I find great technique to pack HTML in doc write and then compress into self unpacking scripts. Actually, would be nice if web browser just took pure compressed files to save me that trouble of packing! 
> 
> I could take Chrome source and probably make it the way it should be, but would take me forever by myself and I cannot afford to donate that much time (I would have to still earn money elsewhere and sleep). Even if I spent a year doing it, it can't be copyrighted and all the other browsers will copy after I show that an extra MB of data is all it took to save terrabytes a day... Yes, 1MB, I have almost 50 various JavaScript compressors/decompressors in testing phases (LZMA to PAQ), and codes are less than 1MB total (heavily minified), about 10 of these (lha, lzrc, sppmc, p12a, lzp, lzari, ppmhuff, lzb, dmc, mnzip, fgk, etc) I get over 50% compression and will be integrated to scriptcompress.com eventually. That 50% compress rate is after Base64 encoding (such a waste, lose 30%, but browser forces me to make it safe).

www.ScriptCompress.com is trying to provide compression to JavaScript because not all servers have compression. It is not only responsibility of the web server to compress, think about it. Why not client side compression so I can send form data back to server compressed (just one of thousands of examples)? 

If you pack a JavaScript, it may not compress as well with Gzip, here we need an alternative like bzip. Get with the program JavaScript! 

*Why does JavaScript not support decompression of top formats?* It is time to make a proper language that has all good compression formats built in (lpaq, lzma, lz77, bzip, Gzip, zip, rar, lha, etc, etc, etc). It is standard need on a computer, and the internet is run by computers, so only seems logical. 

Developers need to be able to find a match for their needs. One compression may work well on say text, but another works better on binary data (like run length encoding algorithm I came up works well on a bunch of zeros and ones, but on a javascript it inflated many times over). I have found mixing a few together in certain combinations results in more savings than any used alone. 

Can't tell me it's not possible, file type svgz can open natively on most browsers and it is just a svg that is gzipped! Why not htmlz, jpgz, cssz, etc? Here is sample of HTML hacked to SVGZ: http://imgh.us/1MB-HTML5-Holy-Bible.svgz (this was a huge task making the Bible this small, takes a bit to extract and load because I had to combine so many techniques to compensate for bloating of Base64), it's the World's smallest fully complete HTML5 Bible that was originally 4.5MB but now 1MB (if browsers supported compression I could have skipped base64 and got down to 900KB plus less time decoding base64 about 2 times). I had to pack it to JavaScript (scriptcompress.com makes self extracting search/replace compressed script mixed with bzip), compress bzip, encode Base64, minify, convert to SVG foreignObject tag (inject to iframe) and final stage was gzip I left raw compressed data. 

*Why doesn't JavaScript have built in decompression for all the top formats?* 

Compression is not just responsibility of the server side hosting. I myself use many paid services or free services that do not compress. Why can't I use compressed files on them? Because web browsers won't do their part! Look at all the trouble I have to go through to host a gzipped webpage on a server without compression: first I use HTML packer on scriptcompress.com to make it complete javascript, now I bzip with tools on same site, then convert to SVG image and then gzip it  https://plus.google.com/108316513308693963076/posts/SrLwZahWgyE - GRRRRRR! 

I should be able to say have an HTML page zipped up. So we have index.html that is now index.html.zip. The browser should now see they expect a name of index and extension html, so browser would know that to unzip what internal function it needs, then extract the page then view it. SO SIMPLE! 

index.html.gz = gzipped index.htm 
index.html.bz =bzip 
logo.png.gz = an image gzipped 

The browser would first extract all related files in same recursive directories, then your pages can now call say logo.png instead og logo.png.gz. By first extracting everything, you could now call other files that were packed in say index.html.gz (maybe you added css or js files for instance), basically the name is just a place for the extractor to start when executing something 

If browser told to open index.html.gz it would extract with gzip and run index.html so if you had css and js files to go with the page without a URL linking to external resources, you would either have to embed code with base64 and dataURLs or just simply include the files inside index.html.gz without any (file renaming) 

The browser should check again for compressed files incase some compressed files were compressed before compression. 

Search engines (like Google) are going to have to start decompressing files to get meta data. All my attempts of self extracting web pages fail because people complain that all stuff is now hidden from search engines! Would be nice if a JavaScript contained eval a search engine would actually run it to get data as I find great technique to pack HTML in doc write and then compress into self unpacking scripts. Actually, would be nice if web browser just took pure compressed files to save me that trouble of packing! 

I could take Chrome source and probably make it the way it should be, but would take me forever by myself and I cannot afford to donate that much time (I would have to still earn money elsewhere and sleep). Even if I spent a year doing it, it can't be copyrighted and all the other browsers will copy after I show that an extra MB of data is all it took to save terrabytes a day... Yes, 1MB, I have almost 50 various JavaScript compressors/decompressors in testing phases (LZMA to PAQ), and codes are less than 1MB total (heavily minified), about 10 of these (lha, lzrc, sppmc, p12a, lzp, lzari, ppmhuff, lzb, dmc, mnzip, fgk, etc) I get over 50% compression and will be integrated to scriptcompress.com eventually. That 50% compress rate is after Base64 encoding (such a waste, lose 30%, but browser forces me to make it safe).

[toc] | [prev] | [next] | [standalone]

#26331

Some updates:

HTML to JavaScript encoder/packer:
http://www.scriptcompress.com/HTML-JavaScript-Packer.htm

TEXT to JavaScript converter/packer:
http://www.scriptcompress.com/Text-To-JavaScript.htm

JavaScript compressor:
http://www.scriptcompress.com/JavaScript-Compressor.htm

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.javascript

csiph-web