My only/biggest concern with DateTime libraries, after seeing how bloated moment is, especially with the timezone info, is how absolutely huge these things can be/get. Curious how big the bundle size is.
I know very few are bundling via Deno currently, but can see it becoming a popular option in a couple years.
Should note that an `async function` *ALWAYS* returns a promise... I often see things like...
async function foo() : Promise<bar> {
return new Promise(...)
}
Because of a lack of understanding of this simple fact, which seems to be amplified with the typescript typing of Promise<T> in the declaration.
One niggle with the post. IndexedDB's API was really meant to be a groundwork API and the expectation was that libraries would be built on top of that to make interactions easier to deal with for front end developers.
somewhat useful package... I usually just put the following at the top of js modules that need it..
const delay = ms => new Promise(r => setTimeout(r, ms));
Then I can use `await delay(10)` or whatever in practice. Often after file operations, so they can sync up before continuing (more for windows antivirus, etc) in node... or to slow down certain operations in a browser.
I will also use this when stubbing API clients when the server-side isn't ready, or similar on the server to simulate longer loads to check UI/UX behaviors.
I think about the only time I ever use defer method these days is with something like zxcvbn, that is massive. I have a wrapper (asdfgh) that waits for it to be loaded, and handles this for me.
I do like the import() function since it's in browser pretty much everywhere at this point... I don't really worry too much about supporting legacy browsers these days. ES2020 is generally a safe to use target at this point. I also realize that some people will disable JS altogether, and while I understand the sentiment, it shouldn't apply to applications.
Appreciate the article... and I agree, redis is very cool... I've used it for sequence generation, caching, pub/sub and queues. This article off topic though.
I just removed the other two posts since this one had conversation... the author keeps posting about this library via differing venues though.
Not a huge issue... just gets a bit over the top sometimes.
Should note that an `async function` *ALWAYS* returns a promise... I often see things like... async function foo() : Promise<bar> { return new Promise(...) } Because of a lack of understanding of this simple fact, which seems to be amplified with the typescript typing of Promise<T> in the declaration.somewhat useful package... I usually just put the following at the top of js modules that need it.. const delay = ms => new Promise(r => setTimeout(r, ms)); Then I can use `await delay(10)` or whatever in practice. Often after file operations, so they can sync up before continuing (more for windows antivirus, etc) in node... or to slow down certain operations in a browser. I will also use this when stubbing API clients when the server-side isn't ready, or similar on the server to simulate longer loads to check UI/UX behaviors.