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 1 of 2  [1] 2  Next page →

#26222 — JavaScript Packers, Compression & Decompression

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] | [next] | [standalone]

#26223

Chris White wrote:

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

Because it is not the job of JavaScript to decompress anything
transmitted via HTTP -- it is generally the client's job, see RFC 2616
section 3.5[1] (resp. the newer RFCs obsoliting RFC 2616).  If you want
better/other content-codings, you can propose them -- but this is OT in
this newsgroup, anyway.

> All my attempts of self extracting web pages fail because people 
> complain that all stuff is now hidden from search engines!

Not only from search engines, but from all clients that don't support
the required scripting language.  Note that the HTML5 specification says[2]:

| Authors are also encouraged to make their applications degrade
| gracefully in the absence of scripting support.

[1] <http://tools.ietf.org/html/rfc2616#section-3.5>
[2] <http://www.w3.org/TR/html5/scripting-1.html#scripting-1>

-- 
Christoph M. Becker

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

#26224

Chris White wrote:

> [spam.Spam.spam.example] is trying to provide compression to JavaScript
> because not all servers have compression.

Name one and give a use-case for its exclusive use.

> It is not only responsibility of the web server to compress,
> think about it.

BTDT.

> Why not client side compression so I can send form data back to server 
> compressed (just one of thousands of examples)?

Because the code to do that needs to be transported to the client first as 
it is executed there.

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

I do not see a use-case where you would send script code to the server other 
than uploading script files.  All user input must be treated as untrusted.

> Get with the program JavaScript!

This sentence does not make sense.
 
> *Why does JavaScript not support decompression of top formats?*

With regard to client-side/unprivileged JavaScript: The right tool for the 
right job.  With regard to client-side privileged/server-side/CLI JavaScript 
you are simply wrong.

> 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).

To what end?  And why should JavaScript (whatever you think that is) be the 
exception there?  There is no native support for compression in other 
programming languages either.  In PHP, for example, this is facilitated with 
an *extension*.

> It is standard need on a computer,

No, it is not.  Besides, there are compression programs that do the job just 
fine, and using gzip can actually increase the footprint if the original is 
small.

> and the internet is run by computers, so only seems logical.

Your logic is flawed.
 
> Developers need to be able to find a match for their needs.

If there was a need, do you not think that someone before you would have 
addressed it?  And it turns out that people have.  Why do you not use Google 
as a search engine for a change?

> One compression may work well on say text, but another works better on
> binary data (like run length encoding algorithm I came up

Oh, *you* came up with that?  It seems your hubris knows no end.

> [tl;dr]

This is not the diary for your “How To Learn JavaScript in 30 Days” course.  
Please go away or get a minimum clue.  TIA.

BTW: _tera_

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#26234

The web browser should handle all compression formats too.

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

#26235

Apparently it is no bodies job, just mine, LOL. Your answers are perfect to show how no one takes on responsibility

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

#26236

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).

So again I ask why can't JavaScript offer compression formats. "It's not JavaScript's job" is not sufficient for me, it's everyone's job! Pointing out how stupid I am (pointed ear troll), doesn't really answer it either. It would be nice to have it built in to JavaScript and also built into all browsers, that way all traffic (to and from browser) could be compressed at all times.

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

#26237

Chris White wrote:

> So again I ask why can't JavaScript offer compression formats. "It's
> not JavaScript's job" is not sufficient for me, it's everyone's job!
> Pointing out how stupid I am (pointed ear troll), doesn't really
> answer it either. It would be nice to have it built in to JavaScript
> and also built into all browsers, that way all traffic (to and from
> browser) could be compressed at all times.

JavaScript is not necessarily implemented (or enabled) in an HTTP client
(there is no such requirement).  Therefore it makes no sense to push the
responsibility of decompression to JavaScript.

-- 
Christoph M. Becker

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

#26238

Chris White wrote:

