Echo JS 0.11.0

Looks like ie11 does have the URL method needed, but the result has a `blob:` prefixed before the UUID portion.  So replacing the substr check with a split/pop that includes a colon or \/ works.

    function uuid() {
      var temp_url = URL.createObjectURL(new Blob());
      var uuid = temp_url.toString();
      URL.revokeObjectURL(temp_url);
      return uuid.split(/[:\/]/g).pop(); // remove prefixes
    }

-- edited: original reply below. ---------------------

No IE support[1], but many are no longer supporting even IE11 at this point, at least for internalized apps.

It's cool, but not sure if this is any better than just using crypto.getRandomValues()[2][3] directly, which is supported by at least IE11 forward.  Assuming you only care about browser generation, otherwise node as a getRandom method on its' crypto implementation as well.

    window.crypto = window.crypto || window.msCrypto;

All of that said, your best bet is to still probably prefer the uuid[4] module's v4 implementation which handles most of the platform issues for you.

If you want a close to direct implementation, you could also try my uuid4[5] module.  If you want the implementation, you could always snag the browser.js source... it's bigger than TFA, but will at least work in a relatively widely used browser that doesn't support the URL api.

1. https://caniuse.com/#feat=url
2. https://developer.mozilla.org/en-US/docs/Web/API/Crypto/getRandomValues
3. https://caniuse.com/#feat=getrandomvalues
4. https://www.npmjs.com/package/uuid
5. https://www.npmjs.com/package/uuid4

Window management is kind of the most interesting feature imo, and without it on mac/windows, almost a non-starter.

Very cool that this works though.

In general, there are two major reasons to use DI.  The first is testability, as testing frameworks for TS/JS can override imports, that lessens the use case significantly.  The other is to easily target multiple plugins/modules that can be changed out.  If you aren't actively targeting multiple versions or plugin models, that lessens the second reason.

For most developers, most of the time, hard coding to an instance/module and using the testing frameworks to override those imports is less cumbersome than the overhead to reason with DI abstractions when spelunking through code in the future.

Wasn't there some risk of timing exploits for the earlier implementations?

Would be cool, but I don't think I've ever seen more than 3 downvotes on a post... 

I keep thinking it one had to have X karma in order to post...  but don't necessarily want to discourage first time posts.  The spammy accounts tend to be all over the map... some see about 3/4 quality post and 1/4 crap, others the inverse, others still single post, decent quality and others single post, crap.

Not to be negative, just feels like short of immense development, hand curation is still, largely the best option.

Mostly agree... I'd probably be more inclined to switch to typescript before adding an immutable library at this point.  And I'm not really doing ts in the app code.

Note: put .env in your .gitignore file... so it doesn't accidentally get checked into source control.

still prefer fetch/node-fetch directly.

Would add joi and ajv to the list, since they're more widely used than either.

Why is everything renamed to .txt?