Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fabrice Bellard Releases MicroQuickJS

github.com

Post reply on HN
Print view View original

201–210 of 594 posts

Re: Fabrice Bellard Releases MicroQuickJS

#201

Post by lucketone »

spacechild1 wrote: post #177
antirez wrote: post #111

If this had been available in 2010, Redis scripting would have been JavaScript and not Lua. Lua was chosen based on the implementation requirements, not on the language ones... (small, fast, ANSI-C). I appreciate certain ideas in Lua, and people love it, but I was never able to like Lua, because it departs from a more Algol-like syntax and semantics without good reasons, for my taste. This creates friction for newcom…

> it feels like it departs from what people know without good reasons. Lua is a pretty old language. In 1993 the world had not really settled on C style syntax. Compared to Perl or Tcl, Lua's syntax seems rather conventional. Some design decisions might be a bit unusual, but overall the language feels very consistent and predictable. JS is a mess in comparison. > because it departs from a more Algol-like syntax Huh?…

I known for very long time that c (and co) inherited the syntax from algol.

But only after long time I tried to check what Algol actually looked like. To my surprise, Algol does not look anything like C to me.

I would be quite interested in the expanded version of “C has inherited syntax from Algol”

Edit: apparently the inheritance from Algol is a formula: lexical scoping + value returning functions (expression based) - parenthesitis. Only last item is about visual part of the syntax.

Algol alternatives were: cobol, fortan, lisp, apl.

Re: Fabrice Bellard Releases MicroQuickJS

#202

Post by kvemkon »

qznc wrote: post #199
kvemkon wrote: post #188

Earlier quoted context omitted.

SQLite 3.51.1 $ wc -l ... 265908 sqlite-amalgamation-3510100/sqlite3.c Is there any as large as possible single source (or normal with amalgamation version) more or less meaningful project that could be compiled directly with rustc -o executable src.rs? Just to compare build time / memory consumption.

SQLite is only deployed as a single file but the original sources are multiple files. They call it "The Amalgamation". https://sqlite.org/src/doc/trunk/README.md

Yes, that's why I've asked about possible rust support of creating such version of normal project. The main issue, I'm unaware of comparably large rust projects without 3rdparty dependencies.

Re: Fabrice Bellard Releases MicroQuickJS

#203

Post by nine_k »

kvemkon wrote: post #188
drschwabe wrote: post #94

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.

SQLite 3.51.1 $ wc -l ... 265908 sqlite-amalgamation-3510100/sqlite3.c Is there any as large as possible single source (or normal with amalgamation version) more or less meaningful project that could be compiled directly with rustc -o executable src.rs? Just to compare build time / memory consumption.

The sqlite3.c file is generated from more finely-grained real sources, see https://www.sqlite.org/src/doc/trunk/README.md

Re: Fabrice Bellard Releases MicroQuickJS

#204

Post by [deleted] »

kvemkon wrote: post #188
drschwabe wrote: post #94

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.

SQLite 3.51.1 $ wc -l ... 265908 sqlite-amalgamation-3510100/sqlite3.c Is there any as large as possible single source (or normal with amalgamation version) more or less meaningful project that could be compiled directly with rustc -o executable src.rs? Just to compare build time / memory consumption.

[deleted]

Re: Fabrice Bellard Releases MicroQuickJS

#205

Post by simonw »

If anyone wants to try out MicroQuickJS in a browser here's a simple playground interface for executing a WebAssembly compiled version of it: https://tools.simonwillison.net/microquickjs

It's a variant of my QuickJS playground here: https://tools.simonwillison.net/quickjs

The QuickJS page loads 2.28 MB (675 KB transferred). The MicroQuickJS one loads 303 KB (120 KB transferred).

Re: Fabrice Bellard Releases MicroQuickJS

#206

Post by nine_k »

kvemkon wrote: post #202
qznc wrote: post #199

Earlier quoted context omitted.

SQLite is only deployed as a single file but the original sources are multiple files. They call it "The Amalgamation". https://sqlite.org/src/doc/trunk/README.md

Yes, that's why I've asked about possible rust support of creating such version of normal project. The main issue, I'm unaware of comparably large rust projects without 3rdparty dependencies.

From my daily-use utilities, ripgrep and bat seem to have zero dependencies.

Re: Fabrice Bellard Releases MicroQuickJS

#207

Post by sfpotter »

zdragnar wrote: post #120
drschwabe wrote: post #94

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's support for modularity is actually rather strong. This PDF gives a good overview of the basic techniques available: http://www.metamodulaire.org/Computing/modular-c.pdf

It may not be immediately obvious how to approach modularity since it isn't directly accomplished by explicit language features. But, once you know what you're doing, it's possible to write very large programs with good encapsulation, that span many files, and which nevertheless compile quite rapidly (more or less instantaneously for an incremental build).

I'm not saying other languages don't have better modularity, but to say that C's is bad misses the mark.

Re: Fabrice Bellard Releases MicroQuickJS

#208

Post by xonix »

norir wrote: post #178
antirez wrote: post #111

If this had been available in 2010, Redis scripting would have been JavaScript and not Lua. Lua was chosen based on the implementation requirements, not on the language ones... (small, fast, ANSI-C). I appreciate certain ideas in Lua, and people love it, but I was never able to like Lua, because it departs from a more Algol-like syntax and semantics without good reasons, for my taste. This creates friction for newcom…

I don't love a good deal of Lua's syntax, but I do think the authors had good reasons for their choices and have generally explained them. Even if you disagree, I think "without good reasons" is overly dismissive. Personally though, I think the distinctive choices are a boon. You are never confused about what language you are writing because Lua code is so obviously Lua. There is value in this. Once you have written…

Re: TCO

Does the language give any guarantee that TCO was applied? In other words can it give you an error that the recursion is not of tail call form? Because I imagine a probability of writing a recursion and relying on it being TCO-optimized, where it's not. I would prefer if a language had some form of explicit TCO modifier for a function. Is there any language that has this?

Re: Fabrice Bellard Releases MicroQuickJS

#209

Post by tacone »

ea016 wrote: post #81

Well, as Jeff Atwood famously said [0], "any application that can be written in JavaScript, will eventually be written in JavaScript". I guess that applies to embedded systems too [0] https://en.wikipedia.org/wiki/Jeff_Atwood

Sounds a bit like rule 35 of the Internet.

Re: Fabrice Bellard Releases MicroQuickJS

#210

Post by gaigalas »

simonw wrote: post #98
claar wrote: post #88

Earlier quoted context omitted.

I think many subscribe to this philosophy: https://distantprovince.by/posts/its-rude-to-show-ai-output-... Your github research/ links are an interesting case of this. On one hand, late AI adopters may appreciate your example prompts and outputs. But it feels like trivially reproducible noise to expert LLM users, especially if they are unaware of your reputation for substantive work. The HN AI pushback then drowns ou…

Yeah, I agree that it's rude to show AI output to people... in most cases (and 100% if you don't disclose it.) My simonw/research GitHub repo is deliberately separate from everything else I do because it's entirely AI-generated. I wrote about that here: https://simonwillison.net/2025/Nov/6/async-code-research/#th... This particular case is a very solid use-case for that approach though. There are a ton of important q…

> can it run in WebAssembly?

You can safely assume so. Bellard is the creator of jslinux. The news here would be if it _didn't_.

> What's the difference to regular JavaScript?

It's in the project's README!

> Is it safe to use as a sandbox against attacks like the regex thing?

This is not a sandbox design. It's a resource-constrained design like cesanta/mjs.

---

If you vibe coded a microcontroller emulation demo, perhaps there would be less pushback.

Post reply on HN