Echo JS 0.11.0

That's my concern as well.. FWIW, you can dynamically set the content in most UI frameworks for the raw SVG content, which can use CSS properties for attribute usage beyond a single color... so you could use var(--brand-color) and match against body.dark or body.light for adjusting an accent color as well.

Assuming your light/dark integration changes the html or body element as appropriate, most will/do just that.  I will generally detect for localStorage falling back to native preference, then set the html element appropriately as well as integration with my UI toolkit as such.  I do similar for handling various side-menu states combined with breakpoint integrations.

That's literally a placeholder though...  Which is fine, I was just mentioning it.

If you have the "real" content, then why would you need a skeleton?  I get that it uses the DOM values... but you'd need to have a placeholder for say "Last, First" or "123 any street" while the real data is loading, one would assume while the real data is loaded... that's the point of skeletons, generally speaking.

Kinda cool.. but you need to have placeholder values while loading, as well as assuming you aren't using a UI toolkit that already includes a skeleton component wrapper.

I blocked the site... I think this is the second or third such post for an online only tool from/for this site.

Reminds me of Svelte.

Interesting... though it seems like this and pixi.js are pretty large in terms of npm payload... the demo itself seems a little bit smaller, but still really large for what it is.

Updated title to more closely match the link and github repo description.  Tend to frown on submissions with the term "free" attached, or sensationalist titles.

Package seems interesting enough, would recommend also scanning uploads and extracted archives with ClamAV in addition to this tool.

I'm only slightly concerned about the distribution size of the delivered package from npm, not particularly bad as it's a server-side only package, but still on the heavy side.  In practice, you might want to use a worker instead of in-process inspections, similarly may even want to use an event sync/worker (Lambda/Function/Worker) as opposed to even in the same application in practice.

Would be nice to see performance testing for the checks in question... Would be nice if the site listed self-hosted and prominent cloud alternatives as well as some performance metrics.

One thing that I found interesting, is that Bun's FFI interfaces are blocking only... Deno's supports having the execution and responses async, which can help.  I wound up having to use koffi for Node and Bun because of this limitation in order to improve performance.

I do wish that koffi's interfaces were supported in the box for Node, though NAPI is pretty stable, I feel that a straight up FFI approach can be better for some types of library integrations.

On the article itself, it's really conflating a lot of issues that can be performance issues that are well outside your runtime itself.  Database utilization, tuning and even connections in environments where you may be horizontally scaling can be a serious issue.

Beyond this, database drivers are not all the same... depending on the driver itself and how connections are handled, for the promise.all, it could be serializing the requests on a single connection, or it could be acquiring several connections from the same pool.  Hard to know for sure.  That doesn't even get into connection gateways for things like PostgreSQL, CRDB, etc. that have expensive connections, which can be problematic combined with worker services like Lambda, Cloudflare or Vercel, where you may not want to have larger pools of connections.  Which is an entire other area not even discussed.

Definitely throwing a lot of different concepts at the wall in a less than coherent way.