journey of quanta: release 1.0.0

introduction -- why quanta?

since the pandemic, i wanted to make my own browser. back then, i had no idea how i was going to do it. i made some prototypes using webviews, but they weren't enough. in the summer of 2025, i started working on it. i had tried firefox before, but it didn't work out. i didn't have the freedom i wanted. i wasn't looking for a different skin with a few new features. i wanted to be in control.

i knew it was going to be difficult, but i had no idea how big the difficulty actually was.

that's where quanta started.

for almost 6 months, there was basically no progress. that was the learning phase. to be honest, when i started, i knew almost nothing about how javascript engines worked. after february 2026, things started moving much faster. you can see it yourself if you look at quanta's test history. it went from 21.8% to the 80s in just 5 months, and those 5 months weren't even continuous. there were breaks and other things in between.

what i'm trying to say is that quanta wasn't originally a standalone project in my mind. it was supposed to be a part of solar. but it's not that anymore. it became a project on its own.

it was the first step toward solar.

i never thought it would come this far. now it's an engine that can compete with quickjs in benchmarks, and its compatibility is getting there as well.

the journey behind it -- how i built it

i'm not going to lie about this: eventho i don't like to mention it i'm a 16-year-old high school student.

most of my day is spent at school and studying, and the other half is basically spent sleeping. realistically speaking, if i heard that a 16-year-old built a javascript engine, i probably wouldn't believe it either. because it doesn't sound real.

but our generation has a tool that makes things like this possible.

its name is ai.

whenever people see ai involved in something, we immediately put the "ai slop" label on it. maybe we're against it, maybe we aren't. but i'm going to be honest.

even though i filtered the architectural decisions, even though i made the decisions and designed the architecture, a biiiiig part of the code was written by ai.

am i ashamed of that?

no.

then you might say, "okay, you used ai, how are we supposed to trust your code?"

let me explain.

i didn't just throw prompts at an ai and press accept.

i went through the code. i stress-tested it. i ran test262 every day and after basically every change. i didn't rely only on test262 either. i tested real-world scripts, compared quanta with other engines, used different comparison suites with different engines, optimized its memory usage, and kept fixing things based on what those tests showed.

and honestly, where quanta is today is much better than what i expected when i started.

when i first started, i thought that after 24 months i would maybe reach around 60% test262 compatibility with a tree-walker somehow.

now, with temporal and intl excluded, it goes beyond 95%, and it has a bytecode vm and a non-moving gc.

did i never struggle?

of course i did. how could i not?

using ai doesn't make development sunshine and rainbows. at the end of the day, you're still working on a computer algorithm and what is, in my opinion, one of the harder kinds of projects in computer science.

quanta started as a tree-walker. my first goal was simply increasing spec compatibility.

once i reached the point i was aiming for, i moved on to building a proper gc. in the old version, you could almost say there wasn't even a gc. it couldn't really grow beyond around 10,000 objects. it was basically there for correctness.

once that was done, a proper gc was implemented. after that came the vm, performance improvements, and everything else.

you might be thinking, "where is the difficulty in this? what the freak?"

and honestly, at first, there doesn't seem to be much.

the normal development process itself wasn't painfully difficult to me. what was difficult was how long everything took, the lack of visibility, and most importantly, the bug hunts that sometimes took days while making it feel like absolutely nothing had progressed.

but this project taught me a lot.

i can design systems now. i know how to work with ai properly. i understand a lot more about how these things actually fit together.

so maybe it wasn't that much of a "journey" in the traditional sense, but hopefully you can get at least a little bit of a feeling for how quanta was actually developed.

architectural decisions -- and why?

this part obviously connects back to solar, because as i mentioned at the beginning, quanta's architecture was designed around what i imagine solar's final architecture to look like.

i wanted the choices to fit that architecture as naturally as possible.

register-based bytecode vm

there isn't a huge story behind this one.

fewer instructions.

threaded dispatch

as i mentioned, quanta started as a tree-walker.

when i moved it to a vm, i initially used switch-based dispatch. later, because of performance reasons, i moved to threaded dispatch.

one non-moving garbage collector

if you look through the code, you can see that there are things like dom, layout, and networking-related tags that aren't really part of javascript itself. these are reserved for the solar browser.

solar doesn't treat the dom and javascript as two completely separate worlds.

they live in the same world.

that's why having one non-moving gc made sense for the architecture.

does a non-moving gc have risks?

yes.

but we try to minimize them as much as possible by using allocations aligned to 16-byte sizes, expanding freed regions when possible, reusing objects of the same type, and a bunch of other small things.

allocator -- mimalloc

the choice of mimalloc actually came pretty late.

i probably made this decision this september

the reason was that at that point, it wasn't only about speed or compatibility anymore. memory usage had become important too.

with one of the bundled scripts we use, which is around 3 mb, the allocator's contribution was actually significant, and rss wasn't stable at all after running the script more than 10 times.

we tested different allocators, including glibc.

we eventually chose mimalloc.

not because it had the lowest rss.

the important thing was stability.

across 10 different runs, glibc could have around a 30 mb difference in rss, while mimalloc was only around 0.5 mb apart.

around 270–300 mb with glibc versus roughly 270–270.5 mb with mimalloc.

it also gave us a performance improvement on the same script. the runtime dropped by around 0.5 seconds.

so we went with mimalloc.

the parser

i was thinking about what else i should talk about, and yeah, the parser is probably worth mentioning.

if you read the documentation right now, you'll still see that quanta has an ast.

yes, it does.

but why?

as i mentioned above, we managed to bring the rss of that bundled script down to roughly 170–180 mb with a mechanism we call "taped expressions".

however, statements still create expressions internally, and you can also see this in places like classes and functions.

so why don't we just remove the ast completely?

first, because for me, it's currently not worth doing.

the effect of the ast on rss has already gone from around 77 mb down to around 3 mb.

for those remaining 3 mb, the amount of work required isn't really worth the potential correctness issues it could introduce.

we also try to keep the parse tree as small as possible with techniques like lazy parsing.

so yeah, the ast is still there.

and for now, i'm okay with that.

where quanta stands today -- and its limitations

today, quanta is honestly in a much better place than i could have imagined one year ago.

its performance is, in my opinion, good enough for the first stage of solar.

obviously, it isn't going to look like a jit-enabled engine, but for solar's initial development stage, it's enough.

and later, i already have plans for things like a jit.

temporal isn't implemented yet.

intl support isn't there yet either.

and performance shouldn't be compared directly with jit-enabled engines.

other than that, even though quanta has been heavily stress-tested, tested with test262, and compared against other engines in areas test262 doesn't cover, there can still be something missing somewhere.

that's just something you have to accept with software.

even today, bugs appear in all kinds of software.

so these are the limitations i think people should know about when looking at quanta today.

closing

i don't know if i'll be able to keep working on solar forever.

i don't know how long i'll continue it or how far i'll take it.

i reached the point of giving up on quanta more than once, but i got through it.

quanta taught me a lot.

maybe i still don't know every part of the javascript syntax.

but i also don't want to underestimate what i've built.

i'm completely open to criticism, as long as it's respectful.

because this is my engine.

it's a part of my dream.

it's quanta.

thank you for giving your time to this.

Written by Ata Türkçü on September 30 2026