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

JavaScript engines zoo – Compare every JavaScript engine

zoo.js.org

Post reply on HN
Print view View original

31–40 of 97 posts

Re: JavaScript engines zoo – Compare every JavaScript engine

#31

Post by senfiaj »

ggggffggggg wrote: post #25
senfiaj wrote: post #10

Earlier quoted context omitted.

Maybe because with tail call optimization you wouldn't have a proper stack trace?

I never understood this complaint. You won’t get a “loop trace” when you convert your tail calls into an iterative algorithm. And your code will be less readable to boot.

I don't know fast it would be if it was done iteratively. But Apple's implementation has negative implications for debuggability: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... https://webkit.org/blog/6240/ecmascript-6-proper-tail-calls-... .

V8 team decided that it's not worth it, since proper stack traces (such as Error.stack) are essential for some libraries, such as Sentry (!). Removing some stack trace info can break some code. Also, imagine you have missing info from the error stack trace in production code running on NodeJS. that's not good. If you need TCO, you can compile that code in WASM. V8 does TCO in WASM.

Re: JavaScript engines zoo – Compare every JavaScript engine

#32

Post by no_wizard »

gurgunday wrote: post #14

You can see when JIT is disabled, the upcoming Static Hermes (Hermes V1) engine from Meta, built specifically for React Native, outperforms both V8 and JSCore on Apple Silicon It'll be interesting to see how much it will affect React Native apps as it gets more and more optimized for this use case

React Native continues to be one of the best technology bets I’ve ever made.

At one point I really thought that Flutter would outclass it but typical Google project stuff has really put a damper on it from all I can see.

It’s not better than native apps, but as far as cross platform GuIs go it’s still very very good

Re: JavaScript engines zoo – Compare every JavaScript engine

#34

Post by wiseowise »

no_wizard wrote: post #32
gurgunday wrote: post #14

You can see when JIT is disabled, the upcoming Static Hermes (Hermes V1) engine from Meta, built specifically for React Native, outperforms both V8 and JSCore on Apple Silicon It'll be interesting to see how much it will affect React Native apps as it gets more and more optimized for this use case

React Native continues to be one of the best technology bets I’ve ever made. At one point I really thought that Flutter would outclass it but typical Google project stuff has really put a damper on it from all I can see. It’s not better than native apps, but as far as cross platform GuIs go it’s still very very good

> Flutter would outclass it but typical Google project stuff has really put a damper on it from all I can see.

Flutter is amazing, but they really shot themselves in the foot with Dart (and I say that as someone who doesn't mind Dart).

Re: JavaScript engines zoo – Compare every JavaScript engine

#35

Post by Octoth0rpe »

gurgunday wrote: post #24
lionkor wrote: post #22

Earlier quoted context omitted.

> Google has a lot more incentive than Apple to make the fastest engine What are those incentives? I see no incentive for Google to make something fast.

A significant part of Google’s business (Ads, YouTube, Workspace) runs inside a browser, so if the web is slow, Google loses money

And the faster that a page finishes rendering on an iphone, the faster that the cpu can idle, which hugely benefits battery life. That's a pretty strong motivation on Apple's side. I don't think the proposed motivation on google's side is stronger.

Re: JavaScript engines zoo – Compare every JavaScript engine

#36

Post by pygy_ »

senfiaj wrote: post #31
ggggffggggg wrote: post #25

Earlier quoted context omitted.

I never understood this complaint. You won’t get a “loop trace” when you convert your tail calls into an iterative algorithm. And your code will be less readable to boot.

I don't know fast it would be if it was done iteratively. But Apple's implementation has negative implications for debuggability: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... https://webkit.org/blog/6240/ecmascript-6-proper-tail-calls-... . V8 team decided that it's not worth it, since proper stack traces (such as Error.stack) are essential for some libraries, such as Sentry (!). Removing some stac…

That argument was vaguely plausible until WebKit/JavaScriptCore shipped PTC and literally no one bat an eye.

Bun users don’t care either.

At this point it is pure BS.

Re: JavaScript engines zoo – Compare every JavaScript engine

#37

Post by johannes1234321 »

gurgunday wrote: post #24
lionkor wrote: post #22

Earlier quoted context omitted.

> Google has a lot more incentive than Apple to make the fastest engine What are those incentives? I see no incentive for Google to make something fast.

A significant part of Google’s business (Ads, YouTube, Workspace) runs inside a browser, so if the web is slow, Google loses money

What are the marginal gains in business for them from the likely improvement of the runtime? It's not like the web (or: web-technology-based apps) don't capture a lot of time already.

Re: JavaScript engines zoo – Compare every JavaScript engine

#38

Post by _alastair »

It’s fascinating to see so many implementations targeting the same thing, along with the crazy variation in runtime size. I’d love to see memory usage comparisons too but I suppose you’d need to establish what you’re actually measuring first.

A few years ago I started work on a kind of abstraction layer that would let you plug Rust code into multiple different engines. Got as far as a proof of concept for JavascriptCore and QuickJS (at the time I had iOS and Android in mind as targets). I still think there’s some value in the idea, to avoid making too heavy a bet on one single JS engine.

https://github.com/alastaircoote/esperanto

Re: JavaScript engines zoo – Compare every JavaScript engine

#39

Post by ivankra »

_alastair wrote: post #38

It’s fascinating to see so many implementations targeting the same thing, along with the crazy variation in runtime size. I’d love to see memory usage comparisons too but I suppose you’d need to establish what you’re actually measuring first. A few years ago I started work on a kind of abstraction layer that would let you plug Rust code into multiple different engines. Got as far as a proof of concept for JavascriptC…

I actually captured max RSS size while running benchmarks as a rough approximation, but it's not exposed anywhere. If you go to the repo, you can run `./bench/compare -f rss_mb -lT bench/amd64/*.json` to see a table in the terminal. No big surprises there, Java engines (Rhino, Nashorn, GraalJS) are most memory-hungry.
Post reply on HN