Echo JS 0.11.0

Changed link to point to actual site article.  The component itself seems to be a commercial component.  Would be nice to have more insight into how the size reduction was accomplished though.  As it is, it's kind of a fluffy release article.

Nice module... one suggestion to anyone using this, make sure your minutes window supports your retry timeout for the outbound mail service/server.  Many hosts will do a greylist option on inbound emails, relying on the retry for SMTP servers to reduce inbound spam.  If you run your own SMTP server, set the first retry to 1 minute (default is usually 15 minutes).  This way a greylist receiving server will get the message within the window.

If you're using a service that you don't control, you should set the window to 30-60 minutes.  I would suggest looking into a delivery service like mailgun or sendgrid for these types of things, you'll see much better delivery rates for the big ISPs and mail providers.

Off topic, but good information to understand.

Been waiting for optional chaining for some while now.  Really want the linter in VS Code to support it already, been using it via Babel, but the UI linting errors visible are a little annoying.

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.