31–40 of 151 posts
QuickJS is a really, really interesting engine because it's only ~200KB. Fits a lot of cases where you want to add scripting ability but without bulking out size unnecessarily. Unfortunately because it lacks stuff like JIT it'll never rival the likes of V8 in performance. But in terms of bang for buck it's unbeatable.
Could this potentially be used in a browser? How complete is “complete”? Browser diversity is top of mind for me...
These individual technologies (DOM/html parser, js runtime, layout etc.) really aren't so bad. It's about a weekends worth of work to do one. What makes a "modern" browser is all of these technologies together not just quirk free, but matching quirks with whatever browser is popular. Even this won't really be enough since most people also depend on a bunch of online services provided by browser vendors at this point…
“layout”, including CSS? Hey, good joke, that’s amusing.
Frabrice Bellard truly works in God mode. Ffmpeg, Qemu, Tiny C Compiler ... many others .. and now this!
And in Emacs mode.
I can't say I understand the reason for such massive files. Surely it would be easier to maintain if it was split into a few well-defined modules?
In addition to the maintenance concerns, a JavaScript engine has quite a few parts that could be used as individual components. One good example of this is node's http-parser[1] that was extracted to a self-contained C file with associated headers and is a pleasure to use.
Pretty cool, but cant print basic objects const m = {year: 2019, month: 12}; console.log(m); // [object Object] Compare with Node: { year: 2019, month: 12 }
The spec leaves that up to the implementation: https://console.spec.whatwg.org/#log Node does some custom fanciness, but Object.prototype.toString() is equally correct.
let m = {year: 2019};
let s = JSON.stringify(m);
console.log(s); // {"year":2019}Very cool. Wouldn't it be cool if someone wrote bindings for Linux system calls and provided an event loop for this engine - then you could write system software in JavaScript!
Currently composed of 85,624 lines of C code, mostly in quickjs.c (53,575 lines in that one file alone), but also with a couple other large ones. I can't say I understand the reason for such massive files. Surely it would be easier to maintain if it was split into a few well-defined modules? In addition to the maintenance concerns, a JavaScript engine has quite a few parts that could be used as individual components.…
I kinda like large files (vs splitting the code), because they are easier to navigate in vim. I have no idea about why the choice was made for QuickJS, aside from ease of inclusion into other projects, mentioned in the docs.
> Can compile Javascript sources to executables with no external dependency. Is QuickJS a viable way to write command-line apps in JavaScript? In particular, does it have enough of a standard library to work with, or would it be a struggle because (I assume) it can’t use packages from NPM? I know there’s the alternative of bundling Node.js and V8 into an executable, but the resulting binaries are large - it feels lik…
Currently composed of 85,624 lines of C code, mostly in quickjs.c (53,575 lines in that one file alone), but also with a couple other large ones. I can't say I understand the reason for such massive files. Surely it would be easier to maintain if it was split into a few well-defined modules? In addition to the maintenance concerns, a JavaScript engine has quite a few parts that could be used as individual components.…
It could be that his workflow is to always navigate by searching function names. Then it doesn't really matter if the project is 1 file or 1000.
Very cool. Wouldn't it be cool if someone wrote bindings for Linux system calls and provided an event loop for this engine - then you could write system software in JavaScript!
I realize you're joking, but a company called Samsung actually did something similar already: https://nodejs.org/