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

Porffor: A from-scratch experimental ahead-of-time JS engine

porffor.dev

Post reply on HN
Print view View original

71–80 of 148 posts

Re: Porffor: A from-scratch experimental ahead-of-time JS engine

#71

Post by frutiger »

bobvarioa wrote: post #46
syrusakbary wrote: post #8

It's awesome to see how more JS runtimes try to approach Wasm. This project reminds me to Static Hermes (the JS engine from Facebook to improve the speed of React Native projects on iOS and Android). I've spent a bit of time trying to review each, so hopefully this analysis will be useful for some readers. What are the main commonalities and differences between Static Hermes and Porffor? * They both aim for JS test26…

Contributor for Porffor here! I think this is a great comparison, but Porffor does technically support promises, albeit synchronously . It's a similar approach to Kiesel, https://kiesel.dev/ .

Not sure where you mean by synchronously but if you mean what I think you mean then that is not correct behaviour. This is important to ensure predicatibility.

Eg.

    Promise.then(() => console.log(“a”));
    console.log(“b”)
must log [“b”, “a”] and not [“a”, “b”].

Re: Porffor: A from-scratch experimental ahead-of-time JS engine

#72

Post by tmikov »

syrusakbary wrote: post #8

It's awesome to see how more JS runtimes try to approach Wasm. This project reminds me to Static Hermes (the JS engine from Facebook to improve the speed of React Native projects on iOS and Android). I've spent a bit of time trying to review each, so hopefully this analysis will be useful for some readers. What are the main commonalities and differences between Static Hermes and Porffor? * They both aim for JS test26…

For the record, Static Hermes fully supports compiling JS to WASM. We get it basically for free, because it is an existing LLVM backend. See https://x.com/tmikov/status/1706138872412074204 for example.

Admittedly, it is not our focus, we are focusing mainly on React Native, where WASM doesn't make sense.

The most important feature of Static Hermes is our type checker, which guarantees runtime soundness.

Porffor is very interesting, I have been watching it for some time and I am rooting for it.

Re: Porffor: A from-scratch experimental ahead-of-time JS engine

#73

Post by userbinator »

Porffor can compile to real native binaries without just packaging a runtime like existing solutions.

Any language that allows generating and interpreting its own code at runtime will have the "eval problem". From some other comments here, it sounds like Porffor's solution is to simply ignore it.

Re: Porffor: A from-scratch experimental ahead-of-time JS engine

#75

Post by spartanatreyu »

tasty_freeze wrote: post #40
syrusakbary wrote: post #18

Earlier quoted context omitted.

Since Porffor can compile itself (you can run the compiler inside of Porffor), any calls to eval could be compiled to Wasm (via executing the Porffor compiler in Porffor JS engine) and executed performantly on the same JS context * *or at least, in theory

I haven't used it, but reading their landing page, Porffor says their runtime is vastly smaller because it is AOT. If the compiler had to be bundled with the executable, then the size of the executable would grow much larger.

Yeah, but you'd only need to include Porffor into compiled code if it used eval.

And most devs stay away from eval for well-deserved security reasons.

Re: Porffor: A from-scratch experimental ahead-of-time JS engine

#76

Post by concerndc1tizen »

syrusakbary wrote: post #18
saagarjha wrote: post #11

What happens when someone calls eval?

Since Porffor can compile itself (you can run the compiler inside of Porffor), any calls to eval could be compiled to Wasm (via executing the Porffor compiler in Porffor JS engine) and executed performantly on the same JS context * *or at least, in theory

That wouldn't work: The Wasm spec does not allow for modifying an already running program (e.g. JIT).

AFAIK the only option is to include an interpreter.

Re: Porffor: A from-scratch experimental ahead-of-time JS engine

#77

Post by pandemic_region »

pityJuke wrote: post #36
simlevesque wrote: post #9

Earlier quoted context omitted.

Financed by defunkt[1], GitHub cofounder and ex CEO, for an undisclosed future project. [1] https://news.ycombinator.com/user?id=defunkt

Also funded the Ladybird browser recently. Seems to like his web.

Not familiar with this stuff at all, is Porffor a js engine that Ladybird could end up using? Or are they still writing their own?

Re: Porffor: A from-scratch experimental ahead-of-time JS engine

#78

Post by spacechild1 »

WatchDog wrote: post #55

How does this compare to quickJS, which can also compile JS to native code(with a C compiler)

I think QuickJS only compiles to bytecode and then embeds it together with the interpreter in an executable. The JS itself is still interpreted. Others please correct me if I'm wrong.

Re: Porffor: A from-scratch experimental ahead-of-time JS engine

#79

Post by Sammi »

pandemic_region wrote: post #77
pityJuke wrote: post #36

Earlier quoted context omitted.

Also funded the Ladybird browser recently. Seems to like his web.

Not familiar with this stuff at all, is Porffor a js engine that Ladybird could end up using? Or are they still writing their own?

Or just two separate moonshots for now.

Re: Porffor: A from-scratch experimental ahead-of-time JS engine

#80

Post by pjmlp »

obviouslynotme wrote: post #35
wk_end wrote: post #31

Earlier quoted context omitted.

You’re misunderstanding me, I think. Suppose you have some interface with fields a and c. If your function takes in an object with that interface and operates on the c field, what you want is to be able to do is compile that function to access c at “the address pointed to by the pointer to the object, plus 8” (assuming 64-bit fields). Your CPU supports such addressing directly. Because of structural subtyping, you ca…

I would bet that, especially outside of library code, 95+% of the typed objects are only interacted with using a single interface. These could be turned into structs with direct calls. Outside of this, you can unify the types. You would take every interface used to access the object and create a new type that has all of the members of both. You can then either create vtables or monomorphize where it is used in calls.…

Which is exactly the kind of optimizations JIT compilers are able to perform, and AOT compiler can't do them safely without having PGO data, and even then, they can't re-optimize if the PGO happens to miss a critical path that breaks all the assumptions.
Post reply on HN