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.
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));
Needs somw work... template strings are in JS, and the use of zod example should probably mention the library. Similar for the call at the end, give a zod validated example.
I may add methods like...
User.fromJSON = (json:string): User {
// parse
// validate or throw
// return User
}
For clearer data handling from untrusted sources. Using a FE/BE shared definitions and validation library even.
Needs somw work... template strings are in JS, and the use of zod example should probably mention the library. Similar for the call at the end, give a zod validated example. I may add methods like... User.fromJSON = (json:string): User { // parse // validate or throw // return User } For clearer data handling from untrusted sources. Using a FE/BE shared definitions and validation library even.