Echo JS 0.11.0

And this is a big part of why I haven't started publishing the MS-SQL client I had been working on, AI assisted...  Even though I have some pretty thorough tests for general functionality across node, deno and bun, I just don't quite trust it yet... let alone I still have a couple refactors I want to do around transactions and the documentation project.

It's hard to actually bulletproof test something that people might rely on.  And my client is mostly a wrapper around ODBC at this point.  I'm planning to do a strip-down version for general ODBC that isn't MS-SQL specific.

https://github.com/tsdrivers/mssql

Harder still are features that I want to target that only work for MS SQL Server on Windows with a Windows client (FILESTREAM).

The main advantages that I wanted are around query ergonomics...

https://tsdrivers.github.io/mssql/guide/queries.html

Just curious, is this completely, or mostly AI generated?

Not that I've never developed something offline/private then done a single public commit before, it's just a little sus these days.

Interesting, and haven't really dug into it.... I've done similar before using other JSON diff libraries.  Also, unsure how this fits in with using the browser's built in history API.

Interesting...  Would be cool to see it adapted for MUI and Mantine component libraries.

Given other existing clients, I'm curious as to the "why" on creating/using this one vs. some of the others.  I am a bit familiar with shortcomings I've experienced from other clients.

Also, a nice to have addition would be an implementation of request/response channels (ie: distributed rpc).  Of course on the latter part, I've mostly moved to using Redis for coordinating that type of work... despite SPOF issues.

Nice improvements on the description and readme, etc... the positioning of the tool is much clearer now.

FWIW, Deno also has a cloud target as well as being similar enough to Cloudflare and a few others that code is almost the same... The path for say Hono is more similar between Deno and the clouds as it is with Node (not sure on Bun).

FWIW, Deno also implements the node:sqlite interfaces...  Not to mention their centralized KV and queue implementations.

This really feels like something that should be an example/demo of using smaller components together...  cards, drop zones, etc.  As oposed to a larger component model.  Just my own take.

Also, what's the buy in ecosystem, cost for the app payload?  Especially if you're already settled on say MUI, Mantine or similar.

Just thought this was pretty nifty and that I'd share... I already thought of Deno as one of the better bundling experiences, now you get it for Desktop-class web-apps using the platform's native web-view (similar to Tauri), wouldn't be surprised if it was Tauri under the covers considering Deno and Tauri are both Rust based.

Basically YAGNI... but slightly over-inflated complaint in context.  It's a large reason to suffix promise returning functions with "Async" as well as, when shimming async funcitons, just return Promise.resolve(value) if your intent is to actually replace async.  Will also inject an await delay(1) inside such methods to force the intent.

const delay = (ms:number) => new Promise(r => setTimeout(r, ms));