Echo JS 0.11.0

It's worth noting that *MOST* of these "consent" implementations are flat out *wrong* … what you are supposed to do, is *NOT* include 3rd party tracking scripts that use cookies until *AFTER* you've gotten consent. In practice, you aren't getting consent as you've already tracked the user in a meaningful way by including your analytics, ads etc.

When using this, you should only put in tracking/analytics/ads after the user hits the consent option.

Mostly agree... I tend to use package.json (scripts section) and npm as the source of all truth.  I mostly deal with services and systems that have a web front end, and since node/npm have a script manager and are required anyway it just makes sense to me.

I also, likewise tend to have a ./scripts/npm directory in my projects, and most of the references in package.json will call into them (some using cross-env etc).  In the scripts, I use shelljs a lot as it's got a lot of effectively shell-friendly shortcuts.  It's mostly easy cross-platform that way too (linux, windows, mac).

By convention, I tend to use a few specific scripts for specific use cases.

`localize` in order to configure and setup a docker container running local for dev.  Useful for services I'm not currently working on but need running, and having them in the background.

`dev` any initialization for local development, does a `ci` and copies .env.dev.env to .env ... effectively gets it ready to run local.

`build` build for deployment.

`rebuild` or `build-before` for those services that should be built before any other services are built.  Mostly for the db and settings in a mono-repo.  This way the SQL scripts for upgrades and the application settings are ready for the other services to build and integrate their output.  Most of the apps I deal with at work are deployed to multiple clients, so the settings project rolls up (deep merge) yaml configuration and strings.   !default -> client -> client-environment -> client-environment/*.json --- these are then deployed as part of the payload into the specific client/environment... such as client-internalqa or client-clientqc.

`setup` is usually something pushed into the dist package(s).  Some will be actual setup scripts, others will be containers for k8s or similar.  It does vary.

I also tend to prefer to keep all ci/cd configuration and scripts in source control as much as possible, it tends to make it less reliant on specific ci/cd agents/software.  At work, we use Azure DevOps (migrating to yaml configs), but have also used other systems.

Worth adding, where throttle and debounce can be very useful is in the case of events that trigger remote resources via either websocket and/or fetch calls.  Beyond this, secondary effects dealing with mousemove/over/out are another.  In the case of render effects, using the nextframe apis with your mouse events is a good idea. Keeping your last mouse event values, combined with a single hook for requestanimationframe.

https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame

While a little more Computer Science, and less software development, this understanding is important.  It's even more so if you want to understand how interaction with WASM works.

It's called hoisting and scope.

Stop posting SPAM, it's not welcome here.

Would like to +1 this a few times over.  Nice write-up and an interesting approach.  I would have the "isEvent" check also check that the parameter is typeof "function" though.

About the only thing I'd really like to see added, though would make adapters much more complex, would be range query support against the keys.  Some of the underlying adapters make it a bit of a pain, but it's doable.

I'm using a similar abstraction in one of my current projects, and that's the only real difference and a feature that I needed.

Should also be able to create a Cassandra adapter, which should work/scale well.

This is a decent tutorial for this use... It's worth noting some gotchas and an alternative wrapper.

An alterntavie with some orchestration and version upgrade management https://github.com/godaddy/node-cluster-service

You can also make use of worker_threads module for handing each request across a pool.  This just entered stable, instead of behind a flag, I would suspect that there will soon be options for scaling in the box.  Since it will have lower overhead than full cluster.

Beyond this, if you're using something like Kubernetes, then just scale your instances there and have ingress configured... There's no need for multiple layers of scaling/proxying requests.

I'm pretty sure ES2019 already cut.  A lot of the features being discussed in the article are not Stage 4 (final).

One of the features mentioned (pipeline operator) is actually something I really think could be great, but there are some competing versions, and no idea which is leading.  I can't help but feel it may be held up for some time, similar to decorators.

Here's a list of what was actually added for ES2019.

There are no "potential" es2019 features... it's already cut... this is a list of the actual features added for ES2019.

https://alligator.io/js/es2019/