Echo JS 0.11.0

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.

Interesting... I might take a look once you have PostgreSQL and/or SQLite support working in the box.  Would suggest looking at some of the database extensions that are used with VS Code for refinement and inspiration... the MS-SQL extension is one of the better ones, you can run in docker pretty easily for the server instance, though on arm mac, you'll need Rosetta2 configured with Docker.

I would also suggest using the Rust side to handle at least the main portions of theming as much as possible... Windows, Mac, Linux (Gnome/GTK or KDE/Qt theme detection) to establish a baseline light/dark and appropriate accent/highlight color for buttons, etc.  This is an area were you can go a long way with just a minor amount of time ensuring appropriate fonts/colors for the environment by default.  Much easier with Rust than Electron even.

On the AI front, Not sure if it would be worth trying to train a relatively limited cpu-based model, given a populated database/schema table(s) constructed to a more common format... the variance will really come down to db specific characteristics...  MySQL/Maria's back-tick usage vs pg's case handling and ansi-quotes and MS-SQL's square brackets.  They all also have different schema interrogation to get the schema structure as well as varying behaviors.  SQLite in particular is both better and worse than MySQL in some ways depending on your schema definitions vs usage.

Other than the variance, the SQL language itself is really pretty succinct and limited enough that you should be able to minimize the need for more expensive interactions for most usage.

Adjacent would suggest supporting a migrations project structure, similar to say grate or similar tooling in order to facilitate db "projects" associated against a db instance.  Not to be MS centric, I just find the tooling around MS-SQL and Grate to be relatively nice to work with compared to others.  My DB preference is PostgreSQL though.