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 enough Lua, your mind easily switches in and out of Lua mode. Javascript, on the other hand, is filled with poor semantic decisions which for me, cancel out any benefits from syntactic familiarity.

More importantly, Lua has a crucial feature that Javascript lacks: tail call optimization. There are programs that I can easily write in Lua, in spite of its syntactic verbosity, that I cannot write in Javascript because of this limitation. Perhaps this particular JS implementation has tco, but I doubt it reading the release notes.

I have learned as much from Lua as I have Forth (SmallTalk doesn't interest me) and my programming skill has increased significantly since I switched to it as my primary language. Lua is the only lightweight language that I am aware of with TCO. In my programs, I have banned the use of loops. This is a liberation that is not possible in JS or even c, where TCO cannot be relied upon.

In particular, Lua is an exceptional language for writing compilers. Compilers are inherently recursive and thus languages lacking TCO are a poor fit (even if people have been valiantly forcing that square peg through a round hole for all this time).

Having said all that, perhaps as a scripting language for Redis, JS is a better fit. For me though Lua is clearly better than JS on many different dimensions and I don't appreciate the needless denigration of Lua, especially from someone as influential as you.

> it feels like it departs from what people know without good reasons.

Lua was first released in 1993. I think that it's pretty conventional for the time, though yeah it did not follow Algol syntax but Pascal's and Ada's (which were more popular in Brazil at the time than C, which is why that is the case)!

Ruby, which appeared just 2 years later, departs a lot more, arguably without good reasons either? Perl, which is 5 years older and was very popular at the time, is much more "different" than Lua from what we now consider mainstream.

I read this comment, about to snap back with an anecdote how I as a 13 year old was able to learn Lua quite easily, and then I stopped myself because that wasn't productive, then pondered what antirez might think of this comment, and then I realized that antirez wrote it.

It wouldn't fix the issue of semantics, but "language skins"[1][2] are an underexplored area of programming language development.

People go through all this effort to separate parsing and lexing, but never exploit the ability to just plug in a different lexer that allows for e.g. "{" and "}" tokens instead of "then" and "end", or vice versa.

1. <https://hn.algolia.com/?type=comment&prefix=true&query=cxr%2...>

2. <https://old.reddit.com/r/Oberon/comments/1pcmw8n/is_this_sac...>

Out of interest, was Tcl considered? It's the original embeddable language.

JavaScript in 2010 was a totally different beast, standartization-wise. Lots of sharp corners and blank spaces were still there.

So, even if an implementation like MicroQuickJS existed in 2010, it's unlikely that too many people would have chosen JS over Lua, given all the shortcomings that JavaScript had at the time.

> 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? Lua's syntax is actually very Algol-like since it uses keywords to delimit blocks (e.g. if ... then ... end)

Redis' author also made jimtcl, so I don't think the lack of a small engine was the gap

Lua - an entire language off by one.

Lua only departs from norms if you’ve had a very narrow experience with other programming languages.

Frankly, I welcome the fact that Redis doesn’t use JavaScript. It’s an abomination of a language. The fewer times I need to use it the better.

Not to mention the 1-based indexing sin. JavaScript has a lot of WTFs but they got that right at least.

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

Since you’re on the topic, what ever happened to the multi threading stuff you were doing on JSC? Did it stop when you left Apple? Is the code still in JSC or did it get taken out?

Looks like those sizes could be improved significantly, as the builds include names etc. I would suggest linking with

emcc -O3

(and maybe even adding --closure 1 )

edit: actually the QuickJS playground looks already optimized - just the MicroQuickJS one could be improved.

Indeed

https://www.destroyallsoftware.com/talks/the-birth-and-death...

Well, wasn't Fabrice Bellard the guy who built a virtual machine with JS so that you could run Linux within the browser?

https://bellard.org/jslinux/vm.html?cpu=riscv64&url=fedora33...

Sounds a bit like rule 35 of the Internet.

It does say "public repository of..." implying there's a non-public one with real history. Not sure why not upload the main one though.

Maybe he just oneshotted it

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.

Likely not, given that it only implements ES5.

There are already libraries/frameworks that have supported this:

* espruino (https://www.espruino.com/)

* elk (https://github.com/cesanta/elk)

* DeviceScript (Microsoft Research's now defunct effort, https://github.com/microsoft/devicescript)

That's been possible with Moddable/Kinoma's XS engine, which is standards compliant with ES6 and beyond.

<https://www.moddable.com/faq#comparison>

If you take a look at the MicroQuickJS README, you can see that it's not a full implementation of even ES5, and it's incompatible in several ways.

Just being able to run JS also isn't going to automatically give you any bindings for the environment.

Sort of related: About ten years ago there was a device called the Tessel by Technical Machine which you programmed with Javascript, npm, the whole nine yards. It was pretty clever - the javascript got transpiled to Lua VM bytecode and ran in the Lua VM on the device (a Cortex M3 I believe). I recently had Claude rewrite their old Node 0.8 CLI tools in Rust because I wasn't inclined to do the javascript archeology needed to get the old tools up and running. Of course then I put the Tessel back in its drawer, but fun nonetheless.

Yes. The key enabling feature is a lack of malloc()

I suspect it's just random luck, not timing.

Some other guy tried it as well after you, also no luck.

One strategy is to wait for US to wake up, then post, during their morning.

Other strategy is to post the same thing periodically until there is response.

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.

At this point I'm convinced that they're not a 'real person' and the 'Fabrice' is an operational code name for a very mature hacker collective.

Real people have to sleep at some point!

He's also built a closed-source LLM inference engine, which he's been maintaining since the GPT-2 days: https://bellard.org/ts_server/ and https://textsynth.com/

Always interesting when people as talented as Bellard manage to (apparently) never write a "full-on" GUI-fronted application, or more specifically, a program that sits between a user with constantly shifting goals and workflows and a "core" that can get the job done.

I would not want to dismiss or diminish by any amount the incredible work he has done. It's just interesting to me that the problems he appears to pick generally take the form of "user sets up the parameters, the program runs to completion".

He's also won the International Obfuscated C Code Contest 3 times.

https://www.ioccc.org/authors.html#Fabrice_Bellard

Don't forget his LZEXE from the good old DOS days which was an excellent piece of work at the time.

Don't forget his LLM based text compression software that won awards.

Guy is a genius. I hope he tries Rust someday

Whenever someone says there's no such thing as a 10x programmer, I point them to Fabrice and they usually change their mind.

Funny how people know Fabrice for all the software stuff but none of the hardware antics:

played with implementing analog modem DSP in software in 1999 (linmodem is ~50-80% there, sadly never finished)

probably leading to

played with implementing SDR (again DSP) using VGA output to transmit DVB-T/NTSC/PAL in 2005

probably leading to

Amarisoft SDR 5G base station, commercial product started in 2012 - his current job https://www.amarisoft.com/company/about-us

For real. The GOAT is at it again!

The first two links are broken.

For all the praise he's receiving, I think his web design skills have gone overlooked. bellard.org is fast, responsive and presents information clearly. Actually I think the fancier the website, the shittier the software. Examples: Tarsnap - minimal website, brilliant software. Discord - Whitespacey, animation-heavy abomination of a website. Software: hundreds of MB of JS slop, government wiretap+botnet for degenerates.

The math checks out.

Hard because of web compatibility.

The good news is that it would probably not matter much for chromium's memory footprint anyway...

They are very similar in terms of ROM footprint (esp: 128K vs mqjs: 100K) and min RAM (esp: 8K vs mqjs: 10K), but spec coverage need to be examined in detail to see the actual difference.

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).

rare occasion where he gained a legendary status based purely on his work, I dont think I ever saw even a written interview with the guy

Bellard it the most genius programmer to ever exist, and the least known compared to other pseudo stars.

There is! ACM grants several awards for scientists and more.

One such award is the Turing Award [1], given "for contributions of lasting and major technical importance to computer science."

[1] https://en.wikipedia.org/wiki/Turing_Award

His consistency and craftsmanship is amazing.

Being an engineer and coding at this stage/level is just remarkable- sadly this trade craft is missing in most (big?) companies as you get promoted away into oblivion.

If there were some form of "developed contributions to computing" award, his name is definitely up there. I think there could be a need for such an award - for people who reliably have created the foundations of modern computing. Otherwise it's almost always things from an academic context, which can be a little too abstract.

Between ffmpeg and qemu, I always think of https://xkcd.com/2347/ when I see Fabrice's work. Especially since ffmpeg provides the backbone of almost all video streaming systems today.

I was surprised by this one that only showed up lower in the document:

- Date: only Date.now() is supported. [0]

I certainly understand not shipping the js date library especially in an embedded environment both for code-size, and practicality reasons (it's not a great date library), but that would be an issue in many projects (even if you don't use it, libraries yo use almost certainly do.

https://github.com/bellard/mquickjs/blob/main/README.md#:~:t...

It's funny how many people replying here just got whooshed. This comment is satire; they don't actually think Bellard wrote everything in 12 minutes.

Doesn't say much. Probably had it largely written down and put it together. I don't think it'd even be humanely possible to do that in 12 minutes.

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.

This would never happen because there's zero incentive to do this.

Browsers are complex because they solve a complex problem: running arbitrary applications in a secure manner across a wide range of platforms. So any "simple" browser you can come up with just won't work in the real world (yes, that means being compatible with websites that normal people use).

Lots of comments talking about how existing browsers can already do this, but the big benefit that current browsers can't give you is the sheer level of speed and efficiency that a highly restricted "lite web" browser could achieve, especially if the restrictions are made with efficiency in mind.

The embedded use case is obvious, but it'd also be excellent for things like documentation — with such a browser you could probably have a dozen+ doc pages open with resource usage below that of a single regular browser tab. Perfect for things that you have sitting open for long periods of time.

There could be a way: This HTML-lite spec would be subset of current standard so that if you open this HTML lite page in normal browser it would still work. but HTML-lite browser would only open HTML-lite sites, apart from tech itch it could be used in someplace where not full browser is needed, especially if you are control content generation. - TV screens UI - some game engines embed chrome embed thing ( steam store page kind) - some electron apps / lighter cross platform engine - less sucky QML - i think weechat or sth has own xml bashed app froamework thing (so could be useful to people wanting to build everything app app platform - much richer markdown format ?

While we're wishing, can we split CSS into two parts - styling and layout? Also, I'd like to fix the spelling on the "referer" header...

What about https://geminiprotocol.net/

And also bring back progressive enhancement.

https://en.wikipedia.org/wiki/Progressive_enhancement

Not likely to happen. There is geminiprotocol with gemtext though for those of us that are fine with that level of simplicity.

Work towards an eventual feature freeze and final standardisation of the web would be fantastic though, and a huge benefit to pretty much everyone other than maybe the Chrome developers.

So you want 2026 to be the year of Google AMP?

I would actually merge html and js in a single language and bring the layout part of css too (something like having grid and flexbox be elements themselves instead of display styles, more typst kind of showed this is possible in a nice way) and keep css only for the styling part.

Or maybe just make it all a single lispy language

Do it, man. Call it "MicroWeb" or whatever. Write an agent, make it "viewable with regular browsers". I think this could be cool.

Years ago I wrote a tiny xhtml-basic browser for a job. It was great. Some of my best work. But then the iPhone came out and xhtml-basic died practically overnight.

I can't think of an instance of the web contracting like that. Maybe when Apple decided not to support Adobe Flash.

Would be cool to create a MicroBrowser, just to browser stuff that's compatible.

You mean like the piece of crap that was WAP?

I think there needs to be a split between the web browser as a document renderer and link follower, and the web browser as a portable target for GUI applications. But frankly my biggest gripe is that you need HTML, JS, and CSS. Three distinct languages that are extremely dissimilar in syntax and semantics that you need all three of (or some bastard cross compiler for your JSX to convert from one format to them). Just make a decent scripting language and interface for the browser and you don't need that nonsense.

I understand this has been tried before (flash, silverlight, etc). They weren't bad ideas, they were killed because of companies that were threatened by the browser as a standard target for applications.

You can already create websites to these standards. Then truncate large parts of webkit and create a new browser. Or base it on Servo.

I mean, you can do all that now, so that's not the problem. The problem would be convincing millions of people to switch, when 99.99999% of them couldn't care less.

And if you find you need more features than that - just build an app, don't make the web browser into some overly bloated app!

I'm guessing the use of undeclared variables result in an error, instead of implicitly creating a global variable.

it also talks about the global object not being a place to add properties. So how you might do `window.foo = ...` or `globalThis.foo = ...` to make something from the local context into a global object. in this dialect I guess you would have to reserve any global objects you wanted to set with a `var` and then set them by reference eg

    // global. initialized by SomeConstructor
    var fooInstance

    class SomeConstructor {
       constructor(...) {
          fooInstance = this;
       }
       static getInstance(...) {
          if (fooInstance != null) return fooInstance;
          return new SomeConstructor(...);
       }
    }

I think it means you can't assign to unbounded names, you must either declare with var for global, or let/const for local

It’s not even the languages or runtimes that inhibit embedded adoption but the software to hardware tooling. Loader scripts, HAL/LL/CMSIS, flashing, etc. They all suck.

It looks like if you write the acceptable MQJS subset of JS+types, then run your code through a checker+stripper that doesn't try to inject implementations of TS's enums and such it should just work?

I don't think you can transpile arbitrary TS in mqjs's JS subset. Maybe you can lint your code in such a way that certain forbidden constructs fail the lint step, but I don't think you can do anything to avoid runtime errors (i.e. writing to an array out of its bonds).

Down to -4. Is this generic LLM-dislike, or a reaction to perceived over-self-promotion, or something else?

No matter how much you hate LLM stuff I think it's useful to know that there's a working proof of concept of this library compiled to WASM and working as a Python library.

I didn't plan to share this on HN but then MicroQuickJS showed up on the homepage so I figured people might find it useful.

(If I hadn't disclosed I'd used Claude for this I imagine I wouldn't have had any down-votes here.)

What is the purpose of compiling this to web assembly? What web assembly runtimes are there where there is not already an easily accessible (substantially faster) js execution environment? I know wasmtime exists and is not tied to a js execution engine like basically every other web assembly implementation, but the uses of wasmtime are not restricted from dependencies like v8 or jsc. Usually web assembly is used for providing sandboxing something a js execution environment is already designed to provide, and is only used when the code that requires sandboxing is native code not javascript. It sounds like a good way to waste a lot of performance for some additional sandboxing, but I can't imagine why you would ever design a system that way if you could choose a different (already available and higher performance) sandbox.

You should take a look at https://judge0.com/