Fix bug & port

[Bubuche87]

Technically I should make two different posts, but the "fix bug" is almost insignificant.
I needed only the inflateSync and deflateSync functions. I found a post where you put a line containing only those two features and ... First problem: on Android, this line make the browser hang and go unresponsive, especially when I try to to select the line ( to copy it ).
It's not your fault, it's more a consequence of the minification, but it's still problematic.

I finally did a "wget" on the page of the discussion and opened it on a desktop computer and managed to copy paste it into a file.

Now I import that into my web page ( using the script tag, the old way ) and I get an error, saying that "exports" doesn't exist.
And, in fact, your script ends with two fields of "exports" being affected, while exports itself hasn't been declared.

I used the beautify function built-in chromium to turn this single line into a more editable thing and changed those last lines ( to "const deflateSync = blablabla" ).
But then the file increased in size ( Normal, the beautification). By removing all indentation and all spaces where possible ( using a regex ) i reduced the file to 7.9 kb. It's not "one-line" (so can be edited without making most editors crashes) and still pretty small.

But.

It means that this "exports" problem is actually a problem, right ?

This was for the fix ( and the text is quite long despite the problem being insignificant ).

For the port: what about porting that to C? You say it produces better results that the standard C library, it's definitely something you should consider doing.

Also, once ported to C you could wasm it back to JavaScript. Maybe in the process you could spot the portions of the code responsible for this 4gig limitation. And maybe it will even gain a speedup in the process, because now the interpreter(or jit compiler) will not have to worry about weird type conversions at runtime.

Your code is small, fast and produces good results. Not sure how something like this can exist, but congratulations and keep it up 😊.

[101arrowz]

The use of the undeclared variable exports is for compatibility with a module system called CommonJS. If you're using the code within a web browser, you aren't using CommonJS and so you'll get an error. I would paste the original discussion code into the following closure:

(function(exports){ /* paste the code here */ })(window.fflate = {})

// now you can use `fflate.deflateSync` and `fflate.inflateSync` in the global scope

As for porting the codebase to C: I've tried to port it to Rust (see the rs folder) but the results weren't very promising in terms of performance, so I gave up on the project. I would be surprised if it were any different in C. I think it has to do with how much of this codebase is specially optimized for running in a JS environment, not a native one.

[Bubuche87]

I still think a C version of the inflateSync and deflateSync would be good. Because:
1/ you said that the compression ratio is better ( and I confirm from my tests). I don't think the language influences THAT.
2/ because the code is so small it could be statically linked ( understand: compiled with the project), removing the dependency to zlib.

You underestimate what "better compression ratios" means ( or I overestimate it, it's possible).

Do you mind if I try to port it to C ?
( I cannot do that now, but it's definitely something I would like to try someday )
( Of course you'll be credited as the author of the algorithm etc. And I think your license allows that, but I prefer to politely ask ).