Very cool, starred. I did add an "issue" suggesting that you publish a docker image to make this easier to run without worrying about direct dependencies.
Nioe writeup on these non-mutating methods. It is worth noting that if you have *VERY* large arrays in React you may want to combine with a viewport handler so only the visible nodes are rendered in order to improve DOM performance. It's one of the few places that I will lean towards earlier than later optimization as it can get noticeable fairly quickly.
I generally do line delimited JSON output for stdout logging in production environmnets. This lends itself very well to log shipping and ingestion into services like ELK-stack and Cloudwatch etc.
For JS based services, I will enrich the context object with logging/timing support that will add in a few bits from the request object (path, method, etc). It tends to work pretty well.
The shape of my log entries are usually along the lines of...
{
level: Enum(LogLevel)
timestamp: DateTime,
message: String
req: {
path: String,
search: String,
started: DateTime,
elapsed: Number/Decimal (ms) - since started
},
res?: {
status: Number,
statusText: String,
comment?: String,
},
error?: Error
details?: Object
}
The signature's for logging are like...
ctx.log.debug
(message: string, details?: any) => ...
(error: Error, details?: any) => ...
res bits from ctx if set/available and not part of the error or details (status/statusText/comment). Message will come from the error, when passing an error.
It's tended to work pretty well.. I fclone the error/details object(s) for safety... errors will graft back a few pieces that are hidden from enumerated properties (trace, etc)... Depends on the LOG_LEVEL though.
I'd say it (Hono) is about half a step above Oak or Koa in that it's a similar pattern with a "standard" entry that works pretty well cross-environment... Native for Deno and Cloudflare (I think Bun too) and a small shim for Node.js, the only hard-ish part is there's some inconsistency between publishing of different parts between npm and jspm, also some of the environment specific modules were a bit more difficult to work out (at least in deno) as a result.
I've toyed with CF Workers/Pages deployments with Turso and D1... I want to like the CF hosting stuff, but have a few times had issues where I'm actively developing and the test environment deployments bork.
I haven't used Next/Nest enough to fairly comment on them. I'm not really a fan of page based routing, not to mention for apps, I don't really care about SEO, so have been fine with SPA React.
Cool to see stuff like this... that said, personally I've really gotten into basing most of my validation around zod... this works with hono/zod-openapi as well as client validation integration, so I'm able to get a lot of usage out of the same tools on both the client and server usage.
For server-side, with JS/TS I've gone heavy in with hono, recently used the zod + openapi integration, which has been very nice to use. I've also used C# with FastEndpoints library, which has also been very nice.
Client side, currently working with Mantine component library, though have used MUI a lot as well... for forms, I've used React + React-Hook-Form and zod indegration. Creating modest wrappers around form field elements in order to present error states and helper messages cleanly.
Not to detract from this Vue3 approach, just pointing out what I've used and that zod in particular has made things pretty nice all around, not just on the client.
It would be nice to include references to some common utilities (Git Credential Manager, AWS CLI, etc) that use this technique for authenticating users with CLI tooling.
Not sure how much of this article is or isn't AI in nature... the premise is interesting.
That said, using recursion in JS is asking for pain... you're best of rethinking an algorithm in such a way that removes recursion in favor of iteration. While some algorithms are intended to work best/easiest with recursion, it's usually a bad idea for JS.
Another issue tends to come down to trying to force immutable data usage, where mutation within a function/iterable is often a better use of the language in terms of overhead and performance. While not everything you do needs to be optimized, recursion is one of those things in JS where it's too easy to hit walls. Most runtimes do not have proper tail call optimizations for example.
Both in terms of JS limits as well as DOM limits, such as complexities that are less common today, but still pop up now and then. Nothing worse than a blank page that barely moves and soaks your CPU cycles.
If your timing structure is particularly tight, you might want to adapt an async iterable even... I really like that about the more modern stream designs in JS.
I think the only thing I'd probably change would be to just use emoji instead of the png. They're well supported enough, even if the "font-family" list gets a little weird.
I generally do line delimited JSON output for stdout logging in production environmnets. This lends itself very well to log shipping and ingestion into services like ELK-stack and Cloudwatch etc. For JS based services, I will enrich the context object with logging/timing support that will add in a few bits from the request object (path, method, etc). It tends to work pretty well. The shape of my log entries are usually along the lines of... { level: Enum(LogLevel) timestamp: DateTime, message: String req: { path: String, search: String, started: DateTime, elapsed: Number/Decimal (ms) - since started }, res?: { status: Number, statusText: String, comment?: String, }, error?: Error details?: Object } The signature's for logging are like... ctx.log.debug (message: string, details?: any) => ... (error: Error, details?: any) => ... res bits from ctx if set/available and not part of the error or details (status/statusText/comment). Message will come from the error, when passing an error. It's tended to work pretty well.. I fclone the error/details object(s) for safety... errors will graft back a few pieces that are hidden from enumerated properties (trace, etc)... Depends on the LOG_LEVEL though.