Echo JS 0.11.0

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.

Generally, we really don't support posts regarding crypto currencies at all, and limit the posts on AI utilization in order to keep quality higher.

I'm leaving this post up, just letting you know so that you keep posts for similar tools to a minimum and that future posts may or may not remain up.

Personally, I find a lot of it interesting, but it's too easy to spiral into a morass of attempts at viral content with abusive financial incentives.

I don't think .env.example is the only way to document available environment variables... and for libraries or frameworks is almost absolutely the wrong way.  That's what configuration documentation is for.

IMO, a framework shouldn't even load .env on its' own, it should rely on the upstream application to load its environment as appropriate.  For that matter, depending on your orchestration, you might not use .env files at all, you may inject parameters from a secrets repo as part of k3s/k8s...

Now, you should document environment variables that are meant to be modified by users, but even that isn't always the case as outlined in the articles... sometimes they're for testing.

For something I've been working on the past month or so, I have specific tests that will only work in Windows and with native database install (not via Docker)... so there are environment variables to test those scenarios separately.  These aren't meant to be used downstream at all.

Nice... and I hope it works out for you as a passive income source.. I'm working on a software package myself intending to sell up-feature editions.

I would note that you can definitely hit cold start issues in Cloudflare if your site/service isn't called often enough for a given region... It's not too bad, just worth being aware that it can happen.

I worked at a SaaS startup for a while, where there was a very heavy demand to do a lot of work under 100ms "always" including the RTT, so in practice we'd need to be in the 30-50ms range, which included a few parallel database calls and a custom AI model.

While interesting, you posted this just over a week ago... Posting more frequently than every other month or so gets really noisy here and a lot of users tend to actively dislike that activity over time.

I'm glad to see you've added some usability features in place.  As a stretch goal, may want to look into publishing the entire package as an SVG based color font using the nerd font code points that match the logos, for the logos that overlap.  Though, in doing that, you might, or may not, want to also include or incorporate a nice svg emojii set.  Then you can be used as a fallback font for color iconography altogether.

I was kind of curious about the JS payload to the browser, and maybe how the dom node rendering was handled, or if any used canvas/wasm, etc.

I build an expandable Gantt chard for a job in 1999-2000 that was pretty tough going, had to work in NN4.x and IE4/5.  It worked, but with NN, you pretty much need to cover the area with a solid ILayer otherwise it'll give someone a seizure with the repaint flickering.  Today is so much nicer.

Depending on the level of interactivity, I'd probably try leaning into Rust+WASM with Canvas... As much as I love JS, been running a couple projects playing with Rust WASM and Canvas interactivity and it's been pretty nice.  You of course do lose some accessibility though, so that may be an issue depending no your needs.

Cool tool... I tend to be pretty anal about making all options available via command line parameters or via environment and search up from working and executable path(s) for a .env file.

I'm not always the best myself at keeping the example up to date, I usually locate my active .env a directory above my project, so I can reset --hard without losing my .env ... I don't know how often OP is cycling in and out new devs though.

FWIW, this has been around for a bit..  That said, I still think there's room to improve some of the tooling around imports, both JSON here, and CSS (future)... I think web components are pretty nifty and finally relatively broadly supported, so it would be nice to see a bit more work there.

https://caniuse.com/mdn-javascript_statements_import_import_attributes_type_json

Minor bit of advice... linting and formatting as a pre-commit and pre-release sanity check can help to spot these things...

If your release lint/format changes any files, then fail the release, you had raw commits that bypassed checks.

At least this way you can better spot malware additions to files before they get into the repo... this doesn't help against upstream attacks, but can at least help you spot these things... I set my max line length to 120 (what I tend to see on the screen when editing).