Not apparent at first, but this is a TypeScript to c++ compiler at the core (https://github.com/geastack/compiler), with bindings for various platforms.
Ah, amazing project! Congratulations. I was just writing under another thread that we support any and unknowns in two different ways. First, most any and unknowns are lazy programming—if you trace the call graph you can prove they have concrete types, or used only in one shape. If we can't prove a type narrows properly, we lower it to a boxed dynamic value carrier so it doesn't block compilation. Like JSON.parse—for this we have a special syntax, you can do JSON.parse(x) as T, to define the type, and if you don't it becomes a dynamic value whose price you pay only for that site / variable.
We also have limited support for `new Function("...")` via a small evaluator written in C++ that parses and runs the generated body. We mainly built this for Fastify's generated routing functions so it doesn't support classes, asynchronous, destructuring, etc, but conditionals, loops, variable declarations etc work.
There is no "eval" yet, but the same support shape could be added for it too, as the mechanism is already there.
The approaches and the limitations are documented here:
I've been working on this full-time since late 2025. Happy to share what I've learned - feel free to email me as well if you wish to.
> so it doesn't support classes, asynchronous, destructuring
For users, this general category of problems (not knowing these edges) is the hardest. It's amplified if you pull libs from npm. One of the best ways to test compatibility is to test with non-trivial projects, or existing codebases. For example, one which has helped me a lot is trying to compile Microsoft's typescript-go compiler, after translating it from golang to TypeScript via a separately written tool. Large projects surface a ton of issues.
Also curious - how do you handle "number"? i32, i64, doubles, floats, i16 etc have very different performance characteristics. Also, things like sparse arrays, Error.stack etc. I haven't documented them in my project yet, but it's quite high up in the list of things people actually care about.
A plain number is a double, and then the compiler can prove it can be a 64-bit integer if the size is appropriate. The goal is to keep behavior parity with Node here. Loop counters etc stay double. But we also support custom types we introduced such as i32, which is crucial for embedded performance. And then of course we have proper typed arrays.
Regular arrays are dense, but we keep a presence bit for every element so we can identify sparse arrays and differentiate holes from undefined's. And finally, there's no Error.stack support right now.
I'll keep an eye on this, it seems cool - write once in typescript, compiler compiles typescript into native apps. Seems like it combines ideas from React Native (one language/application model across platforms), Svelte (compiles away high level abstractions to avoid a heavy runtime), and Flutter (own enough of the UI model to target very different platforms).
What I still don't understand (and can't find documentation for) is how Gea defines the portable abstraction boundary.
The targets are radically different: embedded devices, native UI kits, framebuffer-style rendering, and webviews. The docs don't make it clear which Typescript/JS/node/browser semantics are guaranteed. If I write something like `requestAnimationFrame` and `fetch` and `queueMicrotask`, does it work on every target? The lack of caveats in the documentation implies "Yes" but provides no assurance. Where is the compatibility matrix?
Does an application developer mostly stay inside a portable Gea model, or do they need to understand both Gea internals and the target platform to know what will work? If it's the latter, then it's hard to see the advantage of Gea vs just writing a native app.
My impression right now is: potentially VERY interesting, but needs clearer technical documentation about the portability/limitations and convincing real world proof before I can believe it and let myself be excited about it :)
Looking at the compiler repo, it looks like there is just one contributor. So I'm curious, what AI coding tools did you use? Which models? What's your workflow like? (I'm really interested in first hand experience on how models perform on truly difficult projects, not just at drawing pelicans)
Amazing questions, thank you for the careful read!
We should ship a compatibility matrix... at some point we were hoping to report test262 coverage for ECMAScript compliance, but we had to prioritize the release. Of course any of the typical web APIs work, including localStorage, and even so far as the Web Audio API (and we're working on WebRTC to make it cross platform. It's especially interesting to be able to build real-time communication apps, say, on an ESP32-S3, with just the web semantics).
In short, most app code stays inside the portable model. You need to know the target when you use host APIs that are constrained on small devices: blocking I/O, memory limits, file sizes, and of course you can combine it with native code for the target. I'm building a guitar effects processor, for example, where the UI is powered by Gea Stack but all the audio processing happens natively (https://github.com/dashersw/coyopedal).
On AI: yes, it's mostly me plus agents for the compiler. We have a team at Coyotiv that helps with everything else. I use Claude Code with Claude Opus as the main model and Sonnet subagents for parallel work, with a fair bit of Fable. I also combine this with whatever GPT model is available over Codex. During the past 6 months I've started working on the compiler, I've changed several model versions :)
What makes AI perform on a compiler:
Hard gates the agents can't argue with, like a diff gate that names every program whose output changed, plus conformance sweeps, a diary that captures past failures so they don't repeat, and treating a passing exit code as insufficient and the outputs get checked against Node.js behavior and unit tests.
The biggest differentiator for me is, even though I'm a pretty relaxed manager for humans, I'm a heavy micro-manager for AI. I read its thinking tokens and its code live and as soon as I spot something I don't like, I intervene and guide the model to the output I want to see.
It wasn't easy, Gea Stack in total I think burnt more than a million dollars in AI credits, and I've been working on it literally non-stop for 6 months.
Ah damn, this is a leftover from literally the first day of our Android target build. Of course it's native for Android, too. Will fix it ASAP, thank you!
TLDR; it's 11x slower than Node.js and 23x slower than Gea Stack with Hono. With raw HTTP server, Perry is ~27% faster than Node.js and Gea is 3.5x faster than Perry.
They mention OpenGL for the bigger targets, but I was wondering how this worked for the ESP32. Turns out they wrote a custom 2D rasterizer specifically for this target, basically a miniature version of a browser layout engine: https://geastack.com/blog-we-taught-a-chip-to-run-css
Each platform has its native bindings. For graphics, you write CSS and HTML canvas API as well as JSX, it renders to native components and their alignments, the canvas API is converted to native surfaces, whatever the platform uses.
It defers to platform defaults, Android compositor, UIKit/AppKit native views or CoreGraphics for the canvas on Apple platforms, GDI/GDI+ on Windows, whatever SDL2 chooses on Linux. If you have a Three.js app, it uses Metal on iOS and macOS, Direct3D 11 (open) and 12 (commercial license) on Windows and XBox.
It's not clear at first glance, but given (1) the apps are written in JavaScript (2) the project has repos for different OS native bindings, my bet is some kind of embedded JavaScript engine that just calls through to OS native widets
As much as it would cost a native app. Say, on Mac, a plain AppKit app consumes 16-17 MB, gea consumes 18-20 MB, Qt consumes 25-35 (depending on whether you use QML or not) and Tauri consumes 58-60 MB. Tauri suffers a lot from all the WebKit dependencies, as its UI is not native but rather HTML rendered by WebKit.
Don’t know about mac, but in windows qt hello world consumes about 10-15 mb. It is possible to optimise it to half of that. Fltk even goes lower to single digits. Crazy what fltk can manage to do even if creating simple utility apps like notepad or calculator.
A windows native app can be a few kilobytes on disk and use only as much memory as you give to set the stack size, so you might have to use actual numbers. Native can mean a lot of things and be extremely minimal.
I see what you’re getting at, but let’s not pretend like “load-bearing” is something that AIs made up. It was a turn of phrase long before AIs became mainstream and people are still allowed to use it.
"geatsc: the GeaStack TypeScript-to-C++ compiler. A clean-room rewrite built on one rule — a statically typed value that reaches a dynamic carrier is a defect, not a fallback."
The whole thing is like this
But to be fair, it's late 2026 so it's to be expected now that the vast majority of code and surrounding artifacts are AI generated. It's just a fact of life.
Heh, we spent 6 months writing and rewriting the compiler a couple of times and were just too excited about the final architecture. Thank you, simplified.
The code is on GitHub, for example for the first video that renders a 3D cube with CSS the code is at https://github.com/geastack/examples/tree/main/apps/css-3d-c.... It takes only a couple of CLI commands to get it running. For reference, I'm using a WaveShare ESP32-S3 AMOLED Touch 2.06" device here, but the same code renders on every target Gea compiles for.
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.
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.
Not apparent at first, but this is a TypeScript to c++ compiler at the core (https://github.com/geastack/compiler), with bindings for various platforms.
There is also the one from Microsoft themselves, although it supports only a subset.
https://www.microsoft.com/en-us/research/publication/static-...
Used in Make Code,
https://www.microsoft.com/en-us/research/project/microsoft-m...
Bookmarked, thanks
Author of tsonic.org here (which is very similar, but for Rust, C# and Mojo - WIP).
One of the biggest complaints I get is about missing documentation on what TypeScript is not supported.
For example, the following is obviously impossible:
or even: The rest of it is largely doable. But people want to see what's not supported. Otherwise it's not clear to them what to avoid.Ah, amazing project! Congratulations. I was just writing under another thread that we support any and unknowns in two different ways. First, most any and unknowns are lazy programming—if you trace the call graph you can prove they have concrete types, or used only in one shape. If we can't prove a type narrows properly, we lower it to a boxed dynamic value carrier so it doesn't block compilation. Like JSON.parse—for this we have a special syntax, you can do JSON.parse(x) as T, to define the type, and if you don't it becomes a dynamic value whose price you pay only for that site / variable.
We also have limited support for `new Function("...")` via a small evaluator written in C++ that parses and runs the generated body. We mainly built this for Fastify's generated routing functions so it doesn't support classes, asynchronous, destructuring, etc, but conditionals, loops, variable declarations etc work.
There is no "eval" yet, but the same support shape could be added for it too, as the mechanism is already there.
The approaches and the limitations are documented here:
https://github.com/geastack/compiler/blob/main/docs/EVAL.md https://github.com/geastack/compiler/blob/main/docs/DYNAMIC-...
I've been working on this full-time since late 2025. Happy to share what I've learned - feel free to email me as well if you wish to.
> so it doesn't support classes, asynchronous, destructuring
For users, this general category of problems (not knowing these edges) is the hardest. It's amplified if you pull libs from npm. One of the best ways to test compatibility is to test with non-trivial projects, or existing codebases. For example, one which has helped me a lot is trying to compile Microsoft's typescript-go compiler, after translating it from golang to TypeScript via a separately written tool. Large projects surface a ton of issues.
Thank you, would love to grab some time later next week!
And just to clarify, of course, this limitation is only for "eval", not regular TypeScript :)
Most libs from npm compile fine, including Hono, and we are now working on Fastify and MongoDB native driver.
We had an earlier prototype with a full-stack Gea-compiled app with dynamic fallbacks, but I believe we can do better.
And yes, of course, we tried compiling TypeScript compiler to C++ via Gea Stack, but had to deprioritize to get the release out the door.
Also curious - how do you handle "number"? i32, i64, doubles, floats, i16 etc have very different performance characteristics. Also, things like sparse arrays, Error.stack etc. I haven't documented them in my project yet, but it's quite high up in the list of things people actually care about.
A plain number is a double, and then the compiler can prove it can be a 64-bit integer if the size is appropriate. The goal is to keep behavior parity with Node here. Loop counters etc stay double. But we also support custom types we introduced such as i32, which is crucial for embedded performance. And then of course we have proper typed arrays.
Regular arrays are dense, but we keep a presence bit for every element so we can identify sparse arrays and differentiate holes from undefined's. And finally, there's no Error.stack support right now.
I'll keep an eye on this, it seems cool - write once in typescript, compiler compiles typescript into native apps. Seems like it combines ideas from React Native (one language/application model across platforms), Svelte (compiles away high level abstractions to avoid a heavy runtime), and Flutter (own enough of the UI model to target very different platforms).
What I still don't understand (and can't find documentation for) is how Gea defines the portable abstraction boundary.
The targets are radically different: embedded devices, native UI kits, framebuffer-style rendering, and webviews. The docs don't make it clear which Typescript/JS/node/browser semantics are guaranteed. If I write something like `requestAnimationFrame` and `fetch` and `queueMicrotask`, does it work on every target? The lack of caveats in the documentation implies "Yes" but provides no assurance. Where is the compatibility matrix?
Does an application developer mostly stay inside a portable Gea model, or do they need to understand both Gea internals and the target platform to know what will work? If it's the latter, then it's hard to see the advantage of Gea vs just writing a native app.
My impression right now is: potentially VERY interesting, but needs clearer technical documentation about the portability/limitations and convincing real world proof before I can believe it and let myself be excited about it :)
Looking at the compiler repo, it looks like there is just one contributor. So I'm curious, what AI coding tools did you use? Which models? What's your workflow like? (I'm really interested in first hand experience on how models perform on truly difficult projects, not just at drawing pelicans)
Amazing questions, thank you for the careful read!
We should ship a compatibility matrix... at some point we were hoping to report test262 coverage for ECMAScript compliance, but we had to prioritize the release. Of course any of the typical web APIs work, including localStorage, and even so far as the Web Audio API (and we're working on WebRTC to make it cross platform. It's especially interesting to be able to build real-time communication apps, say, on an ESP32-S3, with just the web semantics).
In short, most app code stays inside the portable model. You need to know the target when you use host APIs that are constrained on small devices: blocking I/O, memory limits, file sizes, and of course you can combine it with native code for the target. I'm building a guitar effects processor, for example, where the UI is powered by Gea Stack but all the audio processing happens natively (https://github.com/dashersw/coyopedal).
On AI: yes, it's mostly me plus agents for the compiler. We have a team at Coyotiv that helps with everything else. I use Claude Code with Claude Opus as the main model and Sonnet subagents for parallel work, with a fair bit of Fable. I also combine this with whatever GPT model is available over Codex. During the past 6 months I've started working on the compiler, I've changed several model versions :)
What makes AI perform on a compiler:
Hard gates the agents can't argue with, like a diff gate that names every program whose output changed, plus conformance sweeps, a diary that captures past failures so they don't repeat, and treating a passing exit code as insufficient and the outputs get checked against Node.js behavior and unit tests.
The biggest differentiator for me is, even though I'm a pretty relaxed manager for humans, I'm a heavy micro-manager for AI. I read its thinking tokens and its code live and as soon as I spot something I don't like, I intervene and guide the model to the output I want to see.
It wasn't easy, Gea Stack in total I think burnt more than a million dollars in AI credits, and I've been working on it literally non-stop for 6 months.
So essentially React Native but with the code not left in TypeScript/JavaScript but transpiled to C++?
> iOS Native mobile apps and device companion experiences
> Android Gea apps packaged as a native Android APK, rendered through a WebView
Why webview? No love for android?
Ah damn, this is a leftover from literally the first day of our Android target build. Of course it's native for Android, too. Will fix it ASAP, thank you!
It'll be cool to see how this compares with similar projects, there's a few of these jumping on the scene now.
We compared it to scriptc here: https://geastack.com/blog-geatsc-vs-scriptc
Another one is https://github.com/PerryTS/perry and Huawei ArkTS.
We ran an experiment with Perry, you can read it here: https://geastack.com/blog-hono-with-perry
TLDR; it's 11x slower than Node.js and 23x slower than Gea Stack with Hono. With raw HTTP server, Perry is ~27% faster than Node.js and Gea is 3.5x faster than Perry.
So, not native.
they are native, the typescript is transpiled to c++
What do they use for graphics and audio?
They mention OpenGL for the bigger targets, but I was wondering how this worked for the ESP32. Turns out they wrote a custom 2D rasterizer specifically for this target, basically a miniature version of a browser layout engine: https://geastack.com/blog-we-taught-a-chip-to-run-css
Each platform has its native bindings. For graphics, you write CSS and HTML canvas API as well as JSX, it renders to native components and their alignments, the canvas API is converted to native surfaces, whatever the platform uses.
I mean, is it OpenGL, Vulkan, Metal? etc...
It defers to platform defaults, Android compositor, UIKit/AppKit native views or CoreGraphics for the canvas on Apple platforms, GDI/GDI+ on Windows, whatever SDL2 chooses on Linux. If you have a Three.js app, it uses Metal on iOS and macOS, Direct3D 11 (open) and 12 (commercial license) on Windows and XBox.
It's not clear at first glance, but given (1) the apps are written in JavaScript (2) the project has repos for different OS native bindings, my bet is some kind of embedded JavaScript engine that just calls through to OS native widets
It compiles TypeScript statically to C++, there's no JS engine or VM running.
Ah this is for embedded apps. Pretty neat!
It also supports iOS, macOS, Android, Windows, Linux, XBox for Three.js games, as well as (some) Node.js apps.
could you throw a react project (WEB) at it and get a native macos project out of it?
It loosk more like React Native: https://github.com/geastack/examples/tree/main/apps/notes-na...
https://www.youtube.com/watch?v=o5RDfAmzE7s
It supports Gea frontends (https://geajs.com). Technically it could compile React with a plugin, but that is left to the community as an exercise :)
How many memory does it cost for a simple hello world window? VS Qt, Tauri
As much as it would cost a native app. Say, on Mac, a plain AppKit app consumes 16-17 MB, gea consumes 18-20 MB, Qt consumes 25-35 (depending on whether you use QML or not) and Tauri consumes 58-60 MB. Tauri suffers a lot from all the WebKit dependencies, as its UI is not native but rather HTML rendered by WebKit.
Don’t know about mac, but in windows qt hello world consumes about 10-15 mb. It is possible to optimise it to half of that. Fltk even goes lower to single digits. Crazy what fltk can manage to do even if creating simple utility apps like notepad or calculator.
Another data point: hello.c in GTK4 used over 100MB last I checked.
A windows native app can be a few kilobytes on disk and use only as much memory as you give to set the stack size, so you might have to use actual numbers. Native can mean a lot of things and be extremely minimal.
"The earlier implementation could not be driven to zero of them, because boxing was load-bearing in its emitter"
In the docs of the repo of their TS to C++ compiler. https://github.com/geastack/compiler
I see what you’re getting at, but let’s not pretend like “load-bearing” is something that AIs made up. It was a turn of phrase long before AIs became mainstream and people are still allowed to use it.
"geatsc: the GeaStack TypeScript-to-C++ compiler. A clean-room rewrite built on one rule — a statically typed value that reaches a dynamic carrier is a defect, not a fallback."
The whole thing is like this
But to be fair, it's late 2026 so it's to be expected now that the vast majority of code and surrounding artifacts are AI generated. It's just a fact of life.
Heh, we spent 6 months writing and rewriting the compiler a couple of times and were just too excited about the final architecture. Thank you, simplified.
What do you mean? You were so excited that you didn't want to talk about what excited you and left it to an LLM instead?
Nice.
I will keep an eye on this for future use.
the amount of ai used in this makes me think its pure vaporware. has anyone actually confirmed any of this is real or works?
Watch the demo videos here: https://www.youtube.com/watch?v=uCfFTZSG-PQ&list=PL9pDl_Oth4...
The code is on GitHub, for example for the first video that renders a 3D cube with CSS the code is at https://github.com/geastack/examples/tree/main/apps/css-3d-c.... It takes only a couple of CLI commands to get it running. For reference, I'm using a WaveShare ESP32-S3 AMOLED Touch 2.06" device here, but the same code renders on every target Gea compiles for.
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.