> So again I ask why can't JavaScript offer compression formats. "It's not
> JavaScript's job" is not sufficient for me, it's everyone's job! Pointing
> out how stupid I am

Nobody has said that you are stupid.  Instead, it has been pointed out to 
you (no pun intended) that you are much too inexperienced for statements of 
such boldness.

However, the way you are *acting* here certainly could be labeled “stupid”.  
For example, you have been told before how to post properly here, that is, 
in an easily readable manner (irrespective of the content).  You keep 
ignoring that advice.  You have been recommended to get yourself informed 
before you post, for example by way of reading the FAQ (one version of which 
I maintain with the support of some other regulars, BTW).  You keep ignoring 
that advice as well.  So you should not be surprised if, for the most part, 
you are ignored, too.

> (pointed ear troll),

Do you think insulting people is going to effect their help?  Maybe you are 
the troll after all.  You would not be the first one who misused the freedom 
at Google Groups for trolling.  Please prove me wrong.

> doesn't really answer it either.

I would seem that you are not ready for the answer yet as answers have been 
given but you are refusing to consider them, let alone to read them 
carefully.

> It would be nice to have it built in to JavaScript and also built into all
> browsers, that way all traffic (to and from browser) could be compressed
> at all times.

See Christoph’s answer.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#26239

On Friday, November 28, 2014 10:16:47 AM UTC-5, Thomas 'PointedEars' Lahn wrote:
> Chris White wrote:
> 
> > So again I ask why can't JavaScript offer compression formats. "It's not
> > JavaScript's job" is not sufficient for me, it's everyone's job! Pointing
> > out how stupid I am
> 
> Nobody has said that you are stupid.  Instead, it has been pointed out to 
> you (no pun intended) that you are much too inexperienced for statements of 
> such boldness.
> 
> However, the way you are *acting* here certainly could be labeled "stupid".  
> For example, you have been told before how to post properly here, that is, 
> in an easily readable manner (irrespective of the content).  You keep 
> ignoring that advice.  You have been recommended to get yourself informed 
> before you post, for example by way of reading the FAQ (one version of which 
> I maintain with the support of some other regulars, BTW).  You keep ignoring 
> that advice as well.  So you should not be surprised if, for the most part, 
> you are ignored, too.
> 
> > (pointed ear troll),
> 
> Do you think insulting people is going to effect their help?  Maybe you are 
> the troll after all.  You would not be the first one who misused the freedom 
> at Google Groups for trolling.  Please prove me wrong.
> 
> > doesn't really answer it either.
> 
> I would seem that you are not ready for the answer yet as answers have been 
> given but you are refusing to consider them, let alone to read them 
> carefully.
> 
> > It would be nice to have it built in to JavaScript and also built into all
> > browsers, that way all traffic (to and from browser) could be compressed
> > at all times.
> 
> See Christoph's answer.
> 
> -- 
> PointedEars
> FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
> Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
> Please do not cc me. / Bitte keine Kopien per E-Mail.

Thanks, yet again your reply is so helpful.

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

#26240

Chris White wrote:

> […] Thomas 'PointedEars' Lahn wrote:
>> Chris White wrote:
>> […]
>> > It would be nice to have it built in to JavaScript and also built into
>> > all browsers, that way all traffic (to and from browser) could be
>> > compressed at all times.
>> 
>> See Christoph's answer.
> 
> Thanks, yet again your reply is so helpful.

It was, but again you have ignored the good advice you have been given.  
*All* of it.  Therefore, it becomes increasingly unlikely that advice will 
be given to you again.

That aside: Which part of “JavaScript is not tied to HTTP” did you not 
understand?

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#26243

Thomas 'PointedEars' Lahn wrote:

