Hacker News Reader

Comment by simonw | Hacker News Reader

Funny to see this show up today since coincidentally I've had Claude code running for the past ~15 hours attempting to port MicroQuickJS to pure dependency-free Python, mainly as an experiment in how far a porting project can go but also because a sandboxed (memory constrained, to us time limits) JavaScript interpreter that runs in Python is something I really want to exist.

I'm currently torn on whether to actually release it - it's in a private GitHub repository at the moment. It's super-interesting and I think complies just fine with the MIT licenses on MicroQuickJS so I'm leaning towards yes.

Its got to 402 tests with 2 failing - the big unlock was the test suite from MicroQuickJS: https://github.com/bellard/mquickjs/tree/main/tests

Its been spitting out lines like this as it works:

  I see the issue - toFixed is using
  Python’s default formatting which uses
  round-half-to-even rounding, but
  JavaScript uses round-half-away-from-zero.

View on HN

I am waiting for a llm entusiast to create something like MicroQuickJS from scratch.

Fabrice Bellard, who developed MicroQuickJS, is a user of LLMs.

I scratch my head trying to understand how your comment relates to the parent...

The implication is that the task originally wondered about was done to begin with.

TI had similar idea with TI-99/4 - running interpreted BASIC programs using BASIC written in special interpreted language (GPL) running in its own virtual machine, with actual CPU machine code executing from ram accessible thru single byte window of Video processor. Really brilliant system, turtles all the way down.

I wouldn't trust it without a deeper inspection. I've had Claude do a workaround (ie: use a javascript interpreter and wrap it in Python) and then claim that it completed the task! The CoT was an interesting read on how his mind think about my mind (the user want ... but this should also achieve this ... the user however asked it to be this ... but this can get what the user want ...; that kind of salad)

yt-dlp/youtube-dl used a python javascript interpreter to run youtube's JS until recently

idk how complete it is but it solved youtube's challenges etc for a long time

https://github.com/yt-dlp/yt-dlp/blob/6d92f87ddc40a319590976...

You should release it, it'd be quite useful.

https://pypi.org/project/micro-javascript/ - https://github.com/simonw/micro-javascript

Here's the transcript showing how I built it: https://static.simonwillison.net/static/2025/claude-code-mic...

I see that you're no longer copying and pasting from the terminal, I remember those two gnarly code sessions to get a previous transcript. How are you generating that transcript now? I'd certainly like to use that for my own record keeping.

It's a new tool I built yesterday (because for this particular JavaScript interpreter project publishing the full transcript was essential): https://github.com/simonw/claude-code-publish

It only works with Claude Code for the web sessions at the moment but I expect I'll get it working for local sessions too.

Great, thanks!

How many tests do other JS runtimes like V8 have? ~400 tests sounds reasonable for a single data structure, but orders of magnitude off for a language runtime.

MicroQuickJS has 7, kind of: https://github.com/bellard/mquickjs/tree/main/tests

Though if you look in those files some of them run a ton of test functions and assertions.

My new Python library executes copies of the tests from that mquickjs repo - but those only count as 7 of the 400+ other tests.

Were the tests generated by an AI then? How do you know whether they are really comprehensive?

I'm now having Claude Code build the tests for my voicenotes organization application. For the most basic implementation - just a single text field - I wrote in English which tests I know I need, there were about two dozen. Approaching size limits, unicode, normalization, nonprinting characters, Hebrew vowel points, empty strings vs NULL strings, Exceeded byte length without exceeded character length, etc etc. I then threw Claude Code at it.

Claude Code found more edge cases to write tests for than I ever would have thought of. And I've been doing this for 20 years.

Yes, effectively my entire project was generated by AI.

It's a very weird and uncomfortable way of working - I've said in the past that I don't like a single line of unreviewed AI-generated code in anything beyond a prototype, and now here I am with 13,000+ lines of mostly unreviewed Python written by Claude Opus 4.5.

I'm leaving the alpha label on it until I'm a whole lot more comfortable with the codebase!

I do however know that the tests are pretty comprehensive because I had the model use TDD from the very start - write a test, watch it fail, then implement code to make it pass.

I was able to keep an eye on what it was doing on my phone while it worked and the TDD process seemed to be staying honest.

Here's one example from the full transcript, showing how it implemented closures: https://static.simonwillison.net/static/2025/claude-code-mic...

But why Python? Why not a JVM like Graal? I would think that would yield faster code.

Or why not run MicroQuickJS under Fil-C? It's ideal since it has not dependencies.

I build and distribute software in Python. My ideal solution is something that installs cleanly via pip so I can include it as a regular dependency of my other projects.

It's analogous to asm.js, the precursor to WebAssembly, which was written in js, in that it ran virtual machines in pure js, which is a huge win in portability. The mquickjs readme explains it in a much lower level way than the quickjs readme. There's also more emphasis on the bytecode. In a way it's like a tiny WebAssembly plus garbage collection extension vm that can run compile to js languages, going beyond that and compiling them to bytecode. The overhead of porting it to a dynamic language wouldn't always be that bad depending on the use case. Its memory savings could be maintained.

Reply on news.ycombinator.com