1

Browsers have decompressors written to handle compressed CSS, JS, etc.

Can I access it via javascript...something like decompress(text_stream)

I don't want to use a JavaScript implementation ( there are many implementations out there: here is one post ) as I know the browser already has one implemented in C / C++. Is there any reason there would not be access to this from an API?

I've seen so many posts and .js libraries for decompression, I'm guessing it has been overlooked or there is some fundamental reason why it can't be exposed.

Community
  • 1
  • 1
CS_2013
  • 1,078
  • 3
  • 12
  • 22
  • "Browsers have decompressors written to handle compressed CSS, JS, etc." - do they? – Oliver Charlesworth Jun 09 '12 at 17:46
  • Where would your compressed text stream be coming from, in JavaScript running in a web browser? – Pointy Jun 09 '12 at 17:52
  • ...it's coming from an ajax call...responseText....I prefer to manage my own caching...just a preference. – CS_2013 Jun 09 '12 at 17:54
  • Well if it's compressed by the server it'll be decompressed by the browser before it gets to your JavaScript. – Pointy Jun 09 '12 at 17:54
  • Here is a similar question: http://stackoverflow.com/questions/5213126/how-do-i-efficiently-access-gzipped-xml-from-javascript. It would seem that you can tell the browser that the incoming mimetype of your request is x-gzip and the browser will decompress the incoming request for you. But there doesn't seem to be a way to access these browser decompression methods from JavaScript directly. – Brandon Boone Jun 09 '12 at 17:55
  • 1
    Any opinions on why this is not exposed to JavaScript...the browser knows how to do this...over-riding mime types looks like a possibility though. – CS_2013 Jun 09 '12 at 17:57
  • @pointy not compressed by the server - I compress manually using online tools for now. – CS_2013 Jun 09 '12 at 17:58
  • You can't override the MIME type from the browser (**this is wrong**)- the server has to do it (which makes sense, as the server's the thing that compresses it in the first place). If you're compressing it yourself outside the server's own mechanisms, then you still have to force the MIME type from the server end. – Pointy Jun 09 '12 at 17:58
  • @Pointy - Ahh, yes this is true. My mistake. – Brandon Boone Jun 09 '12 at 17:59
  • Oops that comment is wrong - you *can* override the MIME type. Nevermind then. :-) (See [this MDN reference](http://goo.gl/IFBta) - don't know if all browsers allow it.) – Pointy Jun 09 '12 at 17:59
  • well O.K I'll keep that in mind.... but back to my original question...does anyone know why the browsers implementation is not exposed...or should I be thinking "why would it be"? – CS_2013 Jun 09 '12 at 18:00
  • @CS_2013 fairly limited utility I'd expect - introduces a complicated new API that'd have to be maintained forever. – Pointy Jun 09 '12 at 18:01
  • ....well it has to be maintained anyways.....just put a wrapper around it for javascript use. – CS_2013 Jun 09 '12 at 18:16
  • @CS_2013 Just like Oli Charlesworth said, browsers don't have decompressors for minimized CSS or javascript, browsers just parse/interprete the content and execute it... About GZIP, that is other story, browsers just descompress it and append the content to user without javascript API for compatibility reason. – Fong-Wan Chau Jun 09 '12 at 18:35

1 Answers1

0

If you are talking about gzip data compression, then that is handled at a much lower level than javascript as any browser element can use gzip compression. In that case, the document is automatically decompressed before being used by the browser. There are many, many gzip libraries available. This would not be exposed via a javascript API because there is no need - it's seamless and automatic in the browser. There is no need to do manually gzip decompress in a javascript app.

If you are talking about javascript minification where javascript files are reduced in size by doing variable substitution (using shorter variable names), removing whitespace, etc... then the browser does not need to "decompress" minified files and does not do so. They are still legal javascript files and it runs them as they are. Thus, there is no API for unminifying because the browser doesn't do it. Third party apps have been built to unminify, but this is mostly to make code more readable to humans - it is not needed or done by the browser.

Minification and compression can be used together where a JS file is first minified and can then be compressed by the web server during transfer to the browser. In this case, the browser only sees the compression and does it's automatic decompression as the file is received. It ignores the minification because the file is still legal and runnable javascript even after being minified. The browser does not need to unminify it and does not.

jfriend00
  • 580,699
  • 78
  • 809
  • 825
  • 2
    That's good info...but the question is more asking why the native C/C++ implementation is not exposed to JavaScript...as there are numerous libraries in .js to decompress zipped files...people obviously need it. – CS_2013 Jun 09 '12 at 18:18
  • @CS_2013 - because it is done automatically for you if things have the right MIME info. What practical use is there for it in javascript? Features are generally only added where there is enough demand/benefit to warrant the extra coding, testing, size, documentation, etc... The answer in this case is the same reason why millions of other capabilities available inside a browser or inside the operating system are not exposed via javascript. – jfriend00 Jun 09 '12 at 18:19
  • 2
    I'd say +5 libraries out there in JavaScript form...also beyond use...there is simply preference. – CS_2013 Jun 09 '12 at 18:23
  • @CS_2013 - there are millions of things a browser could surface to javascript. They pick the things to work on that they think are the most important and that there is a champion for to push it forward and that they can find others to support them in. There is no more answer here than those who make these choices (what features to add to a browser, what new standards to push for) haven't thought javascript access to gzip functionality was as important as other things they could do. – jfriend00 Jun 09 '12 at 18:27
  • 1
    Well...I assumed it would just be a simple wrapper function...PseduoCode - javaScriptDecompress(){cPPDecompress();}...not a whole project...but it must be more complicated, as if it was that simple it would probably be done already. – CS_2013 Jun 09 '12 at 18:45