> Chris White wrote:
> 
>> […] Thomas 'PointedEars' Lahn wrote:
>>> Chris White wrote:
>>> […]
>>>> It would be nice to have it built in to JavaScript and also built into
>>>> all browsers, that way all traffic (to and from browser) could be
>>>> compressed at all times.
>>>
>>> See Christoph's answer.
>>
>> Thanks, yet again your reply is so helpful.
> 
> It was, but again you have ignored the good advice you have been given.  
> *All* of it.  Therefore, it becomes increasingly unlikely that advice will 
> be given to you again.
> 
> That aside: Which part of “JavaScript is not tied to HTTP” did you not 
> understand?

I'm afraid, it is the whole part between the opening and the closing
quotation mark.

-- 
Christoph M. Becker

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

#26241

I think JavaScript should include nice simple functions for compression. Like bzip, lzma, rar, lha, gzip,  and all the other popular compression formats. There are nice functions to inflate file size (btoa for base64 encoding, call atob to decode), why not something that deflates sizes?

I also think HTML5 should have full compression & decompression built in too. This day and age, I think it should be standard.

There is nothing or no one on this planet that can change my mind.

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

#26242

Chris White wrote:

> I think JavaScript should include nice simple functions for compression.
> Like bzip, lzma, rar, lha, gzip,  and all the other popular compression
> formats. There are nice functions to inflate file size (btoa for base64
> encoding, call atob to decode), why not something that deflates sizes?
> 
> I also think HTML5 should have full compression & decompression built in
> too. This day and age, I think it should be standard.
> 
> There is nothing or no one on this planet that can change my mind.

I hate to break this to you, but then you are off-topic here.  This is a 
place for discussion, for the exchange of opinions in (hopefully) 
constructive arguments.  Not your blog.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#26244

On Friday, November 28, 2014 11:57:18 AM UTC-5, Thomas 'PointedEars' Lahn wrote:
> Chris White wrote:
> 
> > I think JavaScript should include nice simple functions for compression.
> > Like bzip, lzma, rar, lha, gzip,  and all the other popular compression
> > formats. There are nice functions to inflate file size (btoa for base64
> > encoding, call atob to decode), why not something that deflates sizes?
> > 
> > I also think HTML5 should have full compression & decompression built in
> > too. This day and age, I think it should be standard.
> > 
> > There is nothing or no one on this planet that can change my mind.
> 
> I hate to break this to you, but then you are off-topic here.  This is a 
> place for discussion, for the exchange of opinions in (hopefully) 
> constructive arguments.  Not your blog.
> 
> -- 
> PointedEars
> FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
> Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
> Please do not cc me. / Bitte keine Kopien per E-Mail.

Very good input, thanks.

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

#26245

Il 28/11/2014 17:20, Chris White ha scritto:
> I think JavaScript should include nice simple functions for compression. Like bzip, lzma, rar, lha, gzip,  and all the other popular compression formats. There are nice functions to inflate file size (btoa for base64 encoding, call atob to decode), why not something that deflates sizes?
>
> I also think HTML5 should have full compression & decompression built in too. This day and age, I think it should be standard.
>
> There is nothing or no one on this planet that can change my mind.
>
You are experiencing a very mild treatment from "the resident T", the 
person that everybody respects for his knowledge here, but everybody 
criticize for his severe attitude.

Perhaps he sees in you some of his bald mood when he was young, probably 
brilliant, and probably misguided by his self-confidence, fact is that 
he is treating you with some regards, unusually. In fact, he's not so 
harsh as usually he's. :-)

Maybe you resembles a bit to him in his youth, who knows?
Anyway, I would not simply discard the things that have been told to you.

It is hard for everybody of us to accept that some of our great efforts 
have been devolved to a cause not deserving such efforts, but nothing 
happens without a positive side effect. You studied, worked, learned a 
lot. Some people among the masters of Javascript don't like your work. 
OK. Stay at the window, just continue to work and study.
Prepare your comeback with something more mainstream but in between 
learn to accept critics and suggestions. Don't think simply you are 
right and they are tards that don't understand.
Go on, but keep feets on the ground.

hth
Dan

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

#26246

