Live data from Hacker News

Fabrice Bellard Releases MicroQuickJS

github.com

121–130 of 594 posts

Re: Fabrice Bellard Releases MicroQuickJS

#121

Fabrice Bellard is widely considered one of the most productive and versatile programmers alive: - FFmpeg: https://bellard.org - QEMU: https://bellard.org/qemu/ - JSLinux: https://bellard.org/jslinux/ - TCC: https://bellard.org/tcc/ - QuickJS: https://bellard.org/quickjs/ Legendary.

For all the praise he gets here, few seem interested in his methods: writing complete programs, based on robust computer science, with minimal dependencies and tooling.

I agree: he loves to "roll your own" a lot. Re: minimal dependencies - the codebase has a software FP implementation including printing and parsing, and some home-rolled math routines for trigonometric and other transcendental functions.

Honestly, it's a reminder that, for the time it takes, it's incredibly fun to build from scratch and understand through-and-through your own system.

Although you have to take detours from, say, writing a bytecode VM, to writing FP printing and parsing routines...

Re: Fabrice Bellard Releases MicroQuickJS

#122

I wonder if this could become the most lightweight way for yt-dlp to solve YouTube Javascript challenges. https://github.com/yt-dlp/yt-dlp/wiki/EJS (Note that Bellard's QuickJS is already a supported option.)

Likely not, given that it only implements ES5.

Re: Fabrice Bellard Releases MicroQuickJS

#123
post #103
post #84

Earlier quoted context omitted.

Usually I watch your stuff very closely (and positively) because you're pushing the edges of how LLMs can be useful for code (and are a lot more honest/forthwright than most enthusiasts about it Going Horribly Wrong and how much work you need to do to keep on top of it.) This one... looks like a crossbar of random things that don't seem like things anyone would actually want to do? Mentioning the sandboxing bit in th…

Yeah, I failed completely to explain the context here. I'm currently on a multi-year side-quest to find safe ways to execute untrusted user-provided code in my Python and web applications. As such, I pay very close attention to any new language or library that looks like it might be able to provide a robust sandbox. MicroQuickJS instantly struck me as a strong candidate for that, and initial protoyping has backed tha…

I had been in a similar boat and here are some softwares that I recommend or would discuss with you

https://github.com/libriscv/libriscv (I talked with the author of this project, amazing author fwsgonzo is amazing) and they told me that this has the least latency out of any sandbox at only minor consequence of performance that they know of

Btw for sandboxing, kvm itself feels good too and I had discussed it with them in their discord server when they had mentioned that they were working on a minimal kvm server which has since been open sourced (https://github.com/varnish/tinykvm)

Honestly Simon, Deno hosting/the way deno works is another good interesting tidbit for sandboxing. I wish something like deno's sandboxing capabilities came to python perhaps since python fans can appreciate it.

I will try to look more into your github repository too once I get more free.

Re: Fabrice Bellard Releases MicroQuickJS

#124

I wonder if this could become the most lightweight way for yt-dlp to solve YouTube Javascript challenges. https://github.com/yt-dlp/yt-dlp/wiki/EJS (Note that Bellard's QuickJS is already a supported option.)

Not likely:

> It only supports a subset of Javascript close to ES5 [...]

I have not read the code of the solver, but solving YouTube's JS challenge is so demanding that the team behind yt-dlp ditched their JS emulator written in Python.

Re: Fabrice Bellard Releases MicroQuickJS

#125
post #2

I easily managed to build quickJS to WebAssembly for running in https://exaequOS.com . So I need to do the same for MicroQuickJS !

I'm curious what practical purpose you could have for running a js execution engine in an environment that already contains a (substantially faster) js execution engine? Is it just for the joy of doing it (if so good for you, absolutely nothing wrong with that).

It allows, for example, to create bindings as I did for raylib graphics library. exaequOS can run any program that can be built to WebAssembly It will soon support WASI p1 and p2. So many programming languages will be possible for creating programs targeting exaequOS

Re: Fabrice Bellard Releases MicroQuickJS

#126

Earlier quoted context omitted.

When I first read the source for his original QuickJS implementation I was amazed to discover he created the entirety of JavaScript in a single xxx thousand line C file (more or less). That was a sort of defining moment in my personal coding; a lot of my websites and apps are now single file source wherever possible/practical.

I honestly think the single file thing is best reserved for C, given how bad the language support for modularity is. I've had the inverse experience dealing with a many thousand line "core.php" file way back in the day helping debug an expressionengine site (back in the php 5.2ish days) and it was awful . Unless you have an editor which can create short links in a hierarchical tree from semantic comments to let you o…

C has no problems splitting programs in N files, to be honest.

The reason FB (and myself, for what it is worth) often write single file large programs (Redis was split after N years of being a single file) is because with enough programming experience you know one very simple thing: complexity is not about how many files you have, but about the internal structure and conceptually separated modules boundaries.

At some point you mainly split for compilation time and to better orient yourself into the file, instead of having to seek a very large mega-file. Pointing the finger to some program that is well written because it's a single file, strlongly correlates to being not a very expert programmer.

Re: Fabrice Bellard Releases MicroQuickJS

#127

This engine restricts JS in all of the ways I wished I could restrict the language back when I was working on JSC. You can’t restrict JS that way on the web because of compatibility. But I totally buy that restricting it this way for embedded systems will result in something that sparks joy

He already has a JS engine which doesn’t make these restrictions

Yeah QuickJS is great.

I bet MQJS will also be very popular. Quite impressive that bro is going to have two JS engines to brag about in addition to a lot of other very useful things!

Re: Fabrice Bellard Releases MicroQuickJS

#129

Earlier quoted context omitted.

It's interesting but I don't think it belongs as a comment under this post. I can use LLMs to create something tangential for each project posted on HN, and so can everyone else. If we all started doing this then the comment section will quickly become useless and not on point.

Offtopic but I went to your website and saw that you created hackernews-mute and recently I was commenting about how one must have created such an extension and ranted about it. So kudos for you to have created it earlier on. Maybe we HN users have minds in sync :) https://news.ycombinator.com/item?id=46359396#46359695 Have a nice day! Awesome stuff, would keep an eye on your blog, Does your blog/website use mataroa…

Thank you! I don't use Mataroa but I can see the similarities. My current blog setup is a Python script that parses content written in markdown and emits HTML. The CSS is inspired by the other minimal blogs I see here.

Thanks a lot for checking out my blog/project. Have a great day!

Re: Fabrice Bellard Releases MicroQuickJS

#130

People talk about how productive Fabrice Bellard is, but I don't think anyone appreciates just how productive he is. Here's the commit history for this project b700a4d (2025-12-22T1420) - Creates an empty project with an MIT license 295a36b (2025-12-22T1432) - Implements the JavaScript engine, the C API, the REPL, and all documentation He went from zero to a complete JS implementation in just 12 minutes ! I couldn't…

That doesn't mean anything. I quite often start with writing a proof-of-concept, and only initialize the git repository when I'm confident the POC will actually lead to something useful. Common sense says that those files already existed at the time of the first commit.
Post reply on HN