Split writer from reader? about omggif HOT 6 CLOSED

How does it actually make it easier to use one or the other? I guess what you mean is that it makes it easier not to include the source of what you're not using? I feel like in this day and age the only thing that makes sense if you care about javascript download size is to have some sort of compiler / minification / whatever in the pipeline, in which case dead code removal is going to do a better job than anything else. Once you start splitting it, it is not just reader or writer, but there are parts of the reader you might not use, or parts of the writer you might not use, etc.

Anyway, I just quickly ran the entire omggif through some minifier and the output is 6k, so the idea would be roughly to possibly save 3k for toolchains that aren't doing dead code removal.

Anyway, what I am trying to say is for such a small library I really don't think it makes sense.

Thanks though

from omggif.

It does though, it always does and it takes a few minutes to do it. I don't thing any dead code removal tool actually removes one or the other, since it does eventually export an object with two functions. I wish it did.

The great thing about CommonJS is that it's painless to create as many files as needed so why not take advantage of that?

from omggif.

Because not everyone uses CommonJS. If you look how omggif.js works, you can simply link it into a page and use it without anything related to CommonJS. That is how the vast majority of people are actually using it, and for them it is much more convenient and less http requests to have a single file.

from omggif.

There are solutions to every problem. I publish my modules in ES6 and have versions for ES5 node, browser via global, and AMD: https://github.com/bfred-it/get-media-size/blob/master/readme.md#files

In your case the main omggif.js would import both files and export the two variables normally, to maintain compatibility. omggif.min.js would be a processed file that includes both, in a UMD wrapper. It would be a good opportunity to also add a minified version for those who use plain script tags.

from omggif.

For anyone interested, here's a library that has encoder and decoder in two files, and it's streamable too:
https://github.com/devongovett/gif-stream

from omggif.

I don't really want to keep this going too long... you seem to be a bit religious about this browserify thing. Anyway, I find the criteria "has two files" vs "has one file" an interesting way of choosing between two libraries, given all of the other possible dimensions – performance, download size, memory usage, etc. I can guarantee two things:

1. The code size / download size of all of omggif combined (encoder and decoder) will be much smaller than this library's single encoder or decoder. Look at the number of dependencies from gif-stream. Just to prove my point, I did a browserify and minify of just require("decoder") for gif-stream and it is 78784 bytes minified. All of omggif (both reader and writer together) is 6180 bytes. That makes it more than a 10x bigger download size. Also don't forget that the JavaScript engine then has to parse and compile all of that code.

2. The performance of omggif will be better. JavaScript performance is always hard to guess at but I would say for an example of just encoding or decoding a gif it would probably be at least 2x that of gif-stream.

As a side note about streaming, in my experience it is almost always faster not to stream portions of a buffer, but to just process whole frames through the pipeline. So maybe streaming somehow seems attractive but in reality I think it is not.

Any of course you are welcome to use whichever libraries you want for whichever reasons you like. There is no benefit to me when someone uses omggif. Just using this opportunity to explain some of the background thought and work that was put into this library, and that it was written with code size and performance in mind. Just because it doesn't use the hip framework of the day doesn't mean anything. Integration with this mega world of JavaScript infrastructure was not a goal, it is a simple single file that can just be dropped anywhere and work, in node or in browsers. It is definitely extremely easy to integrate into projects and plenty of projects have already done so.

PS: JavaScript compilers such as closure definitely do dead-code removal and shouldn't have a problem removing unused portions of the code in omggif.

from omggif.