On Friday, November 28, 2014 4:31:25 PM UTC-5, danca wrote:
> Il 28/11/2014 17:20, Chris White ha scritto:
> > I think JavaScript should include nice simple functions for compression. Like bzip, lzma, rar, lha, gzip,  and all the other popular compression formats. There are nice functions to inflate file size (btoa for base64 encoding, call atob to decode), why not something that deflates sizes?
> >
> > I also think HTML5 should have full compression & decompression built in too. This day and age, I think it should be standard.
> >
> > There is nothing or no one on this planet that can change my mind.
> >
> You are experiencing a very mild treatment from "the resident T", the 
> person that everybody respects for his knowledge here, but everybody 
> criticize for his severe attitude.
> 
> Perhaps he sees in you some of his bald mood when he was young, probably 
> brilliant, and probably misguided by his self-confidence, fact is that 
> he is treating you with some regards, unusually. In fact, he's not so 
> harsh as usually he's. :-)
> 
> Maybe you resembles a bit to him in his youth, who knows?
> Anyway, I would not simply discard the things that have been told to you.
> 
> It is hard for everybody of us to accept that some of our great efforts 
> have been devolved to a cause not deserving such efforts, but nothing 
> happens without a positive side effect. You studied, worked, learned a 
> lot. Some people among the masters of Javascript don't like your work. 
> OK. Stay at the window, just continue to work and study.
> Prepare your comeback with something more mainstream but in between 
> learn to accept critics and suggestions. Don't think simply you are 
> right and they are tards that don't understand.
> Go on, but keep feets on the ground.
> 
> hth
> Dan

Good advice. I do appreciate any discussion, glad anyone even notices!

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

#26250

danca wrote:

> Il 28/11/2014 17:20, Chris White ha scritto:

Ah, an attribution line, and a quotation below it.  It would seem we are 
getting there :)

Now you only need to

- get a real name
- trim your quotes to the relevant minimum
- get off b0rked Google Groups and onto a newsreader

>> I think JavaScript should include nice simple functions for compression.
>> Like bzip, lzma, rar, lha, gzip,  and all the other popular compression
>> formats. There are nice functions to inflate file size (btoa for base64
>> encoding, call atob to decode), why not something that deflates sizes?
>>
>> I also think HTML5 should have full compression & decompression built in
>> too. This day and age, I think it should be standard.
>>
>> There is nothing or no one on this planet that can change my mind.
>
> You are experiencing a very mild treatment from "the resident T", the
> person that everybody respects for his knowledge here, but everybody
> criticize for his severe attitude.
> 
> Perhaps he sees in you some of his bald mood when he was young, probably
> brilliant, and probably misguided by his self-confidence, fact is that
> he is treating you with some regards, unusually. In fact, he's not so
> harsh as usually he's. :-)
> 
> Maybe you resembles a bit to him in his youth, who knows?

Fallacy: argumentum ad hominem.  This is _not_ about me *at all*.

> Anyway, I would not simply discard the things that have been told to you.
> 
> It is hard for everybody of us to accept that some of our great efforts
> have been devolved to a cause not deserving such efforts, but nothing
> happens without a positive side effect. You studied, worked, learned a
> lot.

True.

> Some people among the masters of Javascript don't like your work.

You are missing the point here.  This is not about “like” or ”dislike”, not 
about taste.  So far, there is also no work available to like or dislike.

It is about logic (or, if you prefer that, reason).  It is not logical (or 
reasonable) to send *more* code to the client in order to *perhaps* receive 
on the server a smaller footprint of the data only to be decompressed again 
(especially not with current transfer speeds).

And if you want to avoid that, it is also not logical to attempt to rewrite 
a programming language to favor a single purpose when a) tools exist that 
can be used instead, and b) the language is designed _not_ to be tied to a 
single purpose in the first place.

Premature optimization is the root of all evil. [tm]

> OK. Stay at the window, just continue to work and study.

Good advice, although the “continue” here is doubtful.  From the statements 
of him one can read here, it looks as though studying has not started yet.

> Prepare your comeback with something more mainstream

That is incredibly bad advice.  We (and I can say this on behalf of all 
hackers) value *thought-provoking* questions, *new* problems, and anything 
*away* from “mainstream”; in fact, we abhor “mainstream” as being dull, 
uninteresting and potentially flawed (there are always more people not 
knowing what they are doing than those who do).

However, we also abhor wannabes: people who think they know but obviously do 
not.  People who think that it does not take the time we took and the 
experience we acquired in order to recognize a problem and solve it in a 
*solid* way.  People who just think they know better without providing sound 
arguments in favor of their opinion.

So, if someone can provide a good, convincing argument, and presents it in a 
way that it is easy to process without being superficial (keep in mind that 
we value time), they will be listened to.  As he had not, because he had not 
done his homework, he was not (likely to be).

<http://www.catb.org/~esr/faqs/smart-questions.html>

> […] learn to accept critics and suggestions.
> Don't think simply you are right and they are tards that don't understand.
> Go on, but keep feets on the ground.

Good advice again.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#26251

Thomas 'Ingrid' Lahn wrote:

> danca wrote:
>> Il 28/11/2014 17:20, Chris White ha scritto:
> 
> Ah, an attribution line, and a quotation below it.  It would seem we are
> getting there :)
> 
> Now you only need to
> 
> […]
> - get off b0rked Google Groups and onto a newsreader

Oh wait, you did.  Good for you.  But you need to adjust its settings, or 
use its Rewrap feature before posting.  For compatibility and readability, 
in general there should not be more than 80 characters per line.  (It is 
also wise to write source code based on that principle.)

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#26267 — [OT] Re: JavaScript Packers, Compression & Decompression

Il 29/11/2014 15:05, Thomas 'PointedEars' Lahn ha scritto:
> Thomas 'Ingrid' Lahn wrote:
>
>> danca wrote:
>>> Il 28/11/2014 17:20, Chris White ha scritto:
>>
>> Ah, an attribution line, and a quotation below it.  It would seem we are
>> getting there :)
>>
>> Now you only need to
>>
>> […]
>> - get off b0rked Google Groups and onto a newsreader
>
> Oh wait, you did.  Good for you.

You are telling me my posts seem to come from GG??? :-( I use 
Thunderbird, and I keep auto-wrap on because somebody doesn't respect 
the 72-char line length, but had no idea that my messages, in turn, are 
non-standard. Ouch.)

But you need to adjust its settings, or
> use its Rewrap feature before posting.  For compatibility and readability,
> in general there should not be more than 80 characters per line.  (It is
> also wise to write source code based on that principle.)
>
Of course. Thx for pointing out this.

And I have read your previous post and began to answer but I have no 
time these days - anyway thanks for the part in which you agree, and a 
short clarification regarding the part you criticize, it was a benign 
ad-hominem argument. You must accept the idea you are quite popular here 
- for one reason or another - and sometimes you are cited as "for 
example", absit injuria verbis. :-)

Dan

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

#26249

On Thu, 27 Nov 2014 03:34:05 -0800, Chris White wrote:

> *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.

What problem are you trying to solve? Javascript can be sent compressed 
if the server and client agree to compressed data transfers, but this is 
a matter to be handled at the io strreaming level, which is not the level 
of the javascript api in the browser.

Moreover, it is singularly dumb to expect javascript to support all the 
historical compression methods of the last 30 years of computing. Most 
operating systems support compression methods by way of library code. 
However, the browser does not expose all system libraries to the script 
engine (except for perhaps msie, and look at all the security issues that 
has caused in the past!).

If you want a generic function to allow scripts executing in your browser 
to call either arbitrary or sandboxed runtime library functions then that 
is the proposal you should be making, but suggesting that javascript 
needs to reinvent the data compression wheel, and moreover that it should 
do so for a whole list of formats which are in most cases redundant, is 
just plain stupid.

-- 
Denis McMahon, denismfmcmahon@gmail.com

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web