Use modern triple equals and change to js module

[Nikaoto]

Replaced:

• every != with !==
• every == with ===

Also, changed to a js module so it can be used with webpack and other bundlers.

[tomka]

I happened to read through this and believe this change introduces a subtle bug. A few lines above in L334, toFlatArray() is called, but without a second argument, i.e. outBuffer will be undefined here. The expected behavior before was that in this case, a new array will be created, and indeed undefined == null in JavaScript (the way it was before your change). Now the test is strict and fails therefore. As a consequence no array is created when outBuffer is undefined, which leads to an error. Maybe it would be best to just test if (!outBuffer) { or if (outBuffer === undefined) {?

[Nikaoto]

That's a correct remark. I should've noticed that when changing it.

In this case, however, outBuffer is never really undefined since toFlatArray is only used once on L334 outside the function:

// Line 330
		//output as blob or byteArray
		if(outputAsArray){
			//convert ebml to an array
			var buffer = toFlatArray(ebml)
			return new Uint8Array(buffer);
		}else{
			return new Blob(ebml, {type: "video/webm"});
		}

And the variable ebml, defined on L297 can't become undefined since the only changes made to it are a few push methods. So, in this case, my changes don't introduce fatal bugs, but they're still dangerous considering future modifications made to the code might have an undefined array be passed to toFlatArray.

What's more, there's a better way to export whammy as a module for nodejs without having the browser give an annoying error for accessing a non-existent global module.exports.

I'll fix both issues as soon as possible.

[Nikaoto]

This PR actually fixes the second issue I wrote about: #46

[tomka]

And the variable ebml, defined on L297 can't become undefined since the only changes made to it are a few push methods

While it is true that the variable embl can't become undefiend, it is actually the second parameter to toFloatArray() (the parameter outBuffer) that I worry about. If toFloatArray() is called in L334 without this second argument, only embl is passed in, which in turn is available as argument arr within toFloatArray(). The second parameter (outBuffer) is undefined in this situation and this results in an error if the arr contents are non-objects and get pushed to outBuffer.

The other changes look good to me though and the PR itself is certainly useful.

[Nikaoto]

It seems to have slipped my mind. outBuffer is definitely undefined when no second argument is passed to toFloatArray.