Echo JS 0.11.0

In a database driver I once wrote, I took advantage of String objects in how I extended attributes for the purpose of parameterizing queries... it worked pretty well for my use case.  That said, other features I was trying to take advantage of got up streamed into a more popular dv driver, so I left it alone.

I like it... though I would suggest putting the relatively simple usage example with worker higher up in the readme...  A lot of the technical details following later.

Maybe also a ServiceWorker example, assuming the communication works with this context as well, which could be really useful for more advanced apps with communication channels in multiple tabs... think facebook style chat dialogs.

Maybe... in any case, it's deleted as OT... the message I left was mostly to point out that the post didn't belong in this context.

Keeping this since it's specific to a node-based workflow, even though there's not really JS content.

I would suggest that you &NEED& to spend a fair amount of time in planning in order to get what you expect... I've been using Claude Code with Opus as I personally find whatever Github Copilot uses by default to be annoying by comparison.

That said, the results don't exactly surprise me, as a lot was left indeterminant or otherwise unspecified... if you've ever worked with an overseas or otherwise disconnected development team, you will see similar results, but you're waiting until the next business day to continue, where AI is generally minutes away.

I've been able to achieve what I consider amazing results from AI, so long as I spend the time in clarification and enter with an understanding of the likely "miss" points that could happen from anyone.  I have a project I'm about to release that I literally spent just a day with an AI agent, and have a couple hours to go, that would have taken me at least a month of full time work.

I will say that I feel it's important to have a skill level to be able to do it yourself to get the best results.  You need to know/understand what is being produced to best understand what is wrong, where and how it is wrong and how to refine the results.

This couldn't be much more off topic here.

And this is why I think it's important for web devs to have some familiarity with SVG... usually much, much lighter than pulling in some of the graphing/charting libraries out there.

Interesting... though I'm not sure I have that level of trust... have you considered trying to integrate with a secondary browser surface, like the chromium browser that playwrite/puppeteer load?

You can have the app load in the integrated browser, and you will already have dev channel access, just need to side-load your extension into the "temporary" browser.  This way users don't have to trust AI extensions "inside" their local browser.  Just a thought on this.

Kind of interesting... Not sure how much value or position it might hold up against Playwright, Puppeteer or Astral in terms of the browser integration itself.  I'm also not sure if the value for the AI tooling might not be better as an integration library that works with either Playwright or Puppeteer, understanding that it's a large overlap with probably the same integration technology.

Just feels like a lot of duplicated effort.  Not to detract from your work.  I'm just curious as to some of the reasoning in terms of advantages or disadvantages.

If you haven't done so yet, take a look at Deno... I know bun is getting more attention, but IMO Deno works much better in terms of a shell scripting environment.. single executable, directly reference your packages (npm, jsr, http(s)), and no separate install step or node_modules (shared cache).

And yeah, not sure that I'd pull Cobol into anything at this point.. even mainframes have a lot more options in terms of recent-ish languages.

I updated the URL to the repo itself, since it's actually mostly written in JS/TS... but as a completely separate language, it's otherwise borderline off-topic.

Edit: not knocking the tooling at all, which is pretty interesting.  I've been a relatively heavy proponent of just using scripting language(s) and some unified libraries as much as possible for different ETL work... especially variations on data ingress/egress.  Where it's sometimes easier to manage many different solutions for each resource over trying to create more complex tooling.