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

191–200 of 594 posts

Re: Fabrice Bellard Releases MicroQuickJS

#191

Post by [deleted] »

drschwabe wrote: post #94
groundzeros2015 wrote: post #75

Earlier quoted context omitted.

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.

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.

[deleted]

Re: Fabrice Bellard Releases MicroQuickJS

#192

Post by baudaux »

MobiusHorizons wrote: post #131
baudaux wrote: post #125

Earlier quoted context omitted.

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

Is there not a way to use the browser native js execution environment for that? You lose a non-trivial amount of performance running js inside quickjs inside of wasm vs the browser native js engine. I wouldn't be surprised if that's 10 or even 20 times slower, and of course requires loading more code into the browser (slower startup, more ram usage). Maybe you don't care about that, but all of that is pretty orthogon…

Maybe with plugins. The WebAssembly way is cross platform. You would be very surprised with the performances of WebAssembly. I have built a Fibonacci test program in Rust that runs faster when built to Wasi than the native target on my MacBook

Re: Fabrice Bellard Releases MicroQuickJS

#193

Post by rpdillon »

alabhyajindal wrote: post #86
simonw wrote: post #76

Earlier quoted context omitted.

Forget about the AI bit. Do you think it's interesting that MicroQuickJS can be used from Python via FFI or as a compiled module, and can also be compiled to WebAssembly and called from Node.js and Deno and from Pyodide running in a browser? ... and that it provides a useful sandbox in that you can robustly limit both the memory and time allowed, including limiting expensive regular expression evaluation? I included…

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.

Software system is released, comments talk about how to integrate it with other software systems. Seems on-topic.

Re: Fabrice Bellard Releases MicroQuickJS

#194

Post by aziis98 »

alcover wrote: post #5

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.

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

Re: Fabrice Bellard Releases MicroQuickJS

#195

Post by garganzol »

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…

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.

Re: Fabrice Bellard Releases MicroQuickJS

#196

Post by lioeters »

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…

> as my primary language

I'd love to hear more how it is, the state of the library ecosystem, language evolution (wasn't there a new major version recently?), pros/cons, reasons to use it compared to other languages.

About tail-calls, in other languages I've found sometimes a conversion of recursive algorithm to a flat iterative loop with stack/queue to be effective. But it can be a pain, less elegant or intuitive than TCO.

Re: Fabrice Bellard Releases MicroQuickJS

#197

Post by nine_k »

IshKebab wrote: post #137
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…

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

This indeed is not Algol (or rather C) heritage, but Fortran heritage, not memory offsets but indices in mathematical formulae. This is why R and Julia also have 1-based indexing.

Re: Fabrice Bellard Releases MicroQuickJS

#198

Post by lucketone »

dbdr wrote: post #169
cibyr wrote: post #154

Earlier quoted context omitted.

People fight about tab sizes all the time though.

That's precisely the point of using tabs for indentation: you don't need to fight over it, because it's a local display preference that does not affect the source code at all, so everyone can just configure whatever they prefer locally without affecting other people. The idea of "skins" is apparently to push that even further by abstracting the concrete syntax.

> you don't need to fight over it, because it's a local display preference

This has limits.

Files produced with tab=2 and others with tab=8, might have quite different result regarding nesting.

(pain is still on the menu)

Re: Fabrice Bellard Releases MicroQuickJS

#199

Post by qznc »

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.

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

Re: Fabrice Bellard Releases MicroQuickJS

#200

Post by garganzol »

simonw wrote: post #67
simonw wrote: post #17

Clarification added later : One of my key interests at the moment is finding ways to run untrusted code from users (or generated by LLMs) in a robust sandbox from a Python application. MicroQuickJS looked like a very strong contender on that front, so I fired up Claude Code to try that out and build some prototypes. I had Claude Code for web figure out how to run this in a bunch of different ways this morning - I hav…

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 dis…

Thank you for sharing.

A lot of HN people got cut by AI in one way or another, so they seem to have personal beefs with AI. I am talking about not only job shortages but also general humbling of the bloated egos.

Post reply on HN