Echo JS 0.11.0

Please limit posts about your react hooks (at least on echojs) to once a month, there's no need to post about this more than that (let alone multiple posts in a week), most of the users are regular and tend to have an adverse reaction to seeing the same thing re-posted in spammy ways all the time... using a url redirect to work around the post limiter isn't doing you any good.

Continued spammy techniques like this will get the account deleted.

I really do think this is cool. would be nice if this were sourced as a TS project for npm, with a direct module url for use with deno (from github#master).  Since it wouldn't take much effort and could be used on the front-end more easily that way.

I wouldn't say SSR is dead, just rarely needed in practice.  For the most part, if your content is mostly static, then static rendering probably makes the most sense.  If your content is time-sensitive in general (news sites, flash sales), then SSR may make the most sense.  If your site is really more of an application, then Client Side Rendering/Routing makes the most sense.

Edited title to match the start of the repository description.

What I was meaning, is it would be nice, if you could backup/store the config/settings in a github repository as well... but this would mean more flat files, as opposed to sqlite... maybe import/export then an auto-import/export github integration for that.

Interresting... may take more of a look into this.. hoping that blog entries are stored as markdown, and curious how the source details are stored (github integration would be nice for saving the source data to gh).

Okay, liked this implementation, so took the time to update my uuid4 npm package to use a modified version for the browser implementation... also cleaned up some cruft and added module version(s) for both browser and node packages.

https://www.npmjs.com/package/uuid4

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.