Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Elsa – A QuickJS wrapper written in Go

github.com

Post reply on HN
Print view View original

61–69 of 69 posts

Re: Show HN: Elsa – A QuickJS wrapper written in Go

#61

Post by gostsamo »

pjmlp wrote: post #53
gostsamo wrote: post #50

Earlier quoted context omitted.

Not all unicodes are equal for a screen reader. The text in case is read for me as every letter is separated from the others by a unpronouncible symbol and the whole line becomes a mess. Something like the chicken language, if you are acquainted with the concept.

I see, thanks for explaining. Anyway to do it in a more screen reader friendlier way?

Besides leaving effects to the fond, I'm not quite sure. The screen readers must be told to treat one symbol as another and this is not something easy in plain text format. In HTML that you own, you can try to do it with images and alt text attribute, or some shenanigans with aria-hidden and aria-text. Front end is not my specialty, unfortunately.

Re: Show HN: Elsa – A QuickJS wrapper written in Go

#62

Post by adsjhdashkj »

seg_lol wrote: post #28
zokier wrote: post #19

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

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.

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.

Re: Show HN: Elsa – A QuickJS wrapper written in Go

#63

Post by cxr »

coder543 wrote: post #60
cxr wrote: post #58

Earlier quoted context omitted.

> Any meaningful benchmark with JIT runtimes should take several seconds, at a minimum, in my opinion. 8 milliseconds is not enough. Maybe a benchmark for JIT runtimes, but you should always keep in mind what the expected use case is. I recently ported a program from lang X to lang Y. It's a command-line program that you're expected to invoke in your terminal, and it processes some input and then spits something out…

> For our program to have taken "several seconds, at a minimum" to run would have been a failure case, so there would have been no value in benchmarking that, let alone optimizing for it. I expect the use cases are the same for this project, which is supposed to be processing untrusted scriptlets that need to finish in the smallest amount of wall clock time possible. If the goal is to compare to NodeJS and Deno, whic…

> your comment has done nothing to negate any of the reasoning that went into my first comment

It's not clear to me that I'm supposed to have done that or why, but on that topic: likewise.

Re: Show HN: Elsa – A QuickJS wrapper written in Go

#64

Post by searchableguy »

gostsamo wrote: post #61
pjmlp wrote: post #53

Earlier quoted context omitted.

I see, thanks for explaining. Anyway to do it in a more screen reader friendlier way?

Besides leaving effects to the fond, I'm not quite sure. The screen readers must be told to treat one symbol as another and this is not something easy in plain text format. In HTML that you own, you can try to do it with images and alt text attribute, or some shenanigans with aria-hidden and aria-text. Front end is not my specialty, unfortunately.

Hey, I am curious which screen reader do you use?

I have noticed that many cloud based TTS actually work fine with unicode which was surprising. I know google one does and it sounds way better than whatever comes in as default on Ubuntu (Orca).

Re: Show HN: Elsa – A QuickJS wrapper written in Go

#65

Post by seg_lol »

filleduchaos wrote: post #57
seg_lol wrote: post #47

Earlier quoted context omitted.

True statement, but what does that metaphor-analogy have to do with server side JavaScript runtimes? They are also not the same thing, Dragonflys are fast, but they won't run my JS either. Our systems have absolute speeds that the client requests don't care about. They don't care if they are fast for an _x_ when that _x_ has nothing to do with the client. Minimal is a nice quality, but I don't think Elsa is fast in a…

> True statement, but what does that metaphor-analogy have to do with server side JavaScript runtimes Seems pretty self-evident that there are more considerations than "literally the fastest" to be made when the decision is "how do I get from point A to point B", or in this case "how do I execute my javascript". Vehicles and runtimes can be considered fast [enough] regardless of the existence of faster options. Also,…

I would like to deescalate this convo, I used overly harsh language and I apologize.

Your use of fast, is in the definition fast enough for the task at hand. It is not fast in the absolute sense. I assert that Elsa being that much slower than Deno due to Deno having a JIT where as Elsa does not automatically puts them in different categories. But the stack that Elsa uses still needs Go and C, so long term for Elsa I could see it using a pure Go JS runtime in place of QuickJS.

Re: Show HN: Elsa – A QuickJS wrapper written in Go

#66

Post by cheph »

codetrotter wrote: post #34
hn_throwaway_99 wrote: post #32

Earlier quoted context omitted.

It was a joke based on a song from Frozen.

Speaking of which: https://youtu.be/LJvEIjRBSDA Also, it’s weird how time flies. It’s been almost 6 years already since they made the version of the song in the video here linked, but it feels like just yesterday that I saw it.

Wow, what an amazingly effective way to make me never hear another word of golang ever again.

Re: Show HN: Elsa – A QuickJS wrapper written in Go

#67

Post by gostsamo »

searchableguy wrote: post #64
gostsamo wrote: post #61

Earlier quoted context omitted.

Besides leaving effects to the fond, I'm not quite sure. The screen readers must be told to treat one symbol as another and this is not something easy in plain text format. In HTML that you own, you can try to do it with images and alt text attribute, or some shenanigans with aria-hidden and aria-text. Front end is not my specialty, unfortunately.

Hey, I am curious which screen reader do you use? I have noticed that many cloud based TTS actually work fine with unicode which was surprising. I know google one does and it sounds way better than whatever comes in as default on Ubuntu (Orca).

NVDA on Windows. Orca does not have high-quality voice for my language as far as I know and that renders it unusable for day-to-day usage.

Keep in mind that screen reader and voices for it are different components that could be mixed. Both could be instructed to treat unicodes in whatever manner necessary, but it is labor intensive and euristics usually has some dubious results.

Re: Show HN: Elsa – A QuickJS wrapper written in Go

#69

Post by seg_lol »

adsjhdashkj wrote: post #62
seg_lol wrote: post #28

Earlier quoted context omitted.

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.

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.

There are foundational aspects on knowing a component is done, that it will be the same everywhere. What do you think of Nix [1]?

The other quality of flexible composable systems is that they can be extended with something akin to an AoP system. Non-essential qualities can be woven and applied during composition so that each component doesn't have to implement various features.

A counter example is the find command, it has to implement a predicate language into the tool itself. If it omitted typed objects, a filter engine could select the subset. If find implemented polymorphic values, the predicate would dictate what facets were populated in the structures themselves but our shells don't work that way. A metashell that could define its environment and the streams of structures flowing between components could get us closer to a pervasively composable mode of system construction.

Unix pipelines [2] are awesome, but they aren't the pinnacle. I feel like all of us fall short in creating systems that compose. Most (scalable) systems should be fractal, while most composition is limited to a narrow first-order mode of operation.

[1] https://nixos.org/

[2] https://en.wikipedia.org/wiki/Douglas_McIlroy

Post reply on HN