471–480 of 594 posts
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.
Earlier quoted context omitted.
I want to build features - both client- and server-side - where users can provide JavaScript code that I then execute safely. Just having a WebAssembly engine available isn't enough for this - something has to take that user-provided string of JavaScript and execute it within a safe sandbox. Generally that means you need a JavaScript interpreter that has itself been compiled to WebAssembly. I've experimented with Qui…
GraalVM supports running javascript in a sandbox with a bunch of convenient options for running untrusted code. https://www.graalvm.org/latest/security-guide/sandboxing/
One catch: the sandboxing feature isn't in the "community edition", so only available under the non-open-source (but still sometimes free, I think?) Oracle GraalVM.
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.
Earlier quoted context omitted.
Just like all those normal people want rid of their bloated day-to-day monster of a web and therefore go and do something like, say, install an ad blocker? Oh right. 99% of people don't do even that , much less switch their life over to entirely new websites.
> 99% of people In 2025, depending on the study, it is said that 31.5~42.7% of internet users now block ads. Nearly one-third of Americans (32.2%) use ad blockers, with desktop leading at 37%.
I wish for this new year we reboot the Web with a super light standard and accompanying ecosystem with - A small and efficient JS subset, HTML, CSS - A family of very simple browsers that do just that - A new Web that adheres to the above That would make my year.
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…
I'm not an embedded systems guy (besides using esp32 boards) so this might be a dumb question but does something like this open up the possibility of programming an esp32/arduino board with Javascript, like Micro/Circuit Python?
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 )
I'm not an embedded systems guy (besides using esp32 boards) so this might be a dumb question but does something like this open up the possibility of programming an esp32/arduino board with Javascript, like Micro/Circuit Python?
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 ne…
What is the difference with https://www.espruino.com/ ?
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.
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 did once manage to compile Lua 5.4 on a Macintosh SE with 4MB of RAM, and THINK C 5.0 (circa 1991), which was a sick trick. Unfortunately, it took about 30 seconds for the VM to fully initialize, and it couldn't play well with the classic MacOS MMU-less handle-based memory management scheme.
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’m always surprised people pick Lua when Pawn exists. I think I’d even still choose it over MicroQuickJS https://www.compuphase.com/pawn/pawn.htm