Show HN: Elsa – A QuickJS wrapper written in Go

by qu4k • 6 years ago

126 52 6 years ago

faitswulff• 6 years ago

There are some benchmarks against Deno here (as JSON files): https://github.com/elsaland/elsa/tree/master/benchmarks

artagnon2• 6 years ago

Ofcourse; Deno is V8-based, which is a lot more full-featured than quickjs. Perhaps this is a more informative benchmark: https://bellard.org/quickjs/bench.html

tomp• 6 years ago

Wow,, this is seriously bad. Calling this fast is very misleading. QuickJS is about 0.5x as fast as V8 without JIT (and like 20x slower than V8+JIT).

pastrami_panda• 6 years ago

That is a horrible way to present benchmarks, but it's quite a big difference in favor of Elsa. I was under the impression Deno was built on Rust and V8 which should bode for good performance, Elsa must be doing something very good?

hombre_fatal• 6 years ago

Yeah, I've put more work into explaining the results of a benchmark I put on pastebin.

coder5432• 6 years ago

Each of the benchmarks seem to take a single-digit number of milliseconds in Elsa/QuickJS.

My guess is that these benchmarks were chosen because the startup time for QuickJS is probably less than the startup time for V8, but I struggle to imagine that V8 is slower once the code has warmed up.

Any meaningful benchmark with JIT runtimes should take several seconds, at a minimum, in my opinion. 8 milliseconds is not enough.

From what I can tell, the benchmark is including the startup time, and it isn't keeping the interpreter warm -- it starts a fresh instance for each iteration of the benchmark.

This is one of the benchmarks: https://github.com/elsaland/elsa/blob/master/testing/bench_s...

Literally a single line of JavaScript.

untog3• 6 years ago

I'm very dubious about whether these actually match real world performance.

I've done a bunch of work with QuickJS. It's awesome and the performance features you get in return for its tiny footprint is amazing. But compared to JIT-enabled V8 it's incredibly slow.

The one area where it shines compared to V8 is startup time, because the engine is so much lighter. So if you're profiling "time taken to start up and execute one operation" then yes, QuickJS might look better. But that isn't how people use Node/Deno, even when you're creating a CLI tool you're loading a lot of JS and performing a lot of operations.

artagnon2• 6 years ago

It's a simple command-line application that dispatches to the quickjs runtime. The headline is somewhat misleading.

Complexicate• 6 years ago

Let it go. Let it go. Misleading titles never bothered HN anyway.

sigzero• 6 years ago

I wish I could upvote you more than once!

cheph2• 6 years ago

I am quite happy that the topmost comment on a misleading post clarifies it. Clarity is good. So I guess I for one am happy someone did not let it go.

omarhaneef• 6 years ago

I didn’t get the connection before your joke, but I think it is called Elsa exactly because it is written in Go!

(This happens to me Olaf the time)

seg_lol5• 6 years ago

I don't think so, it is clearly a Deno competitor in name and spirit. My first thought was around how languages allow us to choose our tribe and that Go folks couldn't contribute to Deno since it is in Rust, hence Elsa, maybe they were getting Frozen out? Or Deno is the Dinosaur and Elsa is the ice age that kills them? Who knows, ;)

I had forgotten that Fabrice Bellard also made one of his signature hacks around JavaScript [1]. This thing is amazing and he created a nicely written and formatted pdf, absolutely lovely.

Then I started doing a simple comparison of the two code bases

    (py38.env) zc:deno seanj$ tokei 
    -------------------------------------------------------------------------------
    Language            Files        Lines         Code     Comments       Blanks
    -------------------------------------------------------------------------------
    JavaScript            169       168797       146555        19948         2294
    Markdown               89        10716        10716            0            0
    Rust                  101        42996        36525         2272         4199
    TypeScript            668       117796        85786        20609        11401
    -------------------------------------------------------------------------------
    Total                1119       342851       281567        43027        18257
    -------------------------------------------------------------------------------
    (py38.env) zc:elsa seanj$ tokei 
    -------------------------------------------------------------------------------
    Language            Files        Lines         Code     Comments       Blanks
    -------------------------------------------------------------------------------
    Go                     26         1143          949           21          173
    JavaScript             31       146438       127418        18927           93
    TypeScript              6         4450         1080         2823          547
    -------------------------------------------------------------------------------
    Total                  72       153059       130470        21774          815
    -------------------------------------------------------------------------------

The JS portions feel similar (spoiler, same TS runtime) and that Deno has documentation and probably a lot more tests.

Here is the a breakdown of the test code in each.

    # kept top-k entries after $find . -type f -not -ipath "*test*" -exec rm -f {} \;
    (py38.env) zircon:deno_t seanj$ tokei 
    -------------------------------------------------------------------------------
    Language            Files        Lines         Code     Comments       Blanks
    -------------------------------------------------------------------------------
    JavaScript            107         2991         2564          151          276
    Rust                    6         5166         4476          141          549
    TypeScript            420        40449        34436         1872         4141
    -------------------------------------------------------------------------------
    Total                 614        50564        43246         2219         5099
    -------------------------------------------------------------------------------
    (py38.env) zircon:elsa_t seanj$ tokei 
    -------------------------------------------------------------------------------
    Language            Files        Lines         Code     Comments       Blanks
    -------------------------------------------------------------------------------
    Go                      3           76           64            0           12
    JavaScript             23          137          115            2           20
    Plain Text              1            1            1            0            0
    TypeScript              5           14           11            0            3
    -------------------------------------------------------------------------------
    Total                  32          228          191            2           35
    -------------------------------------------------------------------------------

The JavaScript foot print in both codebases is mostly dominated by the TypeScript runtime and library.

    (py38.env) zc:deno seanj$ find . -name "*typescript*js" -exec tokei {} \;
    -------------------------------------------------------------------------------
    Language            Files        Lines         Code     Comments       Blanks
    -------------------------------------------------------------------------------
    JavaScript              1       147419       128513        18894           12
    -------------------------------------------------------------------------------
    Total                   1       147419       128513        18894           12
    -------------------------------------------------------------------------------
    (py38.env) zc:elsa_js seanj$ find . -name "*typescript*js" -exec tokei {} \;
    -------------------------------------------------------------------------------
    Language            Files        Lines         Code     Comments       Blanks
    -------------------------------------------------------------------------------
    JavaScript              1       145671       126934        18725           12
    -------------------------------------------------------------------------------
    Total                   1       145671       126934        18725           12
    -------------------------------------------------------------------------------

Deno only has 18kloc of js.

[1] https://bellard.org/quickjs/quickjs.pdf

randomdata• 6 years ago

Go folks couldn't contribute to Deno since it is in Rust

Deno was originally written in Go, until V8's GC was getting in the way of Go's GC, so they could always work on early versions of Deno, if they are willing to accept the problems with V8 that pushed the project to Rust.

jeswin• 6 years ago

The headline I believe was chosen by OP. What leaves a bad taste in my mouth is that the team thought it unnecessary to credit QuickJS and Bellard anywhere in the README file - and making it seem like original work.

DetroitThrow2• 6 years ago

Between this, what the "runtime" is currently capable of, and the benchmarks shown, I feel like this is a really poor example of a Show HN project and at best unintentionally misled me about several things...

qu4k4• 6 years ago

Thanks for pointing this out. Bellard deserves most of the credits. I updated the description accordingly.

ballenf• 6 years ago

I'm really curious how this reached #1 here on HN. Not accusing anyone of foul play, just really curious why this is so popular.

As for quickJS, I've really enjoyed using it and was surprised how easy it was to get started with a brew install on a Mac.

untog3• 6 years ago

I'm really curious how this reached #1 here on HN.

Usually people submit then direct friends/contacts/Twitter followers/etc to the "new" page to upvote. "growth hacking"? :)

DetroitThrow2• 6 years ago

I'm really curious how this reached #1 here on HN

I was initially excited about the idea of a Go alternative to some existing js runtimes.

Aissen2• 6 years ago

@qu4k It's a shame that QuickJS isn't mentionned in the README since it does the heavy lifting.

Also, why is it secure ? Is there some kind of sandboxing of the runtime that I have missed ?

qu4k4• 6 years ago

README still needs some work and surely we will credit the awesome libraries that allowed us to build elsa

We plan on taking the deno route and requiring flags when running a js file to allow specific ops to be called. You can see a demo of this in our filesystem ops

Aissen2• 6 years ago

Ok, I understand it's secure because of the deno-style permission system, but not necessarily because it can be used to run untrusted code safely (sandboxed engine, like in chromium).

zokier• 6 years ago

So Elsas own comparison[1] says that the binary size difference is 20MB Elsa (QJS) vs 44MB Deno (V8). Looking at QuickJS benchmark[2] V8 is 28M vs 1M QJS, so Elsa adds 19M on top of the engine vs 16M for Deno. Doesn't feel that lightweight anymore

[1] https://github.com/elsaland/elsa/blob/master/COMPARISON.md

[2] https://bellard.org/quickjs/bench.html

seg_lol5• 6 years ago

It is amusing how each of us define our own _lightweight_, for me it is the size and readability of the code. Others it is the magnitude of the executable bytes. To someone else it might mean the startup time, the number of dependencies or the build/test/debug iteration time.

pwdisswordfish4• 6 years ago

The only reasonable application of "minimal" is for it to be a cross-cutting description. To describe something as "minimal" without qualification while focusing only on any single quality is not a good use of the term.

adsjhdashkj• 6 years ago

Ooo, and one more: Depth of features.

Software that achieves my goal in a focused manner is something i typically enjoy. I don't want it to do everything under the sun, i want it to do one or two things well.

These days, to me, a "lightweight" alternative to Dropbox would be one that focuses on filesharing with none of that other junk.

untog3• 6 years ago

That was surprising to me, too. For me the big benefit of QuickJS is the tiny runtime size. If that isn't a factor you might as well go for V8, the performance is an order of magnitude better.

einpoklum• 6 years ago

The snowflake logo reminds one of Disney's Frozen, but - may also be confused with, well, Snowflake (the distributed database).

varbhat• 6 years ago

Mention QuickJS Engine in the readme . I came to know that this project uses quickjs (i believe it is written by Bellard) after reading about it in "comparison with deno and node"

qu4k4• 6 years ago

Done, thanks for pointing this out ;)

bryanrasmussen• 6 years ago

this made me wonder about a QuickJs wrapper for Rust https://github.com/theduke/quickjs-rs

jitl• 6 years ago

If you’re interested in using QuickJS yourself on the web or in node to implement untrusted JavaScript evaluation in your own (JavaScript) software, check out my library: https://github.com/justjake/quickjs-emscripten

sradman• 6 years ago

HN thread Fast Vue SSR with Rust and QuickJS (2 months old) makes it clear that QuickJS is an alternative to V8. QuickJS is small and easy to embed but it lacks V8's JIT for fast JavaScript execution.

It seems that the comparative advantage of QuickJS based solutions is short-lived invocations that benefit from fast startup times. CLI apps/tools and Cloud Functions (e.g. AWS Lambda) seem to fit the bill.

Elsa adds Deno-like HTTP imports and TypeScript support which makes it a strong alternative to Deno for CLI apps/tools.

Deno (V8 on Rust) or the rusty_v8 bindings seems like the better choice for long-lived servers where server-side JavaScript performance is important.

[1] https://news.ycombinator.com/item?id=23887336

oknoorap• 6 years ago

Interesting alternative for Deno. I'll be waiting Olaf and Anna engine to come out.

Show HN: Elsa – A QuickJS wrapper written in Go

Related Stories