[HN Gopher] QuickJS JavaScript Engine
___________________________________________________________________
QuickJS JavaScript Engine
Author : gjvc
Score : 96 points
Date : 2022-03-08 09:10 UTC (13 hours ago)
(HTM) web link (bellard.org)
(TXT) w3m dump (bellard.org)
| pier25 wrote:
| One great feature of QJS is it can create C executables or
| modules from JS.
|
| AFAIK the JS code is not converted to C, but the compiler
| produces bytecode which is bundled with C code.
|
| This is interesting because it means it's possible to execute JS
| code from languages that have C interop. So for example you can
| do SSR rendering of Svelte components in a Go server application.
| At least in theory, I've never tried this.
| jart wrote:
| You can use QuickJS as an Actually Portable Executable.
| $ echo 'console.log("hello world\n");' >hello.js $ zip
| o//third_party/quickjs/qjs.com hello.js adding:
| hello.js (stored 0%) $ o//third_party/quickjs/qjs.com
| /zip/hello.js hello world
|
| Just add your source code to the qjs.com executable using
| InfoZIP and you've got a single file releasable binary that'll
| run on seven operating systems. It's also about 700kb in size.
| tiborsaas wrote:
| Where to get qjs.com from?
| dflock wrote:
| Here, I think?
|
| https://bellard.org/quickjs/binary_releases/
| silasb wrote:
| https://github.com/rogchap/v8go is a Go library which makes
| this easy to accomplish.
| pier25 wrote:
| Yeah but how much memory does that consume?
|
| QJS is a lot smaller than V8. Granted, it doesn't have JIT,
| but for certain stuff it's ok.
| saghul wrote:
| QuickJS is awesome, simple to use and very easy to integrate.
|
| Over the past few years I slowly built a small JS runtime using
| QuickJS as the engine and libuv as the platform layer, amongst
| other things, in case anyone wants to take a look:
| https://github.com/saghul/txiki.js
| [deleted]
| madjam002 wrote:
| QuickJS is cool, I use it to run a JS sandbox for a WYSIWYG
| editor so the user can write Nunjucks templates.
| pbowyer wrote:
| That sounds amazing, can you share any more details - of your
| WYSIWYG editor and how you use QuickJS?
| playpause wrote:
| Original discussion:
| https://news.ycombinator.com/item?id=20411154
| andrew_ wrote:
| How bizarre (1) that the author doesn't accept Pull Requests. I'd
| love to know more about why .patch files via mailing list are
| preferred.
|
| 1) _adjective . strange or unusual, especially so as to cause
| interest or amusement._
| ubertaco wrote:
| I wonder if it's a "raised barrier to entry" to prevent low-
| effort drive-by PRs. I have a couple of extremely-small OSS
| libs that are available in public package repos and are hosted
| on Github, and even those have gotten the drive-by "I slightly
| reworded your README" PRs that don't help. I can't imagine the
| volume of noise that larger projects get.
|
| By requiring a .patch file to be sent via a mailing list, the
| sort of "burden of effort" shifts away from "log into Github
| and click the pencil icon in the preview for README.md" and
| towards a slightly-heavier-weight minimum threshold -- one that
| shouldn't be so bad as to discourage folks making earnest
| valuable changes, but might be enough to make low-effort spam
| more annoying for the spammer than the spam-ee.
| londons_explore wrote:
| Mailing lists suffer from other kinds of spam... Actual email
| spam, poor moderation tools, etc.
| andrew_ wrote:
| Barrier of entry is a good call. From my experience on some
| rather large OSS projects, the ratio of noise to signal on
| PRs tends to go along with the target audience of the
| project.
| cxr wrote:
| Using a mailing list to manage (incl. browse) contributions
| really sucks. The way that GitHub abuses pull requests and all
| the anti-productive derpiness that has arisen around it,
| though, sucks even more. It will be nice when the world gets
| shaken out of the collective hallucination that GitHub is at
| all a reasonable and efficient way to do things, instead of
| what it actually is: another dark-pattern-employing, walled
| garden social network that prioritizes engagement and growth
| over productivity, privacy, accessibility, and quality of
| interaction.
| pcwalton wrote:
| The pull request workflow is not "anti-productive derpiness".
| You literally click one button and the pull request is
| merged. With email you have to save the patch from your
| webmail client+ somewhere, then apply it on the command line,
| and then push your changes. This workflow inefficiency is
| multiplied by the number of patches you have and therefore
| adds up quickly. There is no good reason for it other than
| nostalgia for the old days of Unix when everything was email
| based because the Web wasn't very mature yet.
|
| +Yes, most people use webmail, not native desktop email
| clients, and no, it is not reasonable to expect people to
| switch for this.
| cxr wrote:
| You have your thumb on the scale and are subjecting GitHub
| to the more lenient half of a double standard. Just like
| lots of software that gets billed as working with "a single
| click" even though it doesn't[1], there's lots more to it
| than you're saying here. Go do a sober and objective
| measurement of how involved GitHub _actually_ is, including
| scenarios for "I don't have an account yet", "I have an
| account, but I haven't forked/changed/committed my
| contributions yet", "I have cloned the original repo to my
| computer and committed the last few days of my work and
| need to submit my changes now", and "I need to maintain my
| privacy from casual snooping and to protect myself from
| people who would be casually willing to hurt me"[2].
|
| And I'm continually astounded whenever I bring up any
| GitHub criticism and get in response folks so hurried to
| try and "but Hillary!" me while leaping to the conclusion
| that I like mailing lists-- _even here in this case where I
| deliberately took special effort to start off by outright
| saying they suck_. Let me be emphatic (again): mailing
| lists _really_ suck.
|
| > This workflow inefficiency is multiplied by the number of
| patches you have
|
| On the topic of things that suck: Git's CLI. Having said
| that, I'm not going to lie about it being worse than it is.
| You've moved your thumb off the scale. You're now saying
| things that aren't true.
|
| Git's native workflows _should_ be better. So should GitHub
| 's.
|
| > There is no good reason for it other than nostalgia for
| the old days of Unix
|
| Go nerd-strawman someone else. I'm not Drew DeVault. I'm
| not the easily-take-downable bogeyman that, for your own
| convenience, you wish you were engaging with. I'm saying
| GitHub sucks because it does.
|
| (As further data points: it's been only since, like,
| sometime after COVID lockdowns began that GitHub's site was
| finally fixed so that when you visit on mobile now, you
| don't get a horizontal scrollbar anymore. And this is the
| pre-eminent, tech-oriented platform that people can't stand
| to see being heralded as anything other than the thing that
| makes doing technical work feel like normal and
| approachable for normal people? Their "wikis" aren't even
| wikis, for fuck's sake.)
|
| 1. https://web.archive.org/web/20090202140249/http://www.be
| ngoo...
|
| 2. https://news.ycombinator.com/item?id=18942501
| carapace wrote:
| You're arguing the old argument CLI/Terminal vs. GUI.
| Clicking a button vs. typing some commands is not the
| productivity bottleneck (or if it is you have bigger
| problems, eh?)
|
| (I've seen terminal jockeys do things that blew my mind,
| emitting continuous streams of characters that seamlessly
| switched between terminals and functions, orchestrating
| their machine like some virtuoso pianist, moving so fast it
| was impossible to follow. GUIs offer such folk nothing and
| I wouldn't be surprised if Fabrice Bellard was of this
| ilk.)
| badsectoracula wrote:
| As a contributor i found sending (or attaching to a bug
| report) .patch files _much_ easier than the pull request-
| based workflow, especially when there are changes after the
| patch is made.
| carapace wrote:
| The rise of GitHub seems to me one of the strangest things in
| the world. I've heard it called "the front page of the FOSS
| movement"! But the code for GitHub is _not available on
| GitHub!_ It was weird enough when a closed-source proprietary
| company put themselves in front of an open-source
| _distributed_ VCS and got traction, but then they were
| acquired by _Microsoft_!? That 's like Sauron buying the
| Shire and charging the hobbits rent on their own land or
| something. I feel a rant coming on, so I'm going to check
| myself here.
|
| I think if the world ends, it won't be due to Fire or Ice. I
| think the name of doom is _" Convenience"_.
| deckard1 wrote:
| I'll continue your rant. Bruce Perens and Eric Raymond
| fucked us. They took freedom and made it a commodity
| palatable to corporations. Now, Microsoft, via Github
| Copilot, has plans to sell our own code back to us as a
| subscription-based B2B productivity tool for businesses to
| create proprietary code. I couldn't even imagine such a
| dystopian outcome in 1998.
| jart wrote:
| Some proprietary software authors would likely feel the
| same way about free software. For example, Phil Katz
| drank himself to death after zlib used his invention to
| create the most prolific library in the world. I'd also
| imagine all the jobs software is eating would feel the
| same way. Now software is eating itself.
| carapace wrote:
| > Now software is eating itself.
|
| I thought it would happen much faster. Programming isn't
| that much harder than Go (the game not the lang) is it?
| Once automated programming becomes common and useful the
| problem domain shifts to mapping human intention(s) to
| the automated machinery, or how to write tame AI that can
| re-write itself w/o going feral? (Personally, I don't
| think it's possible, and Isaac Asimov pointed out why.
| It's the same "strange loop" explored in a handful of
| sci-fi stories that have hyper-lucky characters. What,
| ultimately, is good?)
|
| In re: Free software vs. charging for copies of software,
| I looked at the world situation when I was younger and
| figured that no company or even nation could pay me what
| I'm worth (in terms of the value that my ability with
| computers could potentially unlock) and the most
| efficient way to "work" would be to give away my output
| and take advantage of the "rising tide that lifts all
| boats". I took Bucky Fuller very seriously, and still do:
| we have all the technology to make a secular utopia, it's
| just a matter of logistics and psychology. And the
| computers can handle the logistics easily. I figured the
| psychology would handle itself once word got around, but
| it hasn't really. (I don't know if I was just incredibly
| naive or if humans are just incredibly stupid, it's a
| problem that still vexes me.)
| [deleted]
| qbasic_forever wrote:
| It's how git was created to operate. The linux kernel, probably
| the largest software project in history, only operates through
| emailed patch files too.
| cxr wrote:
| Linux uses pull requests, too, it's just that it uses them
| the way they were meant to be used--among a limited cohort of
| collaborators frequently pulling from one another--instead of
| GitHub-style pull requests that have little to do with Git-
| the-tool and that _everyone_ gets shunted through, even when
| a patch (or three) would be more appropriate.
| throwaway2037 wrote:
| Hi @dang: Can you please update the title of this post to include
| the date of last release (2021)? Officially, the last release was
| on 2021-03-27.
| gjvc wrote:
| Stop obsessing about the date of items and judge them on their
| actual _worth_ and _usefulness_ , not assumed "freshness".
|
| As I have mentioned elsewhere, activity is not a proxy for
| quality, but many other factors are, including the author,
| whose name I included in the submission but for some reason has
| been removed.
|
| So, there -- we've both got complaints!
| ramses0 wrote:
| I'm with you w.r.t. people on Jan 1 2022 trying to tag things
| as "(2021)", but can definitely understand the value of
| tagging as (2020/2019/...and prior).
| akmittal wrote:
| Im am always fascinated by how a single person can build a
| language runtime. That too for language like JavaScript where
| large number of features are introduces on regular basis.
|
| https://github.com/bellard/quickjs/graphs/contributors
| saghul wrote:
| Note that the GH repo is just a mirror, development happens
| elsewhere. From the copyright notes there is another main
| developer involved, Charlie Gordon.
| lifthrasiir wrote:
| JS is relatively easy to implement if you don't care about
| performance. (QuickJS _does_ care about preformance though,
| which makes it more amazing.) The apparent complexity of
| ECMAScript specification mostly comes from lots of pseudo code
| written in prose, which leaves no room for different
| interpretation and actually makes implementor 's job easier.
| Newer JS features also rarely introduce new concepts and can be
| mostly desugared into the core language, pretty isomorphic to
| ES5 plus some library bits like Proxy---which means you can
| start with ES5 (an even smaller language) and build newer
| features on top of that.
| jart wrote:
| Would you call running a marathon easy? Anyone can run. But
| could you run for 26.2 miles without stopping? The ECMAScript
| 12 spec is 44,000 lines and it contains 269,000 words. It's
| enormous. It's the same way with qemu. You have to spend
| months doing an enormous number of things to build something
| like that before it's able to run even the simplest most
| everyday programs. Bellard is legendary for his stamina. Not
| many programmers can match it. Only one I can think of would
| probably be the SerenityOS guy.
| lifthrasiir wrote:
| I like your marathon analogy. Not everyone can or does run
| a marathon, but there are still lots of marathoners. You do
| need stamina, but you don't need an inhuman level of
| stamina like Bellard's. If you don't stress yourself and
| pick your enemy wisely (like, start with ES5) it is very
| much doable.
| Klasiaster wrote:
| There is also duktape which got some traction:
| https://wiki.duktape.org/projectsusingduktape
|
| Not sure how they exactly compare - seems QuickJS supports a
| newer JS standard?
| gigel82 wrote:
| Gave it a try a couple of years ago and it had issues with larger
| JavaScript bundles (passing a lot of objects on the stack
| requiring recompiling the entire process with an increased stack
| size or modifying the threads on which it runs to accommodate -
| even with that, reasonably deep callstacks would overflow).
|
| I also thought the deterministic GC would mean lower memory usage
| but it's actually worse than V8 (which has all the intermediate
| bytecode, and the JIT-ed machine code as well in memory, plus the
| dangling objects).
|
| Still impressed that someone could write an EcmaScript-compliant
| engine from scratch, but looks more like a proof of concept (the
| fact it didn't get any updates in a year doesn't help either).
| 11235813213455 wrote:
| another interesting proof of concept:
| https://github.com/engine262/engine262
| c-smile wrote:
| My Sciter[1] Engine has two versions
|
| 1. Sciter.JS, with QuickJS, mainstream version now.
|
| 2. And former Sciter.TIS - uses my own TIScript. TIScript uses
| moving/compacting GC (close to V8).
|
| We have several products ported [2] from TIS to JS already. I
| am not registering increased memory consumption but quite
| contrary sometimes.
|
| In some cases deterministic reference counting schema is
| beneficial in UI, like: function Foo() {
| var nobj = new NativeObject(); nobj.dosomething();
| } // QuickJS will destroy nobj at exit from the
| function
|
| [1] https://sciter.com [2]
| https://terrainformatica.com/2022/02/19/freeconferencecall-a...
| MuffinFlavored wrote:
| Does this ship an exactly pegged version of WebKit like
| Electron or does it use whatever the host system provides?
| sreekotay wrote:
| Sciter does not use website at all, nor any HTML engine
| provided by the host OS. It is itself an entire HTML,CSS,JS
| engine.
| danbolt wrote:
| It's really interesting to hear your performance issues with
| QuickJS there.
|
| I found an opposite sort of performance profile (few small
| values on the stack, shallow stack size) with lots of calls
| back and forth between C and JS worked really well. Or, a lot
| of situations outdid V8 and ChakraCore for me (with JIT
| disabled). I didn't dig into the exact reasons why though.
| jitl wrote:
| If you want to use QuickJS in the browser and/or NodeJS for
| running untrusted code, building plugin systems, etc, I have a
| library here that wraps a WASM build of QuickJS:
|
| https://github.com/justjake/quickjs-emscripten#quickjs-emscr...
|
| I believe Figma uses QuickJS for their plugin system.
| david2ndaccount wrote:
| QuickJS is awesome. I'm using it to allow you to execute
| javascript in a markdown-like file format that allows you to
| manipulate the document tree programmatically before rendering to
| html. Has turned out much nicer than CPython which I was using
| before.
| CGamesPlay wrote:
| Project seems really cool! The docs seem a little sparse,
| unfortunately. After reading through the calculator code I am
| still curious: how do you use a custom resolver for modules? I
| want to make something completely sandboxed.
___________________________________________________________________
(page generated 2022-03-08 23:01 UTC)