The concern with a lot of projects that look largely AI made isn't that the current state works, but that this current state might be all that ever happens so people who try to use it end up relying on a dead project unless they maintain it themselves.

[refusing to reword the "it is not X, it is Y" - I'm not an LLM but I don't care that much if you think I am!]

I understand and appreciate the concern. We've been working on Gea Stack for about a year now. Started with https://geajs.com, then decided to enlarge the capabilities. The current capabilities have been under development for the past 6 months. We are in the process of forming a new company around Gea, and already collaborating with multiple embedded device vendors, development partners and customers who are interested in the technology.

There's a broader philosophy of "firmware freedom" that we want to bring to the world. Practically, you should buy hardware for what it is, and run your own firmware on it. E-book readers and unlocked bootloaders in the Android world is doing a pretty good job at this, so we want to contribute to this movement by making the development of such solutions dead simple, both for humans and AI. Incidentally, TypeScript, JSX, and CSS happen to be the languages AI knows best.

So, it's an ambitious project with a real team behind it, with commercialization on the horizon.

You are getting good advice here; if you don't go beyond the default AI aesthetics, your implicit communication will be that this is low-effort AI-slop. Regardless of your true effort.

Much appreciated. There's a lot to work on, and we initially chose to spend a bulk of our effort on the engineering work itself as it's the moat and the foundation to everything else. Everything else we can fix in time.

Having said that, I personally designed the logo and visual aesthetic and it serves a purpose. We believe in firmware freedom and hardware hackability, just like it was the norm in 70s and 80s. Of course it could have been executed better, but the current form is a specific choice after many iterations and certainly not low-effort. Too bad it reminds people of AI-slop, for an older generation it reminds other things.

with a lot of ai projects it's often that the only thing that does work is the demo. and im not saying this to be rude, its an ambitious project and im afk so i cant test it myself.

how does it compile js to c++? js is so dynamic it makes me think it either compiles to some kind of bytecode or its a heavily restricted subset of the language.

It took us 6 months to build the compiler. We analyze literally the hell out of the call graph. We started with strictly typed TS, which is trivial to compile. Then we added a dynamic fallback for projects that have "unknown"s and "any"s, then we had several architectural changes which allowed us to inspect those "claim"s. If you think about it, marking a variable "any" is a lazy claim. If it's ever used in one place and in one shape (akin to duck typing), you can create a static struct out of it...

So there's no byte code, and while not every single dynamic language feature has a corresponding static compilation, the base is pretty broad. So much so that Hono, the web framework, with all its dependencies, compile just fine.

What do you do for memory management? Conservative GC or Ref counting? If ref counting, how do you detect cycles?

It does appear most JS features can be translated to C++, even if at some overhead. Did you encounter any which wasn't straightforward?

It's ref counting, so most objects are freed as soon as the last reference goes away. Cycles are handled by a backup cycle collector using trial deletion (Bacon–Rajan style). Any object whose refcount drops without hitting zero becomes a candidate, and the collector traces from those candidates. In practice cycles are rare, and refcounting does almost all the work.

There were a lot of hurdles along the way and we solve them as we come across them. Keeping values native when JS uses them dynamically was a challenge. d = new Date(); d.foo = 1 is easy if you box everything, but then it's a slow interpreter (like some other projects in the field). So we had to invent a new mechanism; native types get a side table for extra properties.

Generics and union types were also challenging: one JS generic can need several different C++ layouts.

eval is limited: new Function runs on a small evaluator written in C++, and direct eval isn't supported yet.

Thanks claude